Stian Lund

@mburridge @littlepackage
Thank you SO much for the tips! 🙂

I could swear I tried using add_filter for the next/previous_post_link but couldn’t get it to work, or I didn’t understand that I needed to use str_replace() with an input argument.

I went with the anon function like I did with the other posts type. It’s a bit of a “mess” but saves me adding another function inside a function (this is all in a separate require call from functions.php). But might be bad for performance reasons, what do you think?

// Swap 'rel' attributes for single post next/previous links 
add_filter( 'previous_post_link', function($format){return str_replace('rel="prev"','rel="next"',$format);});
add_filter( 'next_post_link', function($format){return str_replace('rel="next"','rel="prev"',$format);});

Thanks again helpful people! 🙂

EDIT: Oh and the theme I use is this:
https://github.com/keichan34/wp386
It’s getting OLD, not updated by the author for a decade… And will probably stop working at some point. Making small changes to it is just a way to *slowly* learn a little more PHP.

I’m adding the code in the overridden wp386_content_nav() method here:
https://github.com/keichan34/wp386/blob/master/inc/template-tags.php

• This reply was modified 3 years, 6 months ago by Stian Lund.
• This reply was modified 3 years, 6 months ago by Stian Lund.
• This reply was modified 3 years, 6 months ago by Stian Lund.
• This reply was modified 3 years, 6 months ago by Stian Lund.

Hello Patrick,
thanks for the reply.

A fresh and updated engine will of course be appreciated – but this is a *single-line* you can try to update at least once a year, and the http checker will continue working for most sites.

You don’t even need to update the whole line to a valid UA, just changing Chrome/70 to Chrome/103 will do.

Chrome 70 was released in 2018 (!)

Best of luck with the new engine!

• This reply was modified 3 years, 9 months ago by Stian Lund.
• This reply was modified 3 years, 9 months ago by Stian Lund.

Thanks for the advice Dion, appreciated.

This was an upgrade from 7.3 -> 7.4. There is no such line in the config, and PHP+WP worked fine before the upgrade. So I think the admins just forgot to install/enable the MySQLi module. It will be fixed I’m sure.

After some investigation I think the issue with the output was the admin had set (or it was default), the PHP value display_errors to On for troubleshooting and it affected the entire server and hosted sites while stuff wasn’t working. I’ve now set the value to Off in my .user.ini and maybe that will stop it from happening in the future.

My main problem and the topic of this post was rather that when WordPress had a fatal error, it displayed the full credentials to the DB in the output. IMO this is bad practice and such information should be stripped from the output, whether or not WP_DEBUG_DISPLAY is true or false. But not sure where I should report it, maybe as a security issue?

• This reply was modified 4 years, 4 months ago by Stian Lund.

@bplv Thank you – much appreciated! 🙂

Hello again Kasia,
I notice the fix I made is now in the plugin. So that’s great, finally. Thank you for that 🙂

However I also noticed the Github version has not been updated for ages. So I assume the plugin is no longer available on Github? If it is, where is the active repo?

It would be nice with some acknowledgement in the changelog too 😉

Stian

• This reply was modified 5 years, 11 months ago by Stian Lund.