No articles appearing, no reason why not

phiw13 · 2016-10-10 06:37:52

Same database version of MySQL on both local and production side?

Destry · 2016-10-10 07:48:44

phiw13 wrote #302064:

Same database version of MySQL on both local and production side?

I thought they were the same, but now I’m not sure. Local is 5.7.13. Prod is at Host Gator and I don’t have shell access there. Nothing I can find in Cpanel says what version that server is running. I don’t see it in phpMyAdmin either. Any idea where I might look?

phiw13 · 2016-10-10 08:26:59

Destry wrote #302065:

Any idea where I might look?

Textpattern Admin > Diagnostics ?

Your host might suppress it though, like most hosting services now hide the Apache version.

Destry · 2016-10-10 08:35:24

phiw13 wrote #302066:

Textpattern Admin > Diagnostics ?

Oh, right. LOL I knew that. ;)

version 5.5.51-38.2

That’s probably the culprit. Even before this last update of DB from prod to local, I probably updated that direction earlier and didn’t remember or notice the article behavior. (This project has always been a minimum budget / help-a-local-acquaintance kind of thing… I try to invest as little time/effort as possible, but it ends up the exact opposite.)

So would this mean if I port the DB now the other direction — to prod — I’ll face the same problem? I guess I’ll have to find out.

Destry · 2016-10-10 09:28:25

Oh crap. On top of it, HostGator is running PHP 5.4. WTF?!

Destry · 2016-10-10 13:10:33

Oh man… just discovered this problem kind of happened on the CSF production site too, but only where there were articles lists inside body fields, as opposed to the entire site, which is why I never noticed it. For example on the event media pages, like this one, there should be a couple dozen articles or so showing up in the “Program resources” tables. On that production site I know the MySQL database is same as local, 5.7.x, so this can’t be a database problem, exactly, unless it’s specifically tied to version 5.7.x.

This seems to have happened somewhere during the updates in the 4.6.0 beta-to-stable series when updating the site locally and dancing through the pesky zeros fixes. But since I never noticed the disappearing articles problem until now, I can’t say which version was the cause. The CSF prod site was deficient like that since mid September when I updated the site to 4.6.0 stable, before that it was fine at 4.5.7.

So now the million dollar question, anyone, is there an easier way to reset saved articles instead of having to go through and manually resave them one at a time?

bici · 2016-10-10 16:38:00

are you able to roll back to the stable version on the live site?

jakob · 2016-10-10 17:31:33

Very weird. No idea what the cause could be. Maybe some change in the parsing, but that doesn’t really explain why the pre-textiled output won’t show.

If it’s just the textile reprocessing of the body and excerpt fields (and not some other thing that changes as a result of saving) then there’s this batch textile updater but please make a backup first…

I suppose you could see what’s actually being changed by copying the database entry for a faulty article, then re-save the article, copy then updated database record and compare the two. With sequel pro that’s easy: you can right click a record and copy as an insert statement, then save that to a text file.

Destry · 2016-10-11 06:29:52

bici wrote #302076:

are you able to roll back to the stable version on the live site?

The way I see it, 4.5.7 and 4.6.1 are both stable versions. It’s all that crap in between that caused problems. And to get to 4.6.1, in my case, it’s necessary to re-save articles, as evidenced by two sites so far. Anyway, I’m going forward, not backward. The updates and fixes are made at this point, mostly. I just hope there’s no more funny business in 4.6.1 onward.

jakob wrote #302077:

Very weird. No idea what the cause could be. Maybe some change in the parsing, but that doesn’t really explain why the pre-textiled output won’t show.

I don’t think this has to do with Textile, specifically, because in the store site, it was every article in the site that wasn’t appearing until I re-saved each article. But in the CSF site, it was only all the speaker “session” articles that output a few details as table records (their only function). Those tables are created as article lists in the body field like the products are in the shop site. But the table markup (part of the form) itself rendered, you could see the table husks. It was only the article contents filling out the tables that didn’t show up until each article was saved again.

But we also discovered yet another unfortunate situation last night with the CSF site… some of the articles just disappeared for good. For example in the Paris page, there should be a another six speakers there at least, including the two keynote speakers. Yet there are no articles in the admin-side for them anymore. We think the same is true for the Helsinki page, because that event had at least twice as many speakers as appear there now. I have an old DB file from which I can probably verify and recover the records, but it’s an extra pain in the ass on the to-do list.

My guess is this all had something to do with the combo of upgrading Txp on top of upgrading to mysql 5.7.13 and all the zero-date hoops I had to jump through just to make Txp happy there. I don’t know why that would be a problem. I’m not qualified to say. But after 12 years of using Textpattern, that’s a first, and it happened during that small window of necessary upgrades.

Anyway, I think I’ll just re-save articles as the fix, like I’ve been doing, and hope the issue goes away.

jakob · 2016-10-11 07:56:18

What about doing that before / after database comparison? It might help the devs identify what the trigger is and if you can perhaps update everything via a db command.

A couple of other stray thoughts:

Are you using a caching plugin at all? I would have thought a txp update would cause the cache to be refreshed, but maybe not.
If you can narrow it down to articles that contain some kind of parsed tag within them, then maybe it has something to do with how the parser works. IIRC there have been some changes there since 4.5.7.

Disappearing articles in the admin-side would seem to suggest something else. It would be more logical if an entire table disappeared but for individual articles to go missing…? Are they truly gone from the DB too? If not, maybe it’s something to do with the expiry dates.
If it’s any help: if you have precise holes in your new database where exactly those IDs are missing, you can probably do the sequel pro thing quite easily with copying the relevant record as an INSERT statement from the old database and pasting it into the other database using the SQL/Query tab. You can open two sequel pro windows in parallel and have the two DBs side-by-side. You can then compare any other fields (like the zero / null dates thing). If you work methodically, that may not be quite so painful a task as you imagined…

Bloke · 2016-10-11 08:17:02

Destry wrote #302079:

to get to 4.6.1, in my case, it’s necessary to re-save articles

The thing that doesn’t make sense here is that, as jakob said, Txp serves articles on the front side from the body_html column. That’s pre-rendered content; raw HTML and (possible) <txp:> tags. No Textile any more.

Thus the only thing introduced in 4.6 that could be getting in the way would be the parser. But if that was the case, the same thing would be present after you resaved the articles. It wouldn’t fix that. So it’s unlikely to be the parser.

My money’s on an encoding issue related to utf8 / utf8mb and the characters set of your template or something like that. I’m not saying this isn’t happening to you, because it clearly is, but in a few thousand installations so far, yours is the only report of this behaviour beyond erroneously constructed <txp:> tags that causes the parser to choke. So it’s likely to be some environmental issue specific to your server setup or database.

I know that doesn’t help with your frustration, and if we can get to the bottom of it, that’d be terrific as it might save someone else going through this pain. But there are a lot of variables in your case that we need to chase down to find the cause:

Upgrade of Txp.
Upgrade of PHP.
Upgrade of MySQL to an (officially) unsupported version, resulting in needing to tamper with zero dates.
Plugins that may be out-of-date or incompatible. Have you tried switching them off? Especially any cache-modifying plugins [Edit: heh, I see jakob thought the same].
Re-saving articles, possibly under a new collation or character set.

I presume there’s nothing in your Apache/PHP/MySQL log files to help narrow it down?

Last edited by Bloke (2016-10-11 08:17:45)

bici · 2016-10-11 18:05:41

Destry wrote #302079:

The way I see it, 4.5.7 and 4.6.1 are both stable versions. It’s all that crap in between that caused problems. And to get to 4.6.1, in my case, it’s necessary to re-save articles, as evidenced by two sites so far. Anyway, I’m going forward, not backward. The updates and fixes are made at this point, mostly. I just hope there’s no more funny business in 4.6.1 onward.

Both of them are stable, but you are having troubles after upgrading.
I thought by rolling back you could check to see if your site is as you expect it to be in earlier versions.

Then upgrade and see what changes.

It might also be instructive to save your mysql file from earlier on. Do a fresh install of TxP into a blank MySQL file , then re-install the previous MySQL and see what happens.

But thsi may not be possible now that you have moved along a couple of times.

Destry · 2016-10-11 22:55:43

jakob wrote #302080:

What about doing that before / after database comparison?

Yeah, I’ll get around to this. I’ve got some other things on the plate first. Plus I need a little time away from it, if you know what I mean.

Are you using a caching plugin at all?

No. Only rvm_maintenance on the store site, and that was off during the local upgrade. Not one on CSF either.

If you can narrow it down to articles that contain some kind of parsed tag within them, then maybe it has something to do with how the parser works. IIRC there have been some changes there since 4.5.7.

Yeah, this is what I’m being told, but I’ve looked through a fair amount of the relevant places to at least scan for any obvious mistakes in the offending places (i.e. relevant sections, pages, forms, article fields…) and I don’t see any improperly constructed tag syntax so far. Plus I would imagine if that were the case, then a simple re-save wouldn’t make it magically come back, it would still be broken.

Disappearing articles in the admin-side would seem to suggest something else. It would be more logical if an entire table disappeared but for individual articles to go missing…? Are they truly gone from the DB too? If not, maybe it’s something to do with the expiry dates.

The verdict is still out on the missing articles, actually, and I probably should have kept mum on that until knowing for sure. I won’t be able to say until I compare databases. Kevin and I both thought there was something amiss there when we re-saved all the articles; tables looked leaner. But this could very well be a false impression, heightened by frustration and lack of sleep. (A side realization from this is, if not true, is that we have some info gaps in or records since creation and will need followed up with old-fashioned web research and emails to plug them.)

if you have precise holes in your new database where exactly those IDs are missing, you can probably do the sequel pro thing quite easily

I’ll keep that in mind, thanks. Hopefully my impression about missing records is indeed false.

There were no missing records from the store site (easy to tell because there weren’t many to begin with), but that site’s entire suite of articles didn’t display either until each article re-saved. Go figure.

Bloke wrote #302081:

the only thing introduced in 4.6 that could be getting in the way would be the parser. But if that was the case, the same thing would be present after you resaved the articles. It wouldn’t fix that. So it’s unlikely to be the parser.

You would know better than me, so I’m happy to here it’s not the parser.

it’s likely to be some environmental issue specific to your server setup or database.

This could very well be it. All my post 4.5.7 install woes have been tied to MySQL 5.7.13 for whatever reason. I mean, that’s the most common line anyway. What it might be, I have no clue. I never do any custom configuration on my stack components. Always just use the default whenever possible. Maybe I exported a database in the wrong character set or something, but that seems like a weird reason to make article disappear but reappear after a simple Save click.

If I was a betting man, I’d bet it all came down to MySQL somewhere.

Upgrade of MySQL to an (officially) unsupported version

You mean unsupported by Txp? Because it was a “latest stable” from the vendor site when I upgraded. I don’t install experimental-ware in the stack. I don’t think Homebrew even provides a dev version of MySQL, though I could be wrong there. But still, I wouldn’t knowingly install it.

I notice WebFaction is running MySQL 5.6.32. Maybe I should upgrade or downgrade from 5.7.13, whichever is the latest stable direction again. Oh wait, what’s Txp’s order?

plugins

As mentioned. Only rvm_maintenance on the shop site, where all articles went hiding, and that plugin was off. CSF uses surprisingly few plugins. We roll like that. Too late to check there now anyway. All articles in database have been drop-kicked back into active status.

Re-saving articles, possibly under a new collation or character set.

Not sure I follow this one. Re-saving is what I’ve been doing to bring them back. Which has been completed now, btw.

I presume there’s nothing in your Apache/PHP/MySQL log files to help narrow it down?

I’ve never looked at a log file in my life. Is it hard? ;)
I guess I should peek into those, if just to know how to find them and see what going on there.

bici wrote #302095:

Both of them are stable, but you are having troubles after upgrading.
I thought by rolling back you could check to see if your site is as you expect it to be in earlier versions.

I have old backups for 4.5.7, which I know are fine, but nothing from the 4.6.0 beta stages, which is the gray area, so there’s nothing to roll back to in those beta steps.

Destry · 2016-10-11 23:16:28

Just connecting a couple dots from things I was saying, …

Whatever caused the problem in the local CSF site (running MySQL 5.7.13) — which, again, went undetected on the local server because not all articles were effected in that site (in fact only the most difficult articles to observe were, if you didn’t know to look in those tables) — the effects carried over to the production site when upgrading Txp there with 4.6.0 stable and uploading the local dev DB with it. So even though WebFaction is running MySQL 5.6.32, the database gremlins introduced locally still affected it.

That probably doesn’t mean anything.

Bloke · 2016-10-12 06:32:53

Destry wrote #302099:

[MySQl version] You mean unsupported by Txp?

Bah, scratch what I said. For some reason I thought your stack had been upgraded to MariaDB. Ignore me. I forgot that MySQL 5.7+ had the potential to cause date issues depending on the environment.

I’ve never looked at a log file in my life. Is it hard? ;)

Not especially. The hardest part is finding them! Your *AMP of choice will probably have a link to them somewhere. If not, find your httpd.conf file inside your Apache installation, go up a directory and there’ll often be a logs directory there. Might be at the same level as the httpd.conf, depends on how yours is set up.

Once you open each log with the most recent timestamp(s), just trawl through them from the bottom up and look for any messages that might bear relevance. The PHP logs are usual in a suitably-named directory off where you find your php.ini file. MySQL logs? Who knows!

Textpattern CMS support forum

#16 2016-10-10 06:37:52

Re: No articles appearing, no reason why not

#17 2016-10-10 07:48:44

Re: No articles appearing, no reason why not

phiw13 wrote #302064:

#18 2016-10-10 08:26:59

Re: No articles appearing, no reason why not

Destry wrote #302065:

#19 2016-10-10 08:35:24

Re: No articles appearing, no reason why not

phiw13 wrote #302066:

#20 2016-10-10 09:28:25

Re: No articles appearing, no reason why not

#21 2016-10-10 13:10:33

Re: No articles appearing, no reason why not

#22 2016-10-10 16:38:00

Re: No articles appearing, no reason why not

#23 2016-10-10 17:31:33

Re: No articles appearing, no reason why not

#24 2016-10-11 06:29:52

Re: No articles appearing, no reason why not

bici wrote #302076:

jakob wrote #302077:

#25 2016-10-11 07:56:18

Re: No articles appearing, no reason why not

#26 2016-10-11 08:17:02

Re: No articles appearing, no reason why not

Destry wrote #302079:

#27 2016-10-11 18:05:41

Re: No articles appearing, no reason why not

Destry wrote #302079:

#28 2016-10-11 22:55:43

Re: No articles appearing, no reason why not

jakob wrote #302080:

Bloke wrote #302081:

bici wrote #302095:

#29 2016-10-11 23:16:28

Re: No articles appearing, no reason why not

#30 2016-10-12 06:32:53

Re: No articles appearing, no reason why not

Destry wrote #302099:

Board footer