Upgraded from 2.7 to 2.8

[Pond]

This failed because I renamed the administrator interface at install time, many moons ago.

I spotted it while trying to solve the "blank pages" issue I mention in the highlighted edit I made to my lengthy message earlier in the thread. The problem is that /admin is a standard location for the admin interface of a WebsiteBaker installation, which makes it too easy to find and start trying to crack. A little bit of security by obscurity can help here (if only a little) so on my deployed sites I used a different admin location.

What I did not realise is that this physically renames the folder in which the admin components lie. If you then later upgrade to WebsiteBaker 2.8, the copy of 2.8 files fails because it uses the old admin name rather than copying a folder using whatever name you have configured. This is kind of subtle, because there are no file copy errors or permissions errors; you simply end up with a default 2.8 admin tree alongside your old 2.7 files in whatever folder name you (inadvertently) defined.

So, I fixed my site in the end by starting from my backup, following the upgrade instructions and then making sure the admin folder was renamed to replace the now outdated, custom named administration folder.

I suppose it was an obvious thing to look for in hindsight, with the admin interface still showing a version number of 2.7; but I'm from a Rails background, where the link between URLs and code is much more abstracted than in WebsiteBaker, where a PHP file exists for each page you fetch. With that in mind, the requirement to rename the directory in which the admin interface resides in order to change the path used to reach it is pretty obvious!

Perhaps the upgrade instructions should mention this potential pitfall. It may help other people.

[kweitzel]

I don't need them since I solved the 2 issues I had, both on 1 webspace, both due to wrongly uploaded files. You would need to find out WHY your upgrade failed. I think because of the same reason. Not all files where uploaded / replaced on your webspace.

cheers

Klaus

[Pond]

Well, I do still have the files from 2.7-with-2.8-copied-over, from the original attempt. If you're interested, I could archive them and send them to you (privately).

[kweitzel]

Hi Pond,

interesting way you went there. Personally I have upgraded about 20 installations and with none of them I had majour issues. Issues that I had where:

1) default template unset
2) half 2.7 / half 2.8 Installation - wrongly prepared the installation (not all files deleted and replaced!)

The first one was fixed by rerunning the upgrade script, the second one by re-uploading the installation files.

cheers

Klaus

[Pond]

Re-running the upgrade script didn't help, as I mentioned, I tried numerous times and with different browsers.

IMPORTANT EDIT: I'm not sure the method in the message below actually works; you do need to copy across the media and pages folder contents from the old site to new, but even with that in place, I found that I tended to get blank pages served for the public site even though the admin interface worked fine. Instead, see later in the thread. The message below is left in case it still somehow proves helpful to someone.

Further to this, I've got it working as follows. First, if you're reading this looking for a solution, do you have the same problem?

• Follow the 2.7 to 2.8.x upgrade instructions including running the upgrade script
• If your administration pages still say "2.7" at the top right then probably you have the same problem as me
• Another indicator is that the 'Settings' page's "Default Settings" section contains a drop-down menu for "Template", but either does not contain a drop-down menu for "Backend-Theme" at all, or the menu is empty

If you're already in the position of seeing the template name error due to having saved settings on an errant installation, then re-running the upgrade script should patch up the database and let you back in (at least until you save settings again - so don't do that!). Run the upgrade script and check that the admin interface loads. If you still get the template path error, then you'll need to hand-update your database somehow. Various instructions are elsewhere in this thread; if you end up doing this at the MySQL terminal, the SQL you'll probably need is:

Code Select Expand


UPDATE settings SET value="wb_theme" WHERE name="default_theme";


This is important, so I'll repeat myself - you need to be in a position where you've attempted to upgrade from 2.7 to 2.8 by copying over files and running the upgrade script, and your administration interface is currently working (though it might look strange, e.g. still say 'version 2.7'), but you know that it will fail to work if you try to save the settings again. Do not proceed further unless this is the case.

So, I'll assume you now have a working half-2.7-half-2.8 admin interface but you can't modify settings without breaking it again. The next thing to do is basically reverse the upgrade instructions. They tell you to copy WebsiteBaker 2.8 over your WebsiteBaker 2.7 files. In this case, we do roughly the opposite, so first we need to get a clean installation of 2.8 running:

• Move all of your web site's files to a safe location
• Install 2.8.1 from clean into the location where your site used to live, as if installing anew
• Go through the installation procedure giving the correct database details except for the database name - use a different name here, or you will trash your existing site!
• Complete the installation and confirm that the admin pages work, including seeing the relevant entries in 'settings', albeit for a new, "empty" web site

Now you need to make this "empty" v2.8 installation look like your old site:

• Copy back any custom modifications you made from your 2.7/2.8-not-quite-working old site
• Pay particular attention to any template changes you may have made and check the WebsiteBaker upgrade documentation to see if you need to make any modifications / merge changes
• Open the new installation's config.php in a text editor and change the database name so that it now points at your original, 2.7-upgraded-to-2.8 database
• Reload the admin interface and check your site; you should find that your site is back in place (since the database WebsiteBaker is reading now contains your original data) while the admin pages still say "2.8" at the top right
  
• You should be able to save settings without anything going wrong.

Hopefully that'll sort it for you. The less you modified in your 2.7 installation, the less you need to copy / merge into your clean 2.8 installation; in my case, I had a single custom template I'd written, so I just copied over those files (because the 2.7-to-2.8 updated database already 'knew' about that template). The upgrade script had already correctly patched up the database so it was suitable for 2.8; the problem lay in the files, where the attempt to copy 2.8 files over the 2.7 files had, it seems, not worked as expected (despite use of cp -f with no errors reported).

[kweitzel]

No ... sorry, I meant the upgrade script, not the install!!!

cheers

Klaus

[Pond]

Running the install script should fix the issue.

You mean by visiting "http://mysite.com/install/" and clicking on the "Install WebsiteBaker" button? Won't that trash the existing site? The page shown certainly hasn't picked up my existing database connection details, website title or anything else - it's basically a blank form.

[kweitzel]

Running the install script should fix the issue. If not, you should let our developers know a bit more about the installation and the environment.

cheers

Klaus

[Pond]

I also find that upgrading from 2.7 to 2.8.1 breaks my installation.

The symptoms are the same; the default_theme named entry in the settings table ends up with a blank value whenever the admin interface is used to update settings. I obviously cannot roll this change out to my client as their installation would break any time they touched the settings page!

I have forcibly overwritten all files from the 2.8.1 tarball except config.php and the 'install' tree, which I deleted as instructed by the upgrade instructions. I made sure no instances of my site were open in browser tabs and cleared cache and cookies as instructed, then directly ran the upgrade script. This reported lots of green "OK" messages.

However, though the visual style on the login page appears to have changed slightly, the main administration interface looks the same. At the top right, it says:

Code Select Expand

     Version 2.7
     Revision REVISION

Clearly something is quite badly broken here. If I go the Settings tab and try to save changes, I get the usual "Settings saved successfully" message shown briefly before the template failure occurs. If I reset the template value at the MySQL console, I find that the settings do seem to have been updated, but obviously something is wrong as the theme value got trashed.

The MySQL server version is 5.0.18, protocol version 10, running on a Debian Linux derivative and contacted over a local Unix domain socket. I've tried repeating the entire upgrade process several times with no success on a mixture of Safari 4.0.5 and Firefox 3.6.3 on Mac OS X 10.6.3.

Any advice? Suggestions? Is there an official bug tracking this problem? Is there a patch I should try?

The client is awaiting an update so this is a rather critical failure for me and the lack of any further information or updates since the last post in this thread (January) is quite worrying. Many thanks in advance for any help forum members may be able to offer.

[tost]

Same problem here. If I do something in adminpage and save.... Can't get into backend again. 
I can find a lot of this problem in german language (maby solutions), but I don't understand german.

If someone has a fix for this please make a "howto" in english.

Best regards
Tost

[mviens]

Hello,
I am having the same issue upgrading from 2.7 to 2.8. I checked in the Settings table and updated the default_theme with "wb_theme". That fixed the problem but everytime I "save" any changes in the Settings panel, the problem recurs and I have to login to the database and update the default_theme which gets reset to blank.

And a bit more information as I'm testing...
1) In Settings page, "Backend-Theme:" shows a blank field with no options to select.
2) If I click on Settings for an individual page, "Template:" shows System Default but no other options to select.

Thanks for any assistance.

Michael

[PJW]

Excellent  .  Glad to be able to help.  Thanks for posting to let me know!

[Deb]

And you would be ABSOLUTELY RIGHT ON! It worked! Thank you so much and for your patience with me!

[PJW]

There are 2 different places for template settings: 1 for your pages - the look of your site, and 1 for your admin area - the back end.

The default_template setting is for your pages, the default_theme setting is for your admin area.

I'm am only going on the basis that you had the same problem as I did, and this is how I fixed it.  When I went into the settings table the value for default_theme was blank and needed to be (re)entered.

Once you are able to log in again, you should be able to change to whatever template you want in the admin area.

[Deb]

Oh, I thought that value had to be a number. I can see the setting_id, name, value boxes. My default_template is set to my own template (customized for the site) called "KAS" ... if I change it to wb_theme I'm going to lose my theme aren't I? This would have been "brought forward" from my 2.6.7 install, I didn't change this at all. This would also be for the site pages I'm assuming not the admin login.

[PJW]

Perhaps you don't have your phpmyadmin window wide enough?

There should be 3 columns with text headings: setting_id | name | value

I'm guessing that you're referring to the setting_id column when you mention 48.  In the value column enter wb_theme.

[Deb]

So where do I find the magic "value" number? It shows a value of 48 for default_theme.

[PJW]

changed it from default_theme to wb_theme

No, that looks like you've changed the name of the field, rather than the value.  You need to change that back to default_theme and change (or enter) the value to wb_theme.

[PJW]

OK,

You're not looking for "prefix" anywhere.  The prefix is just part of the name of the settings table e.g. wb_settings (where wb is the prefix).

Inside that table there is a field default_template - that is what you need.

From memory, you get to that in phpmyadmin by clicking the table name on the left, then clicking the "Browse" tab at the top.  Find default_theme in the name column and change the value (in the value column) to wb_theme.  In the db I'm looking at it's setting_id #46.

Of course, wb_theme will only work if you still have wb_theme installed.

HTH,

[Deb]

Ok, looks like I found it, changed it from default_theme to wb_theme and all that happened was that my error msg changed to:

Template Error: set_root: /var/www/vhosts/kentuckyadoptionservices.org/httpdocs/documents/templates/DEFAULT_THEME/templates is not a directory.

And I did not use caps in the change either, the system did that all by itself.

Deb

[Deb]

Unfortunately, I'm still lost. You're dealing w/a pretty much total phpmyadmin/php dummy here. I can edit stuff already in place if I know exactly where to find it in most cases.

I'm assuming by what you're saying that the prefix would be found in the "settings" table which I've been to several times, along with all the other tables.

I'm sorry to bug you but would it be possible to give me more specifics?

Deb

[PJW]

Hi Deb,

By putting dbprefix in curly brackets {} I meant to show whatever your database prefix is.

So if your database prefix is "deb" the table you're looking for would be deb_settings.  If your database prefix is "wb" the table name would be wb_settings.  The field within that table that needs editing is default_theme.

HTH,

[Deb]

Ok, so I've got the same problem you had .... exactly were IS the dbprefix so I can try your fix. I can't find it anywhere in the db.

Thanks,
Deb

[PJW]

Cracked it, but not sure how the problem arose, I assume I accidentally clicked something I shouldn't have.

To fix it I edited the {dbprefix}_settings settings table directly and changed the value for default_theme from blank to wb_theme.

Hope this helps someone one day!

Paul

[PJW]

OK, fixed that (I had to re-upload all of the files that already existed on the server and force them to overwrite).

Different(?) problem now

I got into admin and changed to my preferred template, which I had already uploaded when at 2.7.  As soon as I saved I got:

Template Error: set_root: /usr/local/psa/home/vhosts/domain.ext/httpdocs/templates//templates is not a directory.
Halted.

...and now I can't log into Admin again.