Update failed - white pages

[Czorneboh]

Hi all!
After a backup with Filezilla I have uploaded unzipped 1.7.2-files and got the typical update-page, which showed me no issues so far. After clicking on the button for updating of the database I have got no failure-message, but the info, that I have updated to 1.7.2. After next click in the backend I have got a white page.

I have done that with Seamonkey.
Using afterwards FF, I loaded the homepage - visible. Articles as well, but all static pages and categories, archive - white pages.

I clicked then in the footer to Admin and got now again the update/upgrade agent with failure infos in yellow letters (verification failure notices), quite a long list:

At the end the 3 lines in green:
"Permissions
/home/joerg/www/joerg/ Writable
/home/joerg/www/joerg/templates_c Writable
/home/joerg/www/joerg/uploads/ Writable"

But before such notices in yellow:
"htmlarea/plugins/ImageManager/Classes/NetPBM.php corrupt or modified: failed verification
include/admin/category.inc.php corrupt or modified: failed verification
include/admin/comments.inc.php corrupt or modified: failed verification"
and so on ...

My system:
PHP 5.4.4-9
Update from 1.6.2
template: Kinetic 1.3.

There is a cache server in use (with nginx). Changes, which I make in the backend, usually gets visible for every visitor with a delay of several hours.

Because of the white page I cannot more access the backend via browser.
(a moment later): I click in my Seamonkey browser again on "Admin" and now I get the same page of update agent like described before, with yellow notices.

Last sentences at the end of the page:

"It appears you do not need any upgrades run "
Button with "consider serendipty upgraded"

The footer shows yet:

"Powered by Serendipity 1.6.2 and PHP 5.4.4-9 "

Before I click anything/leave the page, I better ask now, what to do.

[Timbalu]

You system still pronounces itself as Serendipity v.1.6.2.

The first thing I would do, is to check, if you really have uploaded all files correctly in auto modus (between binary and the "other" option) and force overwrite mode with that FileZilla FTP. It looks like, you did not have the last option turned ON.

Also very useful to have checked before, that all plugins have been updated by Spartacus!
At last, I don't know about the Kinetic Version History, but I know it also needed some deep updates for the 1.7 / Smarty3 Series to run successfully.

Edit: "...with yellow notices" - what do they say?
Edit2: Ah, I found them announced in your backend! This is definitely the FTP force overwrite issue! Best is to upload a full Release, not the lite one.

[Czorneboh]

At last, I don't know about the Kinetic Version History, but I know it needed some deep updates for the 1.7 / Smarty3 Series to run successfully.

I will give Don the notice. Perhaps he can brief me. If there are issues, it may have been to early for an update of my blog?! And I should go back to 1.62.?!

But I will again try to upload the update-fileset with Filezilla, as you recomment me.

The first thing I would do, is to check, if you really have uploaded all files correctly in auto modus (between binary and the "other" option) and force overwrite mode with that FileZilla FTP.

I should have used the plugin for autoupdate. Now it is to late, cause I already do not get into the backend.
Auto modus of File-Zilla - I have choosen: "overwrite" (first alternative. Probably better would have been: "... only if original file is older") and tick in "Immer diese Aktion ausführen" = "always conduct this action" and there "Nur auf diese Warteschlange anwenden" = "only in the queue".

So, if I made the mistake here in Filezilla, then I guess, I should upload the backuped files and when the blog runs normal, try again with the right "overwrite"-alternative.

What do you think?

[Timbalu]

As long as you didn't get an update in the last 2-4 month on kinetic (*), I would recommend to return to 1.6.2.

And Yes, these FTP options mentioned would do well. I personally would not use the "if file is older" option, to really be sure all files are updated, since this may conflict with the checksums check in Serendipity, as well.

For the autoupdate please refere to http://board.s9y.org/viewtopic.php?f=6&t=19467

Good luck!

(*) The most possible issues where discussed in March, see http://board.s9y.org/viewtopic.php?f=3&t=19211

[Czorneboh]

Thanks,

I tried meanwhile several times update of the backup. But I have got everytime an interruption. First was from a programm on my pc, but others because of reasons on the server, last time a timeout.

So, yes, such interruption could have been when updating the folder with s9y 1.7.2. I have written to Don, will see, what he will answer.

I will try later again the upload of the backup.

[Timbalu]

Joerg, I would not wait that long, since everybody can view that backend installer/upgrade page issue and can try to click this "Consider Serendipity upgraded" button to close and finish the Update, even if having that much not correctly updated files!
I do not think you want this to happen!

And your blog isn't fully working too.

[Timbalu]

Since this needs a little hurry, you could try to ask your Server Admin or ISP helping you this single time on this issue, since it is urgent, to unzip and copy a 1.6.2 or 1.7.2 release zip (all files and dirs underneath serendipity/) into the right directory for you by console, which is the absolute quickest way to do.

[Czorneboh]

I could get in to the blog backend, in version 1.7.2.
But after a click somewhere I am out.

Meanwhile my hoster connected me. Blog is damaged. categories, archies, static pages missed.
By which function of the ftp-programm they where deleted, I am ask myself?

Recovery is in process now. Maybe, that I need to ask something about this. backup of database there is from 3 days ago.

[Timbalu]

Well, I don't think you will need to touch (return to backup) the database.
AFAIR there were no db updates upgrading 1.6.2 to the 1.7 Series.

But the issues with upgrader/installer are still the same. Even in that link I sent you per PM.
The "damaged" blog issues happen because of these unfinished uploads (and possible kinetic update pending).

Also the htaccess taking care of the url redirecting will possibly be written new when the last submit on finished upgrade has taken effect.

[Czorneboh]

Aha!

Also the htaccess taking care of the url redirecting will possibly be written new when the last submit on finished upgrade has taken effect.

Yes, this could be. How long does it take? Do you address "my" cache server in front of the blog?

So I will wait a couple of hours for a suprise.

[Timbalu]

I don't really understand your last notes.
The frontend issues might also resolved slowly by your "cache", but I don't know how this is done in detail on your side.

Fact is, that your backend still states all these different files as being "corrupt or modified: failed verification" and still wants to finish the upgrade procedure.
All these files (also a lot of core files) did not upload correct with your ftp manager. So this is still pending to do first.
If you now proceed with the upgrade without solving this first, you will definitely have others and more problems on the frontend and backend side.

[Czorneboh]

I am guessing, that cache server may caching too much parts of the blog. So I am often not know, when the made changes get visible (or would they, if I would use a browser with deleted/emptied cache).

For WP there is a special cache-plugin WP Widget Cache (found about it in: Website Boosting 19/2013, page 86).
But in my case my private hoster (mate) controls the cache (how much time, which parts?) So I am get used to wait after special actions.

Now I am in the backend: the static pages, criteria, plugins seem to be there. I do not know, if anything is missed. The plugin-page do not wanted to load again. But in an other browser (Opera) id loaded finally.

I could perhaps now install yet that new core update-plugin for automatted updating.
But makes this sense, after the version, which is shown in the footer, is now 1.7.2.?
Do I need to go into the file serendipity_config_local.inc.php and change the saved version here back from 1.7.2. to 1.6.2. in the variable $serendipity[`versionInstalled`]? So it is described from Garvin in manual on page 480 (under "just in case...").

The blog, like it is now, I have copied on my pc and I want to compare that with the last 2 backups to find out, what is gone lost. Those lost parts I could manually replace by ftp-uploading, couldn`t I?

[Timbalu]

We are still talking about the same thing, are we?
How do you manage to get into the backend with access to Management (entries, plugins, config, etc)?
If I open the link I sent, it is still showing that upgraders notice page, with lots of corrupted or modfied yellow files (*), wanting to finish, like I said yesterday and still have this morning. Is that a cached page which is shown for me this morning? (It still says 1.6.2, since it needs to finish.) I can't really believe this. I have three instances of that page open, two from yesterday (one of it reloaded) and one fresh try from today. But if you tell me all that has passed for you, I push that "Consider.. upgraded" submit button, to see what happens.

To run the autoupdate Plugin seems to be the only valid solution ATM, if your mate or hoster can not do this for you by console. I would recommend to have that run, if that upper issues have been really solved for you. First install all needed Plugins etc, then right before starting the autoupdate via backends startpage button, change version number here:
https://github.com/s9y/Serendipity/blob ... nc.php#L48
to 1.6.2. Reload your backend, verify the version mentioned in the footer and start the upgrade.

What did your investigation about kinetic update and 1.7 Series brought to daylight?

I could manually replace by ftp-uploading, couldn`t I?

Yes. But if you run the autoupdate there will be no lost parts any more, only individual made pages and templates, changes etc.


PS. There also is an experimental plugin for Serendipity, called serendipity_event_cachesimple.
This plugin will create PEAR::Cache_Lite static pages. It will only parse basic frontend pages. (just as an information, if you ever need or want to change the caching method)


(*) nearly all in /include and /lang and one file in htmlarea/plugins/ImageManager/Classes/ as core files only and as a mixture between core delivered and Spartacus added or manually changed files in /templates and /plugins. You can try to just run a last test with your FTP program (forcing strict upload) to these directories (files) only, which reduces time and amount.

[Timbalu]

As already stated in our PM conversation, this caching seems to be definitely one of the main parts of all these issues here, [in short] since caching the backend is not recommended as long this isn't static. In all upgrading Situations (Spartacus/Core/manual changes) this will need to be turned off, purged and turned on again. And this does not even touch more sensitive areas like Smarty compile files, dynamic hooks etc.

[Czorneboh]

Aha, when writing here, Timbalu passed me with entry from 11:47 am.
Ok, that helps and I am waiting now to get Cache-Server switched off.

I will keep you updated.


Back to 2nd last posting from 08:35 am:

What did your investigation about kinetic update and 1.7 Series brought to daylight?

I have just checked the Kinetic-Forum.
There were indeed issues after update to 1.7. rc3 in march.
Problem could be solved with Timbalu, (for visitors: see here:
http://board.s9y.org/viewtopic.php?f=3& ... #p10434130)

Don has announced there to be going to launch an update in the near future on 1st july 2013 (last message in the forum).

There is not yet an answer to my emailed question.

Yes. But if you run the autoupdate there will be no lost parts any more, only individual made pages and templates, changes etc.

The Update from Kinetic 1.2. to 1.3 I made manually, probably since I have 1.6.2. I want to look for these files, to be able to replace them, if needed.

Some further details you asked I have given you in personal message.

My private hoster now requests me to just upload (again) the (complete) s9y-package.
I want only to collect some informations before (like about Kinetic issues).
And I am waiting to get perhaps the Cache-server switched off for a while, till the problems are solved.