Installing two versions of a theme side by side produces PHP error

Changed bug report accordingly. Since this is not documented or expected behavior and is a severe problem for everybody who upgrades a theme, this is a bug, not a feature request.

Thanks for the workaround proposal:

The only thing that might work is to change Zen 5.x-0.7's directory from the "zen" to "zen07". And then edit all the zen 5.x-0.7 files to change any function that starts with "zen_" to "zen07_".

It still has the problem that all users who have individually selected a non-default sub-theme would fall back to the default. It may be a good idea though to do the change on the new version under test, then revert and do a hard change-over after testing.

You cannot have two themes with the same name on the same site because there's no way for the system to tell them apart.

Now this is one of the most unimaginative postings I've seen in a while, essentially a repetition of the issue description.

Come on, do you really lack every trace of creativity and want to tell everybody that this is an absolutely unsolvable problem? I could tell you within seconds a number of different ways to solve it.

But they are all so simple that every programmer worth his salt will find them just as quickly. There is no need to explain.

I'm not a PHP programmer, so doing it myself is not in the cards.

Now for the proposals. Let me make the simplest first.

Add the version number to the theme name. Have zen07 and zen08. This alone already solves the problem.

A small remaining weakness is that, when, after testing, you make zen08 the default and pull zen07, users of sub-themes would fall back to the default theme.

This is a minor problem on most sites, because few users select a non-default theme in the first place. But it could also be solved in adding some code that makes sure that, for example, a user who runs the zen07-xyz sub-theme, automatically falls over to the next version with the corresponding name, zen08-xyz, if that exists. That's a pretty tiny piece of code to add.

This is just one of many possible solutions to the problem. I'm still surprised by the fact that somebody asked for possible solutions at all, because they are really not difficult to invent.

If somebody had replied, "no time to do it" or, "not worth the effort", that may be debatable, but "impossible" leads to instant berating. (:-)

Hans-Georg

John,

I'm already running a multi-site Drupal installation. Your recommendation not to do development work on a production server has its merit, but it can also have a big fault—it may not be optimal overall. In my situation installing a separate test system would waste far more time than it is worth, particularly when its only purpose is a theme update. I have, of course, weighed the risks and the effort against the advantages and came to the conclusion that in my case it is much better not to install and operate a separate test system.

As to using the multi-site installation to test a theme upgrade, are you forgetting that the themes are common to all sites in a multi-site installation? I haven't looked into this any further, but the themes I'm using are common to all sites, they are installed in the common themes folder.

I am a programmer. I am just not a PHP programmer. But anyway, the failover to a sub-theme is a quite unimportant side problem. Ignore it before the main problem is solved. And if there is no chance that it will be solved, then we may forget this whole discussion anyway.

The first and fundamental question is, would it be a great advantage to be able to install two versions of a theme side by side? I still think yes. If nobody agrees, this discussion is only a waste of time, except that it pointed out an omission in the documentation, namely to tell users that they can only install one version of each theme.

Let's not argue for the sake of arguing. My immediate problem was that I upgraded from Zen 0.7 to Zen 0.8, but 0.8 didn't work. I had to revert to 0.7 and tried to install 0.8 side by side for testing. As we now know, that didn't work either. Now I have no simple and quick way to test what's going on, short of opening up a separate virtual server, setting it up for Drupal (with a list of modifications), installing an entire Drupal, and copying at least one complete site into it, which is far too much effort for the purpose. This is why I was looking for a simpler, quicker way.

Hans-Georg

Since your original problem (http://drupal.org/node/199323) wasn’t in the Zen issue queue, I never saw it. It sounds like a duplicate of this issue: http://drupal.org/node/199362

John,

I didn't want to open a Zen issue, because I wasn't sure it was a Zen issue. I thought I had done something wrong.

Thanks for your good explanation. Since I'm running a globally installed Zen 0.7 in several sites on a multi-site installation, I guess the procedure for a parallel install of Zen 0.8 would be a bit convoluted. I would have to copy 0.7 into each site, remove the global installation of Zen 0.7, create a new site as a test site in the multi-site installation, copy one of the sites to be tested into it, and install Zen 0.8 into it. Then I would have to copy the next site into the test site and test, etc.

I won't find the time for such a procedure soon. It is more effort than I think it should be. A side-by-side installation of two versions would be very much easier, but it seems I'll never get that. My remaining recommendation is to write clearly into the documentation that two versions of one theme cannot be installed side by side. That would change this bug report into a feature request.

I'll probably do a hard switchover from 0.7 to 0.8, as soon as that other problem mentioned in http://drupal.org/node/199362 yields enough information. I'll see if I can contribute to that issue to help resolve it.

Hans-Georg

You already gave the solution to your problem anyway... Just rename one of the themes to zen8 and then you can have them both installed at the same time.

Michelle,

John already mentioned a rename procedure, involving renaming all functions (and all function calls, I presume). That sounded a bit like an untested procedure to me, which involves the risk that it doesn't work, that's why I didn't exactly jump on it. But I'll look at it again when I find the time.

Let me add a more general statement.

The problem of a busy drupal operator is to balance the minimization of effort against the minimization of downtime. Software developers can avoid that dilemma and all responsibility by shifting all the risk and extra effort onto the shoulders of the operator by insisting on the maximum effort way, an extra test installation. They will say, this is best practice, we recommend it, you have to do it, if you don't, it's all your fault, yada, yada, and if an update fails, "See, I told you so."

In practice, depending on downtime tolerance, many operators will, sensibly, not give in and will instead balance and bear risks, because they have the more difficult task of overall optimization.

The ultimate question is whether a Drupal operator is better off running 10 sites at "best practice" or a dozen with a risk of downtime due to update problems. Often the dozen is the better choice overall. I would like all Drupal developers to understand this dilemma and this optimization and take it into account when making design decisions. Making life easier for operators represents economic value. Merely shifting the blame does not.

Hans-Georg

Crell,

don't worry, I had already accepted that the original issue is dead. My last statement on the tradeoff between developer effort and operator effort was a general one. It was only meant to illuminate that additional developer man-hours can save many operator man-days, when you consider that there are many more operators and installations than developers.

This discussion is now tapering off into an exchange of more general views. I have long accepted the won't fix status. There is no harm in exchanging a few more views here until we, soon, end this thread. Alternatively we could start a forum topic, but I guess there isn't that much more to say here.

Consider that many Drupal installations are not run by IT departments, but by a single operator. Many of these operators are not PHP programmers and have limited experience and knowledge. I am one example. To put it the other way around, the more Drupal is designed to be installed and updated very easily by less experienced operators, the more Drupal installations you will see around the world.

I'm far from being a professional server administrator. I barely know MySQL and know only traces of PHP. I have no IT department behind me. The good thing about Drupal is that I can still install and run even a multi-site installation with good success without the means of an IT department. Updating has now become my main worry of running Drupal.

In my situation, creating a test installation and finding and repairing the error that came with Zen 0.8 requires far more time than 15 seconds, most likely hours or a whole day. Add to that the time to transplant all modifications of sub-themes into the new Zen version. And add the risk that all this may be in vain if I cannot fix it.

I don't know if anybody has good statistics about Drupal installations. I'd be interested in knowing how many of them are run by single, non-professional operators. My guess is, quite a few. I also guess that many Drupal installations are still on version 4. Why is this so? Mainly because updating to 5 is not easy enough. I'm pretty sure, if there were a safe one-button upgrate path, every operator would press that button.

As to shifting the blame, yes, we have a conflict of interest here. The developer wants to implement nice new features and ignore all upgrade problems, because they would cost him extra effort, which is less visible and much less spectacular than new features. The operators have exactly the opposite interest. All I want now is that everybody understands the nature of this tradeoff.

The current developer strategy is to provide new versions and leave the update effort and problems almost entirely to the operators, except for update.php, which is one of the pieces of Drupal which I admire most (except for its strange threat of destruction if run twice in a row). I'm trying to explain that this may not be the optimal strategy, when you compare total developer effort to the overall worldwide success of Drupal. Let me give one example: If Zen had an automatic version upgrade ability with a high success rate, more operators would switch to Zen as their base theme, because it saves them time. And if the whole Drupal had an easy upgrade function, that would attract more CMS operators to Drupal. Upgrading is a major issue.

Hans-Georg