I know Joomla 1.6 is now released, but curious if there will be an issue creating a website this early after the release. I am finding only a small number of available 1.6 templates. As I understand now, 1.5 components, extensions, etc. are not compatible and need to be upgraded. Am I going to run into a problem of not having a good selection of addons?
Should I use 1.5 now and wait til better support is available before moving to 1.6?
It really depends on what you are trying to do. The number of 1.6 ready extensions is growing quickly, there are over 400 of them now in just 3 weeks. Every big dev that I know if is working on updates for the most popular extensions.
If you do not have any special needs, then 1.6 is a very good product. I think it is much more polished than 1.5 was at release. There was a ton more beta testing and a much better foundation of code to work on this time.
I don't think you will see much 1.6 being used by pros just yet, because it is an unknown - there could be major problems that pop up once it gets hammered a little harder on live sites. There are also some extensions missing that will stop quite a few people - k2 being one of the notables.
This question is something we've thought over a lot as we've got several sites in the build/planning stages right now that will need to be upgraded within 18 months if they are built on 1.5. However, we've opted to wait a little while longer until there is a better picture of how solid this code is and when 1.7 will be released. It is entirely possible that any sites built in the next 2-3 months will skip 1.6 and go right to 1.7 when it comes time to upgrade.
The upgrade process is looking pretty promising so it is very possible that it will be a relatively painless process to upgrade a couple months from now.
I vote stay with 1.5 unless you really need the ACL.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I'm working on Magento 1.9.3.7 and I want to understand if is a good idea to migrate to Magento 2 or not.
I summarized this differences :
Magento 2.0 is faster then Magento 1.x
Some significant changes in the structure of directory which reduces
the complexity of structure
New technologies and latest versions (example Php, Jquery etc)
Allows developer to setup automated test easily
Many features are now integrate to Magento 2
Improvements to checkout and other stuff
My questions:
There is any index to look up to decide when is a good moment to migrate to Magento 2?
There are any hidden issue I have to know before?
Someone ever try this migration? If yes do you see this big improvement?
All my modules (third parts & hand-written) will be obsolete?
Why Magento 1.x is still releasing new security updates if there is Magento 2?
I hope to listen to different experencies or solution to understand if is the right way.
Please if I said something wrong tell me.
Docs on Internet (differences) : https://gauge.agency/articles/the-differences-between-magento-1-and-magento-2-and-which-is-better/
Having worked extensively with both platform, I have to say that Magento Inc's reasons for upgrading to m2 are just silly.
Magento 2.0 is faster then Magento 1.x
This is not really true, right? Reasons why they say that M2 is faster is that it supports php 7.x and runs Varnish. To this, I say, so what? M1 does as well.
Community efforts like this one work like a charm: https://github.com/Inchoo/Inchoo_PHP7 (I'm in no way affiliated with Inchoo).
Edit: This is now even less true since M1 (as of 1.9.4) supports 7.2 without third party modules.
On the other side M2 has a semi working asset precompiling system, which keeps causing issues on every turn. Further more, it slows the development to such degree that M1 feels like a blazing fast solution.
(If you think that this should be an outrageous exaggeration, which it should probably be, but sadly isn't, check out some of the GH issues.
Some significant changes in the structure of directory which reduces the complexity of structure
This was a great idea, but the actual result is terrible. How the hell did M2 end up with more configuration and more XMLs? What's with the XML heavy UI components?
Is this the example of the simplified module structure – https://github.com/magento/magento2/tree/2.3-develop/app/code/Magento/Catalog?
Yeah sure, M1 is not great here, but M2 did not improve here at all, just check out the amount of the xmls in a single module – https://github.com/magento/magento2/tree/2.3-develop/app/code/Magento/Catalog/etc
New technologies and latest versions (example Php, jQuery etc)
Sure, and stuff like ZF1, KnockoutJS and Fotorama.
Allows developer to setup automated test easily
I agree here. M2 has a proper support for automated testing, while M1 has almost none.
Many features are now integrate to Magento 2
I'm not sure what exactly you wanted to say here, but the problem I had is that they simply migrated features from M1 to M2, didn't improve them at all, slapped new interface on top of it and call it new platform.
While there's no problem here, I feel like this was a huge opportunity to improve the system, but they dropped the ball.
Improvements to checkout and other stuff
I disagree, checkout is now not as nearly flexible as it was. Working with KnockoutJs and UI Components is the last thing you want to do.
I'm fine with it being quirky and all, but the flexibility and possibility to improve checkout per particular shop is nowhere near M1.
There is any index to look up to decide when is a good moment to migrate to Magento 2?
Most of the Magento agencies are using this to promote their services and offer migrations to M2 as a way to make extra profit. So you'll always see companies talking about performance and feature improvements which aren't there.
This is the only case where someone says something differently: https://amasty.com/blog/magento-1-vs-magento-2-performance-comparison-speed-test-results/ (I'm in no way affiliated with Amasty).
There are any hidden issue I have to know before?
Platform is not stable enough, major bugs are still present. Just do a quick browse through issue reports on GH.
Why Magento 1.x is still releasing new security updates if there is Magento 2?
There are lots of businesses that will never migrate to M2. They have no option here.
Lastly, I want to say that I'm sorry for all the hate in this answer, really wasn't my intention. :D
There is any index to look up to decide when is a good moment to
migrate to Magento 2?
It depends on individual store environment (Big stores with own ESB may use M2 as storefront, small ones will have to wait until their ERP Provider releases a plugin or connector)
There are any hidden issue I have to know before?
M2 code architecture is nothing like M1. MVC has been dropped in favour of MVVM
Someone ever try this migration? If yes do you see this big
improvement?
yes. FPC has been improved alot and general ttfb response is a way better
All my modules (third parts & hand-written) will be obsolete?
yes, due different design patterns.
Why Magento 1.x is still releasing new security updates if there is
Magento 2?
Magento inc. has promised ongoing support for M1. There are too many enterprise customers I guess.
I have tried the Magento 1 to Magento 2 migration a few times before. But for me, there is only one reason I can think that stands out, to do such a major overhaul on a website, and that is security,
You should not just upgrade to Magento 2, but specifically 2.3 as it has a lot more invested in security and less prone to malware attacks. It also has new features that did not exist in Magento 2.2.
If you are still on Magento 1, then in theory, it's only a matter of time before malware finds your site.
A good practice would be to have a fork of this repository https://github.com/magento/magento2 and bring the latest fixes into your code periodically. This would of course give you another reason to upgrade to the latest version since Magento 1 is no longer maintained.
You will have to reproduce all of your modules for Magento 2, there is absolutely no other way, And if you use the Data Migration tool, you should have an easy time bringing the data over. And the next point is going to be to create the theme for your site once more, there is no easy way to bring your theme over from M1 either.
Good luck my friend =D
As the title says, is it possible? Right now, we have Java 6 + sqljdbc4 + glassfish 2.1.1. We're planning on upgrading our Java 6 to Java 8 in order for Sqljdbc42.jar to work, because we are having JDBC Connectivity issue and the solution might be to upgrade to sqljdbc42. Please see Option 1 in this link:
https://blogs.msdn.microsoft.com/dataaccesstechnologies/2016/11/30/intermittent-jdbc-connectivity-issue-the-driver-could-not-establish-a-secure-connection-to-sql-server-by-using-secure-sockets-layer-ssl-encryption-error-sql-server-returned-an-incomplete-respons/
Of course some of you might say to upgrade Glassfish to a later version but in case is this is not an option, would errors occur? I found out that editing the asenv.bat will do the trick (http://alvinalexander.com/blog/post/java/fixing-glassfish-jdk-path-problem-solved) but I'm not sure about the deeper problems we might face.
Thank you so much for your answers.
You would have to be very brave (and have lots of free time) to try jdk-8 on glassfish-2. While you can still download glassfish-2, the Extended Support support ends this year (2017). This is not even Premium Support, it's Extended meaning you have already gone too far by this time. I know this because of a client I used to work for that used glassfish-2.
There were multiple bugs and complaints reported or the 3-rd and 4-th versions with jdk-8, not even speaking of 2-nd. Unfortunately you should upgrade to something way more recent (and have a constant plan to upgrade from there still). Obviously you can try and change the jdk version and see what happens - but I bet you would be visiting this site way more often than you would want to.
The real reason why you should seriously consider upgrading is that not a lot of people can answer deeper problems we might face, because not a lot of people use this version. Just my 0.02$.
i wonder if Doctrine 2 is stable enough to use for a production project?
i guess the project will be finished 3 months from now so maybe then Doctrine 2 will be released in a complete version.
i'm wondering if its smarter to use learn and use doctrine 2 right away instead of learning the current version and then convert everything to version 2. cause i've read that the difference is huge between them.
thanks
I've been using Doctrine 2 in production for a few weeks now. Performance wise, it is much speedier than Doctrine 1. And it's much easier to develop with. I've had a few minor issues with bugs, or unimplemented features, but nothing that I couldn't work around.
Honestly, I don't think learning Doctrine 1 is terribly worth your time. Development for it will stop in 2011. And the two framework are so different, you're going to need to teach yourself twice.
As mentioned elsewhere, there have been some backwards compatibility API changes between the last Alpha release and the upcoming Beta (which is slated for the end of April), but they haven't been huge.
It's very possible by the time you're really picking up speed with a project, it'll be into the Beta phase.
The difference is huge, but one additional concern is API stability. I think they've stated in some blog posts that the API won't be considered final until a beta release (so far everything's been alpha). So, there's a chance you'll still have to refactor some code to fit any API changes they may make before beta.
I doubt they change anything earth-shattering, but not being able to say so definitively means that it's a little disconcerting for production use. My suggestion would be to at least wait until the first beta release, which should mark the API freeze.
My job is to upgrade all of our applications that use OpenSceneGraph (an openGl toolkit) version 0.9.9 to the latest and greatest 2.8. Well quite a few caveats come with this task:
1.) After version .9.9 there was a major overhaul the the core OpenSceneGraph (OSG). Commonly used functions and classes were added and removed. Simply put, I can't just replace the old with the new and modify a few deprecated or removed functions - there is a lot that needs to be changed.
2.) Our applications were built using MFC in Visual Studio 2003. They want me to stick with using that for the upgrade.
3.) Good organized documentation for my particular scenerio for OSG seems impossible to find and unorganized and scattered at best.
My question is: What would be a somewhat detailed methodical approach for tackling this problem. I've got about two weeks to upgrade one of the applications. The plan is then to follow and apply this approach for the rest of the applications. For me, the biggest hurdle is finding a starting point. On most projects I work on, I can easily just dig right in and figure it out with a little organization and plan at hand. This seems like a bit more convoluted problem, with a more accurate and precise plan of action needed. Your ideas and suggestions are much appreciated.
In my opinion, you should upgrade your osg to new version and try to build it again until you get no exception.
for every exception which is not solved easily, you can ask to osg-mailing list.
you can also ask what are the major changes with your current version and latest version.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm working on a new project and we're using a pretty nice stack. NHibernate, Spring, MVC... the list goes on.
One thing I've noticed tho is that in the 6 months since we've started we've had a new release of NHibernate, a new release of a third party control toolkit and Windows 7 is on the horizon.
We've had problems before where being stuck on an old version of a technology has cost us dearly, so I'm wondering what are some techniques we could use to help ensure that our transitions to the latest versions of things are as painless as possible?
Quite simply make it a priority and upgrade as you go along. If you keep up-to-date with the latest version, there will be less breaking changes than if you have to update 5 versions at a time.
Perhaps create a branch and do a test update to betas so that you are aware of forthcoming problems when that version RTMs (if using betas is a concern to you).
I agree with the other comments here about updating often. If you wait too long it will be enough work that you will notice it in the project productivity.
The way we do it is the following.
One person on the team, gets the latest version, and makes sure that all tests run.
That person the upgrades whatever dll's / tools are to be upgraded
He also documents the upgrade.
Build all code make necessary changes for it to build
Run all tests, make sure they run.
Manual smoke test of UI
Send info to rest of team with doc of upgrade
Checkin / make sure it builds on build server
This way we do not loose productivity of the team during the upgrade. Note this would be much more difficult without unit tests.
"update early, update often"
if you wait it will be more and more difficult so put high priority on updating the system. Developers mostly like to be on the bleeding edge so they will not mind too much, key challenge is to sell this idea to management.
It is always good to do step by step approach where you upgrade one by one tool. Then it is also easier if you need to roll back to older version. Big bang approach is more difficult and lots of things can go wrong.
Lets be realistic, every update will cost you time and also your team to do the switch to the new tooling version but after some time team learns to deal with it and level of stress when switching the versions is much less.
Speaking from a management point of view, don't upgrade unless there is a compelling reason. You have to look at what the upgrade brings to your project. If there are no benefits to the upgrade, don't do it. Obviously this isn't a hard and fast rule, but most teams I know don't have time to spend upgrading systems for no reason, they are too busy with feature requests and bug fixes. I recommend working in upgrades on the following basis:
The new version runs
[significantly] faster or more
efficiently and your
customers/clients will see this
improvement or it will reduce your
immanent hardware needs.
Features
have been added that you or your
customers/clients want and can take
[immediate] advantage of.
Security enhancement for a security
flaw that affects your current or
immediate future architecture.
License/support reasons. If you are
at the end of your contract then you
will probably want to make the final
jump to the last version of the
software that you are entitled to
while you still have support for the
upgrade. Alternately if you are on
such an old version of the software
that finding support documentation
for it is difficult then upgrading
is certainly called for.
Some aspect of the project that you are
working on is directly impacted by
the software that could be
upgraded. If you are already going
to be working with it and testing
the functionality, it is probably a
good time to upgrade and [probably]
won't add significant load to the
project.
Major changes. If your
project or the software it relies on
have undergone major changes then it
is probably a good time to add the
update(s) into your project plan.
Major changes implies a more
difficult upgrade path and should be
persude on a scheduled basis rather
than having to be shoe horned in at the last minute due to a needed fix or enhancement.
Specific reasons not to upgrade:
Software, installation, and regression testing costs money. Hence the need for a compelling reason to upgrade.
New software is often buggy or has unknown "features." For this reason many choose to stay one version behind the latest release.
Newer versions can often be slower than previous versions, this is especially true for small updates and patches.
Compatibility issues. Upgrades break things, it is better to skip as many incremental upgrades as possible in order to avoid updates that break compatibility, compatibility that may be fixed in the next update.
I recommend keeping a list of all software that your project utilizes along with their version and last upgrade date (along with other important information such as licensing info, support info, etc.). Evaluate every item on this list once a year in order to insure that you don't miss any updates that match a reason to upgrade that you may have missed. Software on this list with an old version/date and a newer version available may be incentive enough to convince management that an upgrade should be done.