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){
Related
I'm getting a strange behavior and after hours trying to figure out what might be causing this issue, still can't solve or understand why is this happening.
The project, using Laravel Framework 5.6.39, suddenly is loading every page twice, like a redirect. This happens in all routes, even the ones not using the master page layouts.
Examples: I call myproject.develop/ or myproject.develop/login or myproject.develop/articles and it loads the correct views but twice. It feels like a redirect to the same page or a refresh.
Some of the things I've done and didn't result: clear cache, clear config, clear views, clear routes, disable debugbar, disable clockwork. The behavior is the same.
Thank in advance for any help in trying to solve this issue.
After Ross Wilson suggestion to disable Javascript in the browser (Chrome o Mac OS), first it didn't solve the issue.
Nevertheless all the steps taken as described in my question, and also cleaning any application settings in the Chrome developers console, it wasn't working.
Then, reverting Chrome settings and re-enable Javascript in Chrome, it "magically" worked and this weird behavior disappeared. Just guessing that this might be a Chrome bug (using Version 71.0.3578.98 (Official Build) (64-bit)) while I was thinking anything was wrong with the application—routes, controllers, scripts, etc.—and it wasn't.
So if anyone starts experiencing this issue of pages loading twice, follow the steps and you might probably get lucky and solve the issue.
Thanks Ross!
Icognito mode solved it... so after dumping a bunch of chrome extensions it finally stopped.
I deleted cache from Chrome and the problem is gone
Ok, none of the others thing worked for me. This can be kinda obvious, but is good to check if you dont have any "src=''" in your code, this seems to try to make a request to the same url with the src type header. that happened to me.
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.
I'm using both scrollTo and the "child"-plugin serialScroll quite frequently, and like them because they
Actually SCROLL things, rather than animating css-properties (margin/position etc)
Are flexible and can be used in many different situations, unlike lots of other scroller/sliders that adds a bunch of bells and whistles that you don't really need.
Thing is, the plugins haven't been updated since 2009, and although they still work just fine, regardless of jquery version, there are things that could need improving (like the ability to change settings after initilaisation), and overall it doesn't fell optimal to use a 3 year old plugin, solid and stable as it is.
Does anyone have a suggestion of other plugins that might do the same thing, perhaps better?
http://flesler.blogspot.se/2007/10/jqueryscrollto.html
This is an old question, but for the record, as Shauna said, the plugins aren't outdated, OP might have been looking at Google code hosting which is indeed out of date.
The plugin is now hosted on Github. There's no much of a need to update it too often given it's very stable already, but I do land some commits every now and then when needed.
I don't have a suggestion for anything better (even Google is coming up with Flesler's plugin or hand-written from base JavaScript or jQuery), but Flesler is still updating the plugin. You can find the latest version in GitHub.
I've got a site built in Joomla, and it is using Joom!Fish for translating articles, which seems to work great.
However there's one page on my site, which in just one of the four languages currently active does not load two of my modules.
I've nailed this down to a SEF-urls problem, de-activating it in Joomla-admin fixes the issue, but I need to have SEF-urls.
Why is the SEF-url working on 3 of my languages, but on the fourth it seems to ignore the itemid parameter and not load my modules.
Using Joomla 1.5x, for SEF-urls I'm using the built-in solution, will perhaps using a SEF-plugin solve this?
Best Regards // Ninja
Fixed it by recreating articles menus, modules etc. That was connected to the broken page, and it started working. However it's prolly just a matter of time before the same problem will occur on a new page.
Seems to be an issue with SEF-urls and modules not really supporting it fully. JoomFish seems fairly bad at this.
So if someone else runs into this problem, try recreating everything thats connected to the problem, and hope nothing else will break.
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