I'd like advice on the best approach to deploying Diazo to work with Plone 3. I know that plone.app.theming is out of the question for versions less than Plone 4.1 but we can't upgrade to Plone 4 yet as we need to port some code to Plone 4.x first but we'd like to benefit from the theming infrastructure of Diazo.
You can also run Diazo via any of the non-Plone deployment methods listed at http://docs.diazo.org/en/latest/deployment.html. You'll lose all of the Plone TTW integration, but if you can build and compile your themes by hand, you're all set.
plone.app.theming requires Plone 4.1. You may be able to use its predecessor, collective.xdv.
collective.xdv Installation documentation
Related
We have a Symfony 1.4 application and want to upgrade to Symfony 4. Is it possible or do we have to reprogram the application?
We asked a software company near us and they told us that we have to reprogram the application.
Symfony 1 is a completely different codebase using different concepts both inside the framework (or application) and with some libraries. For example it uses Propel (Active Record-approach) rather than Doctrine (Data Mapper-approach) for mapping php-objects to a database. The difference between Symfony 2 to 4 is considerably smaller, because they share the same underlying codebase and are therefore closer to each other. Upgrading can still be a lot of work because of deprecations (changed and removed parts of the code), but overall the upgrade process can be done inside the same application. Besides that, you can choose the newest version available and I would argue, if you are starting now/soon, even Symfony 5 beta would be a good candidate.
Basically, if you want to upgrade Symfony 1 you will do a migration to a new system and it will not make much difference if you move to for example Zend Framework 3/Laminas vs. Symfony 4. At least you can directly "upgrade" from Symfony 1 to 4, instead of gradually upgrading from over versions 2/3. It will require a whole lot of manual work, though. Essentially you are migrating between different applications. The Symfony docs have some general advice on how to start a migration project like this: https://symfony.com/doc/current/migration
Basically the approach would be to wrap a new application around the old one (a concept commonly called strangler application) and then move functionality to the new application, e.g. route for route, and falling back to the old application when the new functionality does not yet exist. The main reason for choosing an older version of Symfony, say 3.4, would be restrictions on for example the shared PHP version being used. There are other ways around it, but that would mean substantially more work.
Symfony Framework developer here:
Symfony does provide upgrade steps between versions. e.g:
https://github.com/symfony/symfony/blob/2.1/UPGRADE-2.1.md
But upgrading from 1.4 to 4 is BIG and will require tons of work.
I agree: writing the whole app from scratch will be faster from my experience.
Upgrading can take years for stable outcome (depending on your application size of course)
Have a look here:
https://symfony.com/doc/current/setup/upgrade_major.html
The difference between Symfony 1 and 4 might be to important, therefore you might consider starting a new project and take some of your previous code for a nicer and cleaner project.
Upgrading from 1.4 to 4 is a miracle .
Even if you can upgrade to the version 2 and then 3 untill here it's
could be nice , but the version 4 is totally different , so i can
advice you to rewrite your code directly instead of wasting time
updgrading from version to the upper one.
Disclaimer: I wrote and maintain an open-source tool that handles automated instant migrations called Rector.
Since 2018 these migrations are much easier with help of abstract syntax tree (AST). This technology allows to change one pattern in unlimited amount of files at speed of readfile/printfile.
E.g. 1000 controller from Symfony 1 to Symfony 5 will takes similar amount of time as 1 controller. All you need to do is write migration rules. Some of them are ready in Rector, e.g. Symfony 2.8 via Symfony 5 - see Rector sets on Github.
You can learn more about migration of old Symfony Applications
Upgrade symfony 2.8 or php 5.4 first?
How to Upgrade Symfony 2.8 to 3.4
How we Upgraded Pehapkari.cz from Symfony 4 to 5 in 25 days
For anyone still interested in this task, migrating a Symfony 1.x app to a modern Symfony 4.x and up (including Symfony 5.x), we faced exactly this same task with our company and I found this GitHub project that details how to do it using the Strangler Fig design pattern and the Legacy Route Loader approach that Symfony suggests on their website:
https://github.com/dkusmierek/symfony_migration_example
I can vouch that this DOES work, although there are some tweaks here and there you will need to make to make it work for your specific environment. But it should be enough to get you 90% of the way there.
Is the version 5 of Plone finally having an official multilingual solution that work? I did try Plone 4 but no multilingual solution was official or was working properly. I hope Plone 5 fix the problem.
plone.app.multilingual is a standard part of Plone 5. After installing Plone 5, activate it via the "add ons" control panel of site setup. Then use the "Languages" control panel to set available languages and translation parameters.
For earlier versions of Plone, install Products.LinguaPlone via the usual add-on package mechanisms. While LinguaPlone does not ship with Plone 4.x, it is a well-supported content-translation mechanism and it does work (though plone.app.multilingual is much better). Translation of Plone's user interface does not require LinguaPlone; it is meant to support content translation.
Both solutions also support adding translation support for custom content types.
I have been using flex builder plug-in. But now trial period has expired and looking for some other option which comes free. I am trying to install flash develop plugin for eclipse. In my attempt to install I am trying this page but donno what all plugins to install...http://www.flashdevelop.org/wikidocs/index.php?title=3rd_Party_Plugins ...Can some one please guide. The problem i am facing here is I am not sure about what is outdated and what is useful
FlashDevelop is a standalone application (windows only), as far I know there is no plugin for eclipse. If you are searching for an eclipse plugin, there's the commercial FDT, with a 30 day trial period.
A new FlashDevelop version (4.0) is about to be released and most plugins from the old version aren't compatible with the new one. So I unless there's a new list somewhere or some plugin explicitly states that it supports the new version, every plugin there is probably outdated. Anyway, many plugins from that list have been integrated in FlashDevelop. You can of course use the latests stable 3.x version if you need a particular plugin.
If you've never used FlashDevelop, you should just try the stable 3.3.4 or the latest 4.0 beta or the very latest developement build and see if you are missing some features.
You could always write your code in Notepad and use the command line compiler provided in the free SDK. It's not going to be as nice as any IDE, but it is functional.
Another option, if you are a student or unemployed, is to request a complimentary license to Flash Builder from Adobe.
Another option is to use Tofino, a Free Visual Studio Plugin for Flex Development. However, you'll need Visual Studio for that to work. [And I assume a Windows Machine].
FlashDevelop, as others have noted, is not an Eclipse Plugin as far as I knew. It is a stand alone tool.
Other IDEs for building Flex applications are:
Sapphire Steel Amethyst, which is a commercial Visual Studio
Plugin
FDT; which is an eclipse based plugin. I believe FDT5
will have a free / community option, but I do not know if it is
available yet.
IntelliJ, which many developers swear by.
And of course Flash Builder. I believe the previous three are all commercial plugins, so do not fill your "free" Criteria.
I have to upgrade website running very old version of Drupal (cannot even find out which version is that, but I guess it is even before 5) to the newest one? Is that possible? If yes, how to approach this?
The Drupal web site makes it clear that you cannot skip major versions when doing version upgrades.
See this page: http://drupal.org/upgrade/
(it talks about not being able to skip from v5 to v7; it doesn't even mention v4!)
So if you do manage to upgrade your site all the way from v4.x to v7, one thing is for certain - it's going to be a long-winded process.
The other thing that is going to be a major issue for you is that the Drupal module ecosystem has changed radically in the space of time between v4.x and v7. Many modules that you'll be using in v4 will be either unsupported in later versions, or not have an upgrade path, so you may have a lot of manual hacking to do.
On the flip side, there are likely to be newer modules that can do things in recent versions of Drupal which were not possible in older version or were done in a very different way, and you may find yourself wanting to use some of those modules instead of ones you've got in place. Again, lots of manual work I forsee for you.
In summary, I would suggest that upgrading from such a long way back to the current version is going to be extremely difficult. You may find it easier to start again from scratch and rebuild everything. I'm sure you could get some data imported from the old site to maintain continuity.
One further thing I would add is that this isn't a Drupal-specific problem, so please don't blame the Drupal developers if you struggle with this upgrade - you'll get this issue with virtually any software you run if you don't keep it up-to-date. Try upgrading a Windows95 machine to Windows Vista and you'll see what I mean.
It would be possible, but could be very hard.
You would need to go from 4 to 5, then 5 to 6, and finally 6 to 7. You will have to make sure that your data is still intact along each upgrade and back up your database. Update any contributed modules and check if any have been deprecated along the way and find suitable replacements if possible.
Depending on your site, if it is just the content and you are not concerned with losing url aliases, taxonomy terms, etc. then trying to export/import your raw data directly into a fresh drupal 7 install might be easier.
Edit: You would also need to upgrade any custom themes and modules drastically.
I do not envy your task, as you will need to learn the changes from D4 to D5 only to later discard this knowledge as you learn the changes to become D6 compatible and then discard that knowledge to become D7 compatible.
As you said you do not really care about losing taxonomy terms or extras, you might want to try http://drupal.org/project/import_html or a similar module to scrape your website (though it is not actually static) and convert it automagically into nodes. That module is not currently available in D7, but would get you from D4 to D6.
The key thing to remember is frequently backup your database in case anything goes wrong or you want to try different upgrade paths.
It is doubtful that many contributed modules you are using would survive the upgrade, unless there is a release for each of versions 4, 5, 6, and 7. I agree with #brian_d, the best course of action may be to export your content and import into a fresh Drupal 7 site.
The general procedure for updating:
Assuming you are on version 4.7.x of Drupal:
Update Drupal and any contributed modules you can to the latest release for 4.7.x, in case there were schema changes
Disable contributed modules
Update Drupal to the latest version of 5.x
Update and re-enable modules/themes to the latest release for 5.x
Repeat steps 2-4 for 5.x to 6.x and again for 6.x to 7.x
I've been using Drupal since 4.x. During that time I've had to upgrade numerous times. Mostly I've had good success using the standard upgrade process. However, I've had to do several upgrades manually because of one issue or another. This was basically a Copy and Paste upgrade.
To read more about the Copy and Paste Upgrade go here: Upgrading Drupal by Copy and Paste.
I'm planning to install Drupal. Is there any reason not to install the latest 6.x version as opposed to the 5.x branch? Are there any really good modules that are 5.x only?
Unless you have a 5.x module that you can't do without, and that you know is being worked on to upgrade to 6.x, just use 6.x. i.e. Only start with 5.x now if you know you have a upgrade path with your site to 6.x (and then 7.x). If the module isn't being actively worked on, it mean you'll be unsupported when 7.x rolls around, so you might as well solve the problem of doing without that module with 6.x now rather than wait till your site is developed and up and running.
I've found enough modules to happily run my site on Drupal 6.x I think the only 5.x module I miss is one that did very easy Google ad integration, and that may have been updated I just haven't checked recently. I don't get enough traffic to make the ads worth the time in setting them up, so I just use the search part of the ad campaign.
Drupal 7.x is under development now, so I would expect that anything that hasn't been moved from 5.x to 6.x is just not being developed anymore, and is probably not really that needed.
Ultimately, take a look at what modules you may need. With an account on Drupal's site, you can filter by install type. I found that 6.x is much easier to work with in some regards (managing and upgrading modules) and overall I've had a much easier time maintaining my site under Drupal 6.x than I did under 4.x or 5.x.
I also think that 6.x runs much faster.
My bosses were insistent on making Drupal 6 sites for clients as soon as it was released. This was a headache, because views and CCK were not done, as well as many other modules. Their rational was that we'd have to eventually upgrade to 6, and we wouldn't want to go back and redo these sites. It ended up that we had so many workarounds while using the development versions of modules that it was a pain every time we upgraded modules or core itself.
Thankfully, this is no longer the case. Views, CCK, and most other modules are now ready and stable for 6. The only module we use that hasn't been upgraded is eCommerce, and it doesn't look like it will be, since ubercart is pretty much the Drupal standard for commerce functionality.
We asked ourselves the same question several months ago (just before Drupal 6 was finalized & released)
Our office has limited development resources, and we had released a couple of D5 sites, and a D5 sales app.
We went with Drupal 6.
The decision came after considering the core of what we were interacting with. CCK & Views are the only die-hard critical components for anything besides a default Drupal install, and the level of participation and vitality of the projects was very encouraging.
The stuff that really, really matters, has been/is being ported over to D6, and the wow, this would be nice, p2 stuff is hit & miss.
If you're doing any module development, D6 is a winner.
If you're already very comfortable with D5, then stick with it.
I hope this helps.
The one significant CCK-related module that's not D6 production ready is filefield. This may not be an issue if you're not doing anything substantial with images and media, but might be worth considering if you're going to do any serious DAM. Otherwise, I think we're (finally!) to the point where it's making more sense to go with D6 than D5. Either way, it's definitely worth the time to architect the site according to your specific needs, figure out what modules you'll need and find out if any of them have yet to be updated.
The asset module is not available for D6 yet, not even in a development branch. I've heard a lot about its benefits as a single way to manage all kinds of media files, but most sites can probably happily do without it.
If you haven't been running Drupal before you could find that version 6 has the modules you need. Besides, modules gets ported and created every day so your missing modules could very well be on the way.
For me, the lack of a protx payment module was a deal breaker when choosing which version to use.
The best thing to do is get a full list of requirements before you start, and make sure it's all available in 6.
As a module developer, I feel that Drupal 6's API is more mature then version 5.
So even if you decide to choose 6, and then finds a module is missing, it will be easy to develop it to 6.
Now that I've used Views 2, I ain't ever going back (unless it's to revisit old projects).
I think now, all modules and themes that are of any worth have been migrated and now I'm seeing a trend of new (actually good themes) are drupal 6 only as are quite a few of the must have modules.