[resolved] Database sleuthing

Destry · 2020-12-18 16:29:39

Before I attempt to replace my production db, I thought I’d see if I can learn some db sleuthing first.

As once explained elsewhere, I had this problem after updating an install and importing the local db…

buggy behaviour I’d not experienced before when trying to correct file paths
it does not indicate the right version number at bottom, even though the latest data was imported from a 4.8.4 dump
the articles panel keeps collapsing to minimal records per page, even when I leave and come back to it in the same session and opted for max display
every save in the back, no matter the panel, creates the ‘Success! message but includes an additional check mark ✅ item reading: ‘ A new Textpattern version (4.8.3) has been installed.’
can not make the /files directory writable warning go away even though it’s 777
when clicking help popup for that last one, I see the following:

;textpattern.Console.addMessage([“A new Textpattern version (4.8.3) has been installed.”, 0]);

Directory is not writable

To use the file and image upload capabilities, these directories must be writable by PHP via the web server user. This can be done with an (S)FTP client, or alternatively on the command line by issuing a chmod 755 /path/to/dir command.

Probably the same in other popups. Not checked.

I have a feeling I need to replace the database. The problem is there, I think.

Before I resort to that, what can I check? Is there a mysql log that would show a record of changes and what?

I remembered something just now. When I initially imported my dump file it only imported one table, though I don’t remember which table. I’m not sure why an export created that file, but it might have been because I was in the wrong context in Sequal Pro when creating it. The import was a success, though I recall seeing a lot of unexpected notices in the confirmation. I didn’t pay attention. I didn’t think it was a problem.

I then created the correct/full dump, overwriting the old file and that was the one I updated to production

Thoughts? Suggestions?

Last edited by Destry (2020-12-19 09:09:16)

Bloke · 2020-12-18 17:12:38

The sort of thing you’re experiencing is usually caused by the update process not completing for some reason. Txp then gets stuck in a loop trying to upgrade to the latest version.

This is what happens on any page load after logging in:

Get version value from txp_prefs in the database.
Get $this_version from index.php.
Compare them.
If they don’t match, trigger an upgrade by including the update/_update.php file. This goes through the /update directory, file by file in filename order (which’ll break when we get to Textpattern 10, haha) and compares each file version number to your database version. As soon as it finds a filename that’s greater than your DB value, it runs that file. Thus, making database and filesystem changes as necessary until it gets to the latest version.
Set your database version to match the same version number as the one in index.php, thus next time it won’t trigger the upgrade until you replace the files and put a later version in.

The trouble comes if the update process aborts – for whatever reason – midway. This means your DB value is never altered to match the current file version, so on every page load, Txp tries to apply the update, as detailed above. Thus, Groundhog day.

Depending on the severity of the situation – how far it got through the update before giving up the goat – depends what symptoms you see.

Hence, if an upgrade borks, we often advise changing your database version pref value back to the value of the version you came from, because that then retriggers the update process from that point. If you have debugging switched on, this often yields a bunch of errors. We try to be defensive during upgrade (to check if something’s already been done and skip it) but this paradigm is not strictly adhered to or, in some cases, not possible. The good news is that if you do put debugging on and retry, that can often pinpoint where things are going tits up.

Last edited by Bloke (2020-12-18 17:15:57)

Destry · 2020-12-18 19:49:11

Okay, thanks. I take it that means debugging mode for export from local and debugging mode in prod when importing?

Bloke · 2020-12-18 20:35:04

Yeah, sorry. Production mode = debugging in prefs, log out. Then reset the version number (via phpMyAdmin)and log back in again to trigger the upgrade.

Destry · 2020-12-19 00:15:44

Bloke wrote #327645:

Production mode = debugging in prefs, log out. Then reset the version number (via phpMyAdmin)and log back in again to trigger the upgrade.

I always thought production = live and development = debugging (or testing)

I’m confused.

Anyway, I looked in the database of both local and production DBs. In the txp_prefs table, for ‘version’, they both read 4.8.4. Nothing to change.

But in the production DB (live on the web), I still have all those errors when I log in, and it still says 4.8.3 everywhere, including in Diagnostics output:

Textpattern version: 4.8.3 (596bca03a4b32004412499363cecec62)
Last update: 2020-12-19 00:04:21/2020-11-12 16:44:50
Site URL: wion.com

Now here’s the part I don’t get at all…

I decided to completely delete the production DB and recreate it, which I did on the host end. Then imported a new dump from local, which is all reading fin in Diagnostics (4.8.4) as expected. But when I log in on production (live) again, it’s the same shit as before — same problems and still reading as 4.8.3.

What is going on?

Maybe the local install is false? But how, if it doesn’t show it?

Last edited by Destry (2020-12-19 00:18:34)

Destry · 2020-12-19 00:20:52

If I’m seeing that line in Diagnostics about DB version:

Textpattern version: 4.8.3 (596bca03a4b32004412499363cecec62)

Then it must be somewhere in the DB, getting read, right? Where do I find that?

Destry · 2020-12-19 01:08:04

Well, just noticed that the dump file I created from local and updated production with provides page templates lacking changes I made earlier today, e.g. the latest end-of-article message I was talking about elsewhere.

~~That seems to suggest the dump file is faulty, which must mean Sequal Pro is the culprit.~~ Looks like I will delete that, finally, and try Sequal Ace, or export from command-line, better still. Then see what happens.

Ugh, was looking at the wrong thing. The above was not true, in fact. But I will upgrade to Sequal Ace, finally.

Last edited by Destry (2020-12-19 01:40:05)

Destry · 2020-12-19 01:28:50

Crap, it’s one weird problem after another.

I’m using this command, which has always worked before:

mysqldump -u username -p dbname > file.sql

But it does this:

mysqldump -u username -p dbname > file.sql
    ->

Then I have to \c to get out.

Off to install Sequal Ace, and it better be the damn ACE!

Bloke · 2020-12-19 02:18:45

Destry wrote #327649:

I always thought production = live and development = debugging (or testing)

Well yeah, but the pref name is Production status and you can choose Live, Testing or Debugging. I just meant that if you put it in Debugging mode, log out, and dick around with your files/database, when you log in you’ll see a lot more errors than you’ll do in Live (or Testing) which may help narrow down where the script is falling over.

I looked in the database of both local and production DBs. In the txp_prefs table, for ‘version’, they both read 4.8.4. Nothing to change. But in the production DB (live on the web), I still have all those errors when I log in, and it still says 4.8.3 everywhere, including in Diagnostics output:

In which case, your filesystem is NOT running 4.8.4 on your production installation. The version number you see in the Diagnostics panel is taken from the files (specifically, textpattern/index.php). Double/triple check your site file paths in diagnostics match what you expect, and that textpattern/config.php (primarily the txpath and database definitions) are pointing where you expect.

Last edited by Bloke (2020-12-19 02:19:53)

Destry · 2020-12-19 02:26:22

I think I figured it out, once I realized where the 4.8.3 was coming from.
The /textpattern/index.php files were different between the two servers. :/

That may have been because I forgot to drag it over before. Not sure. I was also getting checksum mismatches when I dragged it over just now, so I did a complete reinstall on local then drug the whole she-bang over and it seems to be all right now.

So sorry for being the DB boob.

EDIT: you beat me to the post. ;)

Last edited by Destry (2020-12-19 11:20:38)

Destry · 2020-12-19 02:31:55

Just the /files and /tmp paths keep reading not writable, even though they are both set to 777.

Way past bed time. I’m outta here.

gaekwad · 2020-12-19 11:10:58

Destry wrote #327661:

Just the /files and /tmp paths keep reading not writable,

You’re not the first person to say this…who else mentioned this in the last week or so? Very vague memory of someone (Algaris? I’ll check.) else saying they had the same thing on an upgrade.

Textpattern CMS

Textpattern CMS support forum

#1 2020-12-18 16:29:39