I am having some real issues with Magento version 1.4, I get alot of "There has been an error processing your request." errors do you think going to the latest version of 1.3 would be more stable ?
No, based on the information you've given, there's no reason 1.3 or 1.4 will run any more, or less stable for you. Track down the reasons for the error message (in your PHP/Apache/Magento error log. Once you know why the application is failing, you'll have a better idea if it's something specific to 1.4, or something about your general server setup.
I would disagree with Alan on this one, that is if your question is only if 1.3 (1.3.3) is more stable than 1.4. Since 1.3 has been around a lot longer, hand multiple sub-releases, etc., I think you'll find more stability in 1.3.3 than you would with 1.4.
If your question was whether or not to go with 1.3 or 1.4, I would definitely suggest going with 1.4. You may want to tackle whatever might be causing your errors, as it could be something rather simple. I have been using 1.4 since it came out, and developing pretty heavily with it, and I don't think I've gotten the error you are getting at all. In fact, I don't think I have had any issues whatsoever. There are known issues in upgrading to 1.4, but other than that, I have enjoyed it quite a bit.
The best to do would be to look at the error reports in var/reports/ and look at the exact error. That's not really a question of stablelity between the two versions.
Related
We're using rack-test for our Cucumber specs. We've been trying to migrate over to Ruby 3 for a while now and the current issue is that the Cucumber tests crash due to rack-test using both keyword/positional args in their internal methods.
I'm up for patching it myself, but seeing how little activity there is on the repo (including PRs open for weeks/months) I fear that I'd do the work and there would be nobody to patch it.
The only alternatives I see are:
Do the work and pray there will be someone to review/merge the changes
Patch it locally & use the patched version locally from now on (yuck)
Find an alternative solution for rack-test
The last solution seems the best IMO. So, are there any alternatives?
As with all open source software, you have a few options:
Keep using the old software version (i.e. don't use ruby v3.0.0).
Hope that someone else updates the dependencies for you.
Do the update yourself.
Stop using the library.
At the moment, option 1 is totally viable; ruby 2.7 is still actively maintained, and support will probably continue until 2023-03-31. You could do this, simply hoping that option 2 becomes available soon.
The standard practice for option 3 is:
Fork the project, and make the fixes.
Open a pull request to the main repo with your fixes. Hopefully it gets merged.
In the meantime, if you need to be unblocked, reference your forked repo in other projects.
This is clearly more effort, but I wouldn't call it a "yuck" solution; not unless your changes are drastic/introduce compatibility issues with the main project, and the two branches diverge.
As for option 4, as with virtually any library replacement, there's always going to be some trade-off between compatibility/features, but clearly other testing frameworks do exist. It depends how you are actually using it. Your mileage may vary.
In summary, I can't really give an objective answer to such a subjective question, but my advice at the moment would be: If you have time/skill/motivation to update to ruby 3 right now, then fork the dependency and update it. (It's probably not a massive change needed!).
But if you lack the time/skill/motivation to do this, then just stick with ruby 2.7 for now.
I have to build a News based website but I am not sure whether to use joomla 1.5 or 1.7? I have been using joomla 1.5 for a while and there are many extensions available for it. On the other hand joomla 1.7 has less extensions available at present and I have heard joomla 1.5 support will be stopped by next year. So would you please kindly suggest me which version of joomla should I go for and why?
Thanks in Advance :)
If you are building new, build in 1.7 as 1.5 is soon to be depreciated. While some extensions are only available in 1.5, most everything new is being written for 1.7.
1.7 has a much better ACL model and other improvements that will be useful for you.
Reasons to stay on 1.5 are limited to:
1. I absolutely need a specific module and nothing similar is available in 1.7 (but if you are building for a client, think of the implications down the road for this decision.)
2. I am supporting many sites and reusing resources among them; all my other sites are on 1.5. I have a migration plan to get them to 1.7 (or 2.5), but I want to do it later in an orderly manner.
If you are holding back for any other reason, you are making a mistake.
If you need extensions that are only available for 1.5, I'd use that. But if you can get away with using/making extensions for 1.7, I'd definitely recommend using 1.7. There will be a little bit of learning at first, but it'll make for a much easier upgrade to 1.8, and you may just find some of the new 1.7 features useful.
That's the approach we've been taking recently for our client projects. There's always a bit of a chicken-and-egg issue at first (waiting for extensions to update), but we now find there are very few things stopping us from using 1.7 as a base (although we're comfortable creating our own extensions where needed).
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
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?