Moving Forward
Time for a project to move OE Hive onto a more modern version of Drupal. I propose the following outline for this work:
1. Review modules in use as previously, but update for current D6 and D7 status.
2. Evaluate the importance of any problem modules and consider possible replacements. Determine if there is anything that can be left out.
3. Determine a plan for initial implementation. Consider D7 if possible, but D6 is more likely.
4. Copy production to staging.
5. Upgrade staging to the proposed configuration.
6. Test
7. Move to Production ... with lots of backups!
8. Evaluate new modules to improve the site.
Known issues include:
Hivemenu and yellowpages are derivatives of D5 sitemenu module. sitemenu has changed considerably since D5 and so an evaluation will be needed as to whether to try applying Jurjen's customizations to the D6 or even D7 version or whether to just fork development and create new modules (which might be contributed back since both are very nice ... thank you Jurjen).
It appears that it is rare for sites to use both the Project modules and the Organic Group modules at the same site, perhaps because there is a less robust version of projects in OG. We are proud of our project capability even though most existing OE Hive projects have no real use for Project features. If it all works, fine. Otherwise we may have to take a hard look at alternatives.
As issues are identified, we should track them through the Hive issue tracker. This should include enhancements to yellowpages which we might fold into this work.
- Login to post comments
Re: Moving Forward
I want to take a slightly different approach. The most maintainable oehive going forward will be the Drupal version and updates provided by WestHost. WestHost is on version 7.
The biggest configuration and maintenance headache for Jurjen and I has been the modules. My goal is to move all of the content to Drupal 7, using as few add-on modules as possible.
Jurjen and I will take a snapshot of the database. We'll strip out the email addresses and passwords so that we can freely share the data without having to worry about spammers getting their hands on it.
We'll get a copy of Drupal 7 as provided by WestHost. It will be the target. The source for the Drupal currently running oehive is already available via SVN.
The key effort is the data conversion program, to get the data from our database to the Drupal 7 database. It has to make sure none of the content is lost, and that it's all easily found and navigated after the migration. This involves two things. The first is the data conversion script. The second is the modules (few as possible) which need to be added to Drupal to make the migration work.
By using a snapshot of the database, we can do the work on our own machines without having to worry about tripping over each other or accidentally breaking something on oehive. WestHost does not provide normal unix user accounts. Having multiple people working hard at the command prompt with the same (root!) login is a recipe for an accident.
I want to focus on the data (the content), focus on the features of Drupal 7, and wash our hands of any Drupal modules which the maintainers have not kept up to date. I hope that Drupal 7 has features which can accommodate the content of things like HiveMenu and YellowPages, but failing that of course we'll be looking at add-on modules.
ok, good idea
Good ideas John.
Although I doubt if the Westhost-Drupal has advantages over the drupal.org/download edition. In the early days when we began, the Westhost-Drupal would be published as yourdomain.org/drupal which was a no-go because we wanted it in the root.
Get rid of unmaintained modules. Maybe there are similar modules in D7 to replace them, or maybe they can be missed.
If Projects and OG can't live together, then keep projects and remove OG. We have never used any of the access-permission features of OG, although this very forum topic could use it :-)
Distributed developing (on our local pc's) is a good plan, code will merge. But I doubt if database can merge, so I think we need a shared integration server with real data. The staging server is that. What we do locally and in staging is a rehearsal for the conversion steps that will be done in live.
I would not remove passwords and emails because they can't be put back after they are removed, but we must make sure the test/staging setups will not send outgoing mail. Or maybe I did not understand what your intention was with the database paragraph?
Re: ok, good idea
Wow, I don't remember Westhost having Drupal when we first started this. All I remember is playing with Joomla on Westhost. Oh well, I'd like to take a look at it anyway, just in case things have improved.
On our local machines, we'll be running through this process repeatedly:
db snapshot -> migration scripts -> migrated db, Drupal 7, and modules
We'll collaborate on the migration scripts and the Drupal 7 modules. We'll all be using a copy of the same db snapshot. Each time we need something different in the migrated db, we'll enhance the migration scripts, and run them against the db snapshot. A lot of the migration scripts should come from the Drupal update programs themselves. But, we'll also need to write scripts to get data from abandoned modules to new modules.
I suspect the migration scripts will really be a migration checklist with a bunch of supporting scripts, but it would be nice if it was mostly automated.
So, I don't think we need a shared integration db server. Once we're close, we'll run the migration process against 'staging' as a final test run on WestHost. Once we're comfortable with that, we can run the migration against live.
What?
Where is all this coming from? Have you ever updated Drupal? My memory of the D5=>D6 transition was not much different than applying a new release. I.e., turn off all the contributed modules, move the pointers to a new release, copy over the site directory, run update, then turn on each contributed module and run update when needed. I did four sites in one sitting. There is no big application of migration scripts on separate platforms and all that.
Besides, until we do steps 1 to 3 in my original list, we can't do anything since we won't know whether the target should be 6 or 7 and what issues we have about modules.
Why don't we just let Alon do that part, decide what we need to decide about modules, and then let him give it a try in staging. If there is a problem, then OK we can back off and see what we need to do. Other than needing to fiddle with which modules and decide what to do about sitemap and yellowpages, I think the whole business is a one day event. Couple of hours after its been done before.
I hope so!
I hope it really is that easy! I'll let you and Alon know as soon as I have a snapshot of the database available, and you can give it a whirl.
There is nothing to give a
There is nothing to give a whirl too until we complete steps 1-3.
Still scratching my head
I see no reason to be interested in the WestHost Drupal at all. What advantage does it have? They are not going to be able to provide any meaningful support that we would not get from Drupal.org and are not going to have latest versions.
Yes, step one is to review modules and see if anything is no longer maintained and whether or not we are using everything we have installed. I don't know how we can make any reasonable decisions until we have done that.
The purpose of OG to me is mostly to allow people to get e-mail on what they are interested in and not on things they are not interested in. This seems non-trivial, although we aren't taking full advantage of it and we certainly aren't doing a great job of educating our 3600+ users. There are simple modules which allow subscribing to changes by page, but I doubt they work for the taxonomy term pages, which would be a big limitation.
Frankly, neither OG or Projects are being used heavily. Most projects other than ProLint would be equally useful with an attachment and a couple of page comments.
What, other than possible updates to hivemap and yellowpages are we going to do any development on? What's to do? When I moved my sites from D5 to D6 the supplied scripts did all of the database issues. No dump and load or anything.
This sounds like it is being made much more complex than it really is.
There is a lot I don't get here.
First, if we have a need for Product X with minimum version B and WestHost has that and we have no particular need for latest release, patches, etc., then fine, use it. I think this applies to PHP and MySQL. But, Drupal and its specific version is core to OE Hive. We can't use something generic; we have to put together the specific modules and configuration we want. We need to be applying patches. The difference between starting with whatever WestHost has ... almost certainly not the latest version so that we would immediately need to do updates for optimum security and stability ... and downloading it from Drupal is trivial.
Second, we have no idea at this point whether D7 is a reasonable target or not. Yes, I would prefer to move to D7, but being able to do so depends on all of the key modules being ported to D7 and in a sufficiently stable form that it is reasonable to commit to them. We need a fresh review of modules, version availability, usage level, release type, signs of active maintenance, etc., before we decide D6 or D7
Note, there is likely to be better Drupal support for D5=>D6=D7 than for D5=>D7 directly so we should consider doing the transition in stages even if we are able to go with D7 at this point.
And, I don't understand the description of the database migration. What is less secure about staging than the live site? If anything, it is more secure because people don't go there and there are no links pointed there so the spammers will be busy on the live site. Moreover, we can lock down Mollom to prevent change to anything while we are in development.
My experience has also been that Drupal itself is going to provide us with the migration scripts. Yeah, I suppose it is possible we might have to do some manual intervention, especially if we skip D6, but I wouldn't count on it.
And why this concern about bunches of people working at the same time. Our problem has been no one working. That was the whole point of adding Alon to the project. Yes, he may want help or there may be some piece that one of us should do, but it isn't as if all four of us are going to be in there poking around randomly at the same time.
I also don't get the attitude about add-on modules. Yes, some modules of value are no longer being maintained and we may need to leave them behind. It happens in the open source world. Often, part of the reason for this is a new module with better functionality. Fine. But, I don't think we need to be so universally cautious.
There is a huge difference in what a module is. Something like Projects and OG are core to the functionality of the site. Clearly, we are making trouble for ourselves by using both. There, perhaps, we want to review to see whether this is still the right decision. After all, while the idea of Projects is very attractive, in practical terms what project other than ProLint has more than two entries in their issue tracker and any real need to support anything other than the current release? Yes, I keep hoping something else will take off, but ultimately we could get by with a lot less capability than we have with very little compromise.
And, there are a bunch of modules which are not core, but which can add value. Take something simple like support for multi-page like this, http://www.cintegrity.com/content/Object-Oriented-Vocabulary-Introductio... , i.e., one node, one page of entry, but more readable pages displayed. All that is is a filter on the output HTML generation. It has no schema, no impact on core functionality, and minimum potential for negative interaction with another module. Moreover, if it breaks, we remove it and the only negative is that we now have some very long nodes filled with [ pagebreak ] marks which the author might want to clean up. Big deal. Why not use it?