Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Fatal error
Hmmm, that is worrying. Does Diagnostics say everything else is tickety boo? And is your /texptattern/plugins directory writable?
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Fatal error
Pre-flight check All checks passed
textpattern directory has permission 705
And when you say “hmm worrying” I know it’s bad
Oh, hang on you said ‘plugins’ directory: 705 also
The only active plugins are these:
smd_calendar-0.53
smd_gallery-0.62
smd_lib-0.36
What else should I try to even see the ‘Plugins’ listed (This is from diagnostics)
Last edited by gavnosis (2021-04-15 15:43:03)
Offline
Re: Fatal error
Can’t say I’ve ever seen 705 as a permission strategy on a host: that’s a new one! Is there anything in that /textpattern/plugins directory? You should have a subdir per plugin installed.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Fatal error
gavnosis wrote #329850:
Pre-flight check All checks passed
textpattern directory has permission 705
Switch that to 755.
Makes no sense that everyone has higher access privileges (5) than the owner group (0).
Offline
Re: Fatal error
‘Textpattern’ now has 755
(Thank you, that was going to be my next question)
…and plugins directory the same? (all subdirectories are there per plugin, and at 705)
And do I hack the plugin and leave the original txp_auth.php in place, too?
// -------------------------------------------------------------------
function cbe_frontauth( $atts, $thing = null )
{
include txpath.'/lib/txplib_admin.php';
include_once( txpath.'/include/txp_auth.php' ) ;
Last edited by gavnosis (2021-04-15 15:54:36)
Offline
Re: Fatal error
gavnosis wrote #329853:
…and plugins directory the same? (all subdirectories are there per plugin, and at 705)
Yep. Just give that a go and see if things pick up. When you edit+save a plugin from the Admin>Plugins panel, it should write to that dir and you’ll see the relevant datestamps change if the server manages it.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Fatal error
Well, I get a different error now… so sort of progress
(but still can’t see my plugins listed within textpattern itself)
Fatal error: Cannot redeclare send_account_activation()
Offline
Re: Fatal error
gavnosis wrote #329855:
Fatal error: Cannot redeclare
Oops, I meant:
include_once(txpath.'/include/txp_admin.php');
Sorry.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Fatal error
Thank you Stef…
Alas, that revised improvement to Claire’s plugin takes me back to my original error, and I can’t help but think something else is seriously wrong. Why (O-Y-O-Y) would installed plugins not be listed within Textpattern itself (I can see them in the database and also the sub directories on the web server–now with the correct permissions), but on Textpattern itself there are (apparently) none installed :-(
Offline
Re: Fatal error
gavnosis wrote #329859:
Why (O-Y-O-Y) would installed plugins not be listed within Textpattern itself
Therein lies the conundrum. Short of it being a filesystem issue – unlikely since Diagnostics says all files are present and correct – or a table-specific connectivity issue, I’m floundering here to understand why this is happening.
Random thoughts:
- Put your site into debugging mode and visit the Plugins panel. See if any errors are kicked out. You can flick it back to Live immediately after.
- Check your table collations on the txp_plugin table match the other tables. Maybe some of the rows/columns have the wrong collation and Txp is having a hard time interpreting the data.
- Check your table indexes are intact and are indexing data. There should be two:
UNIQUE name (name),
INDEX status_type_idx (status, type)
Past that, I’m struggling, sorry.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Fatal error
Thank you for the suggestion. And, oh, this doesn’t look good in plugins in debugging mode
User_Error "Illegal mix of collations (utf8_general_ci,COERCIBLE) and (latin1_german2_ci,IMPLICIT) for operation 'strcmp'"
in… /textpattern/lib/txplib_db.php at line 453.
And there’s more, too :-(
adminErrorHandler()
textpattern/lib/txplib_db.php:453 trigger_error()
textpattern/lib/txplib_db.php:1191 safe_query()
textpattern/lib/txplib_db.php:1039 startRows()
textpattern/include/txp_plugin.php:190 safe_rows_start()
textpattern/include/txp_plugin.php:56 plugin_list()
textpattern/index.php:228 include()
Warning "mysqli_fetch_assoc() expects parameter 1 to be mysqli_result, bool given"
Offline
Re: Fatal error
Okay, result! That’s all fixable and explains it.
I’ve seen this on other tables where stuff just doesn’t appear in the admin side because the database can’t resolve the collation conflicts. That second error is a byproduct of the first so it’ll go away when the collations are fixed.
I’d suggest inspecting the collations used on other tables. Find a table that renders fine (without errors in debugging mode) on the admin side – pages, forms, textpattern, link, images, whatever – and take a look at the collation it uses for columns. Then go to your txp_plugin table and alter the collation on any columns that don’t match. I suspect that any with latin1_german2_ci will need to become utf8_general_ci, but it could be the other way around depending on where your database is located and its language and so forth.
Once you’ve altered those, the Plugins panel should load fine. You can verify it with a quick trip to debugging mode and if there are any stragglers, they’ll show up.
Quite how this situation occurs, btw, is not something that’s apparent to me. It just does. If anybody knows why or how this happens (perhaps content itself is encoded in a particular collation and Txp doesn’t correct it, taking it verbatim?) then I’d love to find out what causes it.
Last edited by Bloke (2021-04-16 08:04:06)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Fatal error
Thank you Stef
Pretty much everything has collations of latin1_german2_ci, including txp_plugin
txp_page latin1_german2_ci
txp_image latin1_german2_ci
In fact the only there tables which don’t are these
txp_skin utf8_general_ci
txp_token utf8_general_ci
smd_tags utf8_general_ci
Would I change these three to latin1_german2_ci?
Offline
Re: Fatal error
If latin1_german2_ci is the dominant collation then, sure, use that. Whichever is least work :)
Check for column collations as well as table collations. Each column in each table has its own collation and they should all match for a seamless ride.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Fatal error
Bloke wrote #329865:
I’ve seen this on other tables where stuff just doesn’t appear in the admin side because the database can’t resolve the collation conflicts. That second error is a byproduct of the first so it’ll go away when the collations are fixed.
[…]
Quite how this situation occurs, btw, is not something that’s apparent to me. It just does. If anybody knows why or how this happens (perhaps content itself is encoded in a particular collation and Txp doesn’t correct it, taking it verbatim?) then I’d love to find out what causes it.
Same here. It’s baffled me a few times, especially with oooold sites where hosting organisation has changed more than once. Some European hosters (and MediaTemple back in the day, inexplicably) set the MySQL collation to their (European) datacenter location, which causes snags when you move to another host that doesn’t necessarily support that collation.
Last edited by gaekwad (2021-04-16 09:35:08)
Offline