By mo-seph on

Hi all,

I'm upgrading to D7 from D6, and finding it incredibly difficult. My site makes heavy use of three modules, which have disappeared:

* audio: has moved into core, but doesn't seem to have all the functionality there. I also have to run a rather sketchy experimental module from someone's git repo to migrate content (http://drupal.org/sandbox/jenlampton/1761334 - I'm saying sketchy as I had to twiddle version numbers to get it to run, and it's not entirely clear whether it worked or not yet).

* img_assist: hasn't been ported, looks like it won't be, and there doesn't exist a sensible replacement (works concisely in non-WYSIWYG, has useful options to pop up images, lightbox etc.). There is a port, but it's unmaintained, only linked on a semi-dead forum post (http://drupal.org/node/841568) and I don't know if it works. There are also scripts to turn everything into HTML so that might be the way to go. But it's certainly not as nice to work with.

* mediawiki_filter: unported, although a possibly-good version of it is kicking around.

I understand that mediawiki was never official. But, at the time, all three seemed to be the best practise for their respective tasks. Now, it seems to be impossible to upgrade my site - I've spent many, many hours reading posts, trying updates etc. And I haven't even looked at more advanced bits of the site.

At this point, I need to figure out whether using drupal is viable for me. Is the idea that now everything is done with CCK upgrades will never be this hard again? Did I just have bad luck with module choices?

How could I do things differently so I don't get stuck again?

Thanks!
dave

⋅ Categories: Drupal 6.x

Comments

john_b’s picture

john_b commented

Best way is to build a new site and migrate your content and users etc. The 7 to 8 upgrade will probably be a pain too. Maybe 8 to 9 will be better, but this is a huge and known issue with Drupal. I have seen a sandbox designed to allow D7 to run a D6 module, looking for helpers, as it is not a full project yet AFAIK. At the end of the day this is a big issue for Drupal and one just has to make a decision either that the good things about Drupal are worth the downsides including this huge one, or to steer clear of Drupal. Or better still, to take the view that it is only fair to give something back with free software, and help fix the problem!

You can reduce the difficulty of upgrades by keeping the site as simple as possible and using only major and well-maintained modules.

Digit Professionals specialising in Drupal, WordPress & CiviCRM support for publishers in non-profit and related sectors

WorldFallz’s picture

WorldFallz commented

Everything john said is true-- especially the last sentence.

That said though, I think you also hit a bit of bad luck. Along with all the changes to d7, there was also the completely separate but coincidental emphasis on moving media handling from the myriad of individual contrib modules (like audio and img_assist) to the media family of modules.

As for the mediawiki thing, i couldn't find http://drupal.org/project/mediawiki_filter. However, the fact that it was never official doesn't exist at http://drupal.org/project/mediawiki_filter means, that it was definitely NOT 'best practice'. Modules like that will always be risky.

And while the challenges of upgrading a site will still exist, it's not likely you'll be bit by that particular confluence of conditions again. Though there's always the possibility of a different confluence of changes.

There is also a core effort to move from the 'upgrade' type upgrade to a migrate module type upgrade-- which I personally think is the way to go and will mitigate these issues going forward.

imo though, sticking with popular, well maintained, modules (or those maintained by well known maintainers), is the single best way to protect your upgrade path.

mo-seph’s picture

mo-seph commented

It's a bit worrying that upgrading to D8 will be just as bad, although hopefully I can simplify things to make it easier. mediawiki_filter was tricky - it was the descendant of PEAR wiki filter, which was official, but discontinued, and the dev didn't manage to make it official.

I understand the idea of keeping it simple, but one of the main features of drupal seemed to be the huge array of modules to do useful things. I guess its a question of balance.

Thanks!

WorldFallz’s picture

WorldFallz commented

No one said anything about keeping it simple! You just need to be critical in your selection of modules. drupal.org is pretty open about hosting modules (which is a good thing imo), but that doesn't mean that every piece of posted code is something you want your site to depend on.

You can build incredibly complex sites just using the top 100 modules. And you certainly can use rarely used modules (i have in certain cases) but 1) realize what you're doing and 2) evaluate the value of using the risky module in terms of it's functionality (standard risk vs reward evaluation).

Also, when using a 'risky' module I make sure that I understand it enough that I could support it myself if I had to.