I have this posted here:
https://getsatisfaction.com/pixelandtonic/topics/wygwam_not_styled_in_cp_entry_and_not_functioning_shown_errors_attached
...but I really need a fix asap if anyone can help here.
I can't get Wygwam to work.
It started with me running this:
EE 1.6.8 (Again, can't update)
Wygwam 2.1.6
FieldFrames 1.4.5
I wasn't able to activate the module. I would receive errors and then the field was jacked.
I then upgraded Wygwam to 2.6.3 and that allowed my to enable the module.
The problem I have now is this:
When I try to Add a new Wygwam field, it tells me that there are no configurations available. When I go to 'Edit Configurations', I only get the serial number input field. I added the serial number, but nothing changed. Under 'Editor Configurations' it just says: There are currently no configurations.
Now I have the existing fields back, however, I cannot view source and do not have any "Configurable Editors" available. I also cannot setup any "Configurable Editors" in the module because I have no settings/options display. Also, I cannot add any new Wygwam fields because when I do, I just get a white screen.
Ok, While this may not be the best answer to provide, it has provided a resolve to the situation I was in.
First off, Kudos goes to Brad Bell at Pixel & Tonic for sticking with me via emails in trying to get this fixed. I am in a situation with this site in which I can't provide access to the site, files, data, etc. It definitely makes getting help with EE related instances more difficult. Brandon and his staff definitely know how to push through these issues.
Thanks guys.
Nothing we were trying was working. What I had to end up doing was rolling back the versions of Wygwam and Matrix from the more recent releases that were installed to WW 2.1.1 and Matrix 2.0.11
I didn't try newer versions as I want to push harder than ever now for a site update/rebuild due to these issues and others. The site is again functional in these areas and they can move forward, (or laterally... depending on your stance), again.
Related
Trying to post to CocoaPods, but when the project goes through it doesn’t generate docs (site + docs button, instead of expand). Alternatively, when I specify a docs url the docs button doesn’t work either. According to the guides, it seems like jazzy isn’t parsing, but when I run:
jazzy
or...
jazzy —podspec MagicCloud.podspec
…it throws no errors and generates 100% documentation (which is hosted here). At the 404 page, If I select the Alternatively, click… or Potential error info buttons no luck. I’ve tried with and without a .yaml file generated here. When I try to use the following…
http://api.cocoadocs.org:4567/redeploy/MagicCloud/2.9.x // x = 5,6,7,8,etc…
http://api.cocoadocs.org:4567/error/MagicCloud/2.9.x // x = 5,6,7,8,etc…
…safari can’t find the server. I’ve posted so many versions at this point, any help would be much appreciated. The project is here, along with it's podspec file. Thanks in advance.
So after contacting Orta (the developer) directly, I eventually found out that he had handed the project off to Buddy Build. With their acquisition by Apple, they're holding off on new clients and are no longer offering support to Cocoapods.
As far as I can tell, no new Cocoapods have been able to compile their docs (at least through jazzy / swift), since the announcement January 2018. If anyone knows different, or if things change, please post here. Thanks.
Asked this on superuser.com, not sure if stackoverflow is a better suitable place for it, but I am not getting any answers yet:
===
I am trying to generate a new blog entry in my octopress setup, but I noticed that some previous posts are being generated as empty files in public, so are the new ones I am trying to generte.
There seems to be no difference at all between the markup files from one entry which is being properly generated to another that isn't
I've got two octopress installations, one's working and this one I am talking about isn't, updates octopress on both, reinstalled bundle but no luck, files as atom.xml are also not being generated correctly.
Also updated from ruby 1.9.2p290 to latest release from 1.9.3 but also did not difference.
Anyone's encountered this before?
===
This is most likely because you started using codeblocks. This was happening to me, and even posts/pages that didn't use codeblocks would fail to generate. My problem (on Windows) was that I didn't even have Python installed (thought I did). Installing it fixed the problem, then gave me another error, which was fixed by updating the pygments.rb (note .rb) gem. Doing these two things fixed all my problems.
There's a similar issue if you're on arch linux which defaults python to version 3 which isn't supported by pygments.rb yet. You'll have to look around to figure out how to fix that to use 2.7 instead, but it should be pretty straightforward.
Can you provide an example of: a) a post that doesn't generate correctly, and b) a post that does generate correctly?
I assume they are just individual posts (and not, for example, pages like /about/). I would also assume that they render as blank both in the blog index on your front page and on the individual post page.
Also - what does render? Is it rendering the rest of the page, but just without the "content" of the post itself? Or does the page not even exist? (404?)
Do Magneto CE extensions work in PE? The extensions I've tried installing in PE aren't working (they install but yield blank screens) and I can't find a straight answer; don't know if it's a problem on my end or if it's built in to Magento. Thanks in advance!!
Short answer is yes. CE modules can function correctly as part of PE, but it will depend greatly on what parts of the functionality it touches.
Things to do for any Magento issues like this:
Ensure the extension is enabled (check to ensure it's output is enabled and it's active) - see this post for reference (the post is how to turn off an extension, but it will point you in the right direction)
Refresh your cache
Ensure logging is on and check your logs for errors
Check your web server logs - where these are will depend on which web server you are running. Apache logs are generally in the error.log file under /var/logs/apache2 or /var/log/httpd
If all else fails, start debugging, by putting Mage::log() entries into the code and seeing what is logged and what isn't
Any extension could possibly work in any version, even if it isn't listed as such. Generally developers of extensions just list the versions that it has been tested in, but that doesn't mean it cant be used in others.
Best way to find out is install the module in your dev environment, and test to make sure it isn't overwriting/breaking any of the existing functionality.
Internet Explorer 9 was released today, and I decided to check a few Magento sites we build in the last couple of months to see if everything continues to work with the new version.
But unfortunately it doesn't. I came across one particular problem that is caused by the version of the prototype library which is shipped with Magento, version 1.6.0.3.
It looks like the cancelling events in eventhandlers isn't working.
For example, if you try to log in to a Magento shop, and just leave the login and password fields empty, IE9 submits the form even if there were errors, and the errors disappear after the refresh.
So that's quite a big problem I think.
So my question is: how can we deal with this problem? I see a couple of ways to deal with this:
Wait for Magento to release a new version with fixes
Upgrade the prototype library to the latest version which probably already has fixed the issue
Mess around in the existing library and try to fix the bug in there
Waiting for a new Magento release isn't a good idea because it probably will take a few weeks before there is one, and because it will cause a whole lot of other problems if you are running a very old version of Magento.
Upgrading to the latest prototype library is probably the best idea, but will everything in Magento continue to work with the latest version of prototype, does anybody has any experience with this?
So what's everybody's opinion about this problem?
Any ideas other than mine?
As upgrading Prototype has the potential to break a lot of things in Magento (and, honestly, doing anything in Magento has the potential to break a lot of things in Magento), I created a theme override for my
app/code/design/frontend/{package}/{theme}/template/page/html/head.phtml
file and slapped the following as the first element under the head tag:
<meta http-equiv="X-UA-Compatible" content="IE=8" />
This tells IE to pretend as if it is IE 8, where possible. This solved an issue where, for example, you could not check out and complete the payment process if you only have one payment method enabled, as in IE 9 the fields will all be grayed out.
Note that it really must be the first tag underneath the <head>.
Since upgrading Magento in any way has the potential to cause problems, I feel this is the least intrusive way to solve the issue in the near term.
Solved: http://www.alexanderinteractive.com/blog/2011/10/solving-the-ie-7-ie-9-magento-prototype-validation-bug/
I spent a couple days on this, and discovered the only thing that truly works is disabling things at the form level. This should solve all your problems.
As a quick fix, I think I would take the same approach you are advocating, and upgrade Prototype to a version that does not contain this issue. However, Magento will be coming along with a patch (this is too big to ignore), and at that point, it would be wise to undo your changes and apply the patch they provide to keep in line with normal upgrades.
It is rarely worth it to manually dig in the internals of Magento's JS, so that option seems a bit off to me. There are probably several places where this semantic is used and you may miss some of them.
Hope that helps!
Thanks,
Joseph Mastey
I've updated the prototype.js file to 1.7 and so far it's correct. I dont see any errors. If you apdate and find errors please notify!
The proper fix is in the Magento forums.
In template/catalog/product/view/tabs.phtml, change the line that reads:
ul.select('li', 'ol').each(function(el){
to
ul.select('li').each(function(el){
I'm using Magento 1.4.1.1 for my webstore. The payment processor supports only 1.4.0.0. I realized this only just now when I was dreaming up of opening the store. Duh! Poor planning.
What's the way out?
Will downgrading help? Wat are the implications of that?
Thanks for any and all inputs.
I am not aware of anyone ever having successfully downgraded Magento. That said, a few considerations:
Are you using version control like you should be? If so, you should have a copy of the site and database from just before the upgrade. You should be able to use this as a starting point. This is your most optimistic route by far.
If no version control, you can download both of the versions and use diff to get the changes. Doing this in reverse theoretically creates a backwards patch.
If you've stayed out of the core code entirely, the code change could be nearly as simple as replacing app/code/core.
Even if you do downgrade the code, the data structures between versions have probably changed, so you'll need someone experienced to find those changes and tell you have to back-patch your database. This is, to say the least, perilous.
Overall, I wouldn't want to undertake this task. As Anton said in the comments, you'll probably have an easier time getting integration done than reverting the changes.
Best of luck!
Thanks,
Joe