Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,596
Website

Re: No articles appearing, no reason why not

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…


TXP Builders – finely-crafted code, design and txp

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,271
Website GitHub

Re: No articles appearing, no reason why not

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)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

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

bici
Member
From: vancouver
Registered: 2004-02-24
Posts: 2,075
Website Mastodon

Re: No articles appearing, no reason why not

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.

…. texted postive

Offline

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

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: No articles appearing, no reason why not

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.

Offline

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

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: No articles appearing, no reason why not

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.

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,271
Website GitHub

Re: No articles appearing, no reason why not

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!


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#31 2016-10-13 14:36:08

maverick
Member
From: Southeastern Michigan, USA
Registered: 2005-01-14
Posts: 976
Website

Re: No articles appearing, no reason why not

Knowing this is way above my pay grade, so I’m thinking any suggestion I have is probably clueless, but at the probably risk of looking like a fool any way . . .

Weren’t there some changes in how certain character entities were handled / encoded? If one of those characters were present in the articles, would that break the display of the article until it was reserved and the encoding updated?

Offline

Board footer

Powered by FluxBB