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
Related
When I am running DrawX sample I have an unrestored package "Realm.Database".
When I am searching this package on Nuget - there are no results.
Is "Realm.Database" removed already and I have to use something different?
SushiHangover, I understand, thank you!
Sorry, as #SushiHangover explained, this is part of an upcoming release. It will be removed from our examples folder to avoid further confusion.
We don't quite manage to commit hourly around-the-clock but the pace of development has been fairly quick in recent time ;-) The rate of API-breaking changes will probably be a lot slower from now on.
Some of the changes have been put in place to support the new Realm Mobile Platform but many were there to help with data binding.
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.
Recently CI 2.1.0 is out.
I have a question. As I recognized that the CI folder structure has been 'evolved' (easy to setup, automatically defines base_url,etc), I'm wondering if the current template libraries like Phil's,william's concept,ocular,etc.. can be adapted to this new CI version.
I've tried Phil's but no luck, I mean..I don't know if I'm missing something this time, and ocular, also, to no avail ( I don't subclass the Controller, as suggested here)
Any better templating suggestions that will be suited enough to the latest CodeIgniter 2.1.0?
Thanks.
It seems like from the comments above that you're having trouble finding any resources online on the matter. Here's my suggestion for you:
Check the CodeIgniter Change Log here, and compare all the changes between this newest release, and the release that you know last worked with the template libraries that you've mentioned above. Use deductive reasoning, and see if you can find a way to modify the templates you need to work with the current CodeIgniter structure. I know that's a lot of work, and is not ideal for your situation. Regardless, it's the best advice I can give at the current moment. Good luck, and happy reading!
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 want to port my application to CodeIgniter but i am wondering whether i should use their v2.0 or v1.72 (then when they release 2.0, upgrade it).
i have never used a framework before so i don't exactly know what implies when upgrading a framework: what does it mean practically - i just move the folders and it will work? or do i have to change a lot of settings, file structure etc? could someone enlighten me about the upgrade process.
and what would you use: v.1.72 or v2.0?
if i'm using the latest version, is there a good documentation for it somewhere so you can read about how to use the new features: packages, drivers and so on.
thanks
You can read about some of the changes in 2.0 here.
I would image the upgrade process should be straightforward as long as you do not use any features that are different/removed such as plugins. Just take your models, controllers, etc and drop them into the 2.0 framework. Then regression test you whole app, fixing any problems as you see them...
If you are selling this app or making something mission critical then of course v1.7.2 is the best choice. That said I have PyroCMS running on v2.0 and since some of my bug-fixes were merged it seems stable enough.
One should consider time frames for deployment:
If it is one week, then stick to v1.7.2
If it is three months, go with v2
Assuming three months is approximately to time for a release to stabilise?