dccharron

[insert_php]
function cleanup() {
  echo "Test<br />";
}
cleanup();
[/insert_php]

The above code on a page relies on the plugin “Insert PHP” by Will Bontrager.

When combined with Jetpack plugin it fails when Jetpack’s
Automatically share your posts to social networks.
is turned on. It works with this feature turned off.

No. My PHP code has no duplicate cleanup function. I changed it to mycleanup and the error just changed to mycleanup.

I don’t know how the jetpack option
Automatically share your posts to social networks.
works but when I turn it off, all works properly. If there had been a duplicate cleanup function, it would not have worked.

One thing I did notice was that “existing” pages that had my own PHP code continued to work (no fatal error). It was only when I built a “new” page with PHP code that failed. Also, if the PHP code doesn’t contain any function at all, there is no error.

Thanks @lautrec. Thanks for the tips.

I was aware of the move to github and have downloaded and installed the latest version (34). I’ve also looked up and down the cfdbplugin.com website for an answer to my problem but sadly nothing has worked.

The really bizarre situation I’m in is that I’m using the same version of the cfdb plugin on another website and it works perfectly. But I just can’t make it work on this second website. I’ve studied the settings on the successful website and made sure I’ve got exactly the same settings on the other. There is something I am missing. I’ve checked .htaccess and wp-config. I’ve even rebuilt the table in the sql database (the older version used a slightly different structure to the new version and I wanted to eliminate that difference as a possible cause).

Tearing my hair out (not much hair left).

I think I’ve resolved this problem myself. I found a useful link on github:
https://github.com/presscustomizr/customizr/issues/815
The problem seems to be related to a rather old bug (classic misuse of “==” instead of “=”) which, according to the aforementioned article had been fixed. But it clearly has re-appeared (at least intermittently).

The cause is as follows:
Apparently, in “Media”, each image has a status of “Uploaded to”. This status connects an image to a post. The status depends on how the image is uploaded. If it is uploaded via the “Media” menu => Add New, the image remains “Unattached”. But if the image is uploaded during the “edit” process of the post itself, the image gets “attached” to the post. That’s the first part of what was causing this problem. The “attach” status is visible in the “media” menu when viewed as a list (not as a grid).

The second part it the way WordPress treats a post with no specified “Featured Image”. WordPress looks for any image that is “attached” to the post, and, if found, treats it as the posts “featured image”. In other words, the image becomes a default “featured image” for the attached post.

In the “Customizr” theme, when specified, the featured image is displayed above the title of the post with a max height of 100px. The image is automatically stretched and/or cropped to 100px in height and is stretched to 1170px width. In my particular case, the post had an “attached” image. That “attached” image was treated as a “featured image”. In this case, the “attached” image was already 1170 wide but was 400 high. The cropping process in Customizr chopped off the bottom of the image before displaying it above the title.

To solve my problem, I’ve used the “detach” link in the “media” list. The problem “seems” to be resolved (it hasn’t re-appeared so far). I’m hoping that’s because when “Customizr” doesn’t detect any attached image, it doesn’t display anything above the post title.

While this correction should fix my problem, it doesn’t explain why, when I was experiencing the problem, the problem only appeared intermittently. That suggests there is still a bug to be found but I’ll leave that to others.

I have a lot more information on this problem. So I’ll close this post and refer you to my new support topic.

Thanks @wfalaa

Seems unlikely that GoDaddy would run a server with misconfigured MySQL permissions or a limited space in /tmp but I’ll contact them to see what they say.

Many thanks. It’s on its way.

I’m stuck. I can’t complete a Scan. It starts normally and then runs normally for a few seconds. But when it reaches Server State level, it runs for a few seconds and then generates:
[Mar 19 11:16:11] Calling fork() from wordfenceHash with maxExecTime: 15
[Mar 19 11:16:11] Entered fork()
[Mar 19 11:16:11] Error finishing writing value for wfsd_engine (MySQLi error: [1] Can’t create/write to file ‘/var/lib/mysql_logs/3/mysqlbintemp/MLjOavJP’ (Errcode: 2))
My account is an older GoDaddy account (running PHP 5.6 – yes I know this is ancient but GoDaddy are very slow to update PHP for their loyal customers as they are hoping they will die and go away or buy one of their really expensive managed WP accounts). My site is running on Linux using Apache.

I don’t have access to configure Apache.

I’ve deactivated all other plugins and tried again but same error at same place.

I don’t have access to “tmp” files. I can only view “errorlogs” and “accesslogs” but the few error messages I can see are very cryptic and don’t seem to relate to wordfence at all.

@kalashnikovevg suggested I get more “free space” but I have no idea how to do that. I assume it is an Apache configuration option and I can’t access that.

Any new help would be great.

Many thanks for the interest. Still no go. Scan dies with same message as before. I have no control over “free space” on a shared GoDaddy server so don’t think I’ll be able to overcome that. As for the error logs, GoDaddy have some weird setup which I’m trying to work through now but I suspect I’ll have to make a call to get anywhere with it. The Access Logs are available for each day but the Error Logs seem to be completely empty at the moment.

Aside: I’ve found my hacker by looking at my Access Logs. They were using an IP address from a registrar that I have seen many times over the past few years: a ‘legitimate’ organisation called RIPE in Amsterdam. RIPE must offer a proxy server or VPN service that has become the preferred gateway for hackers. No way to trace the hacker any further back. I’m trying to find the point of intrusion of the malware files but haven’t found it yet. Have spent my day changing passwords. Ho hum.

Eureka! Stand down! I just found an option in the Appearance => Customise => Main Content => Post/Page Navigation:

Display Posts Navigation in Single Posts

The box was checked. I unchecked it and presto, the links disappeared on the Single posts but remain on the Post Lists.

Comments for that snippet are closed. So I can’t update it. I should have known that Nicolas would add this option. Such a great theme. Have reviewed at 5 star. Continues to impress me every time I use it.

Many thanks for helping.

The website is under construction but I’m not expecting to change anything substantial for a few days.

Here’s a link to a single post on the website:
https://v2.jag.org.au/2018/03/04/social-art-painting-group-ongoing-workshop-on-monday-nights/ You should see the nav links at the bottom of the page.

Here’s the code I’ve put in my child theme’s functions.php file:

// START OF Remove the navigation links completely from the bottom of single posts
add_action ( 'wp_head', 'remove_single_post_nav_links');
function remove_single_post_nav_links() {
    //we only want to remove those nav links for a single post and not for the list of posts
    if ( !is_single() )
        return;
        remove_action  ( '__after_loop' , array( CZR_post_navigation::$instance , 'tc_post_nav' ), 20 );
}
// END OF Remove the navigation completely from the bottom of single posts

Sure hope you can spot the problem.

Oops. I discovered I was using the wrong shortcode. I should have been using

[cfdb-html]

Exactly what I needed.

Me too. I am looking at “Display Posts Shortcode“. Seems to have a big following (100k+) and is being updated to new versions of WordPress.

Yes. Editing a plugin’s PHP is not for the non-technical person. But this is a good learning opportunity as it is a really easy fix.

Tips to non-technical persons:

For those without FTP you probably have a “File Manager” facility through your hosting account. Use it to edit the relevant file.

If you’ve lost access to your “admin” dashboard in WordPress, then use FTP (or File Manager) to rename the “goodbye-captcha” folder (directory) under “plugins” from “goodbye-captcha” to, say, “goodbye-captcha.bad”. That should let you back into your admin dashboard and your website comes back to life and this buys you time to fix the code. Then rename the folder back to its original name and everything is back to normal.

In version 3.1.9 of the plugin, someone has mistyped “add_action” as “add_acttion”. Easily corrected by editing the relevant file using FTP and removing the extra T.

Find the file:
wp-content/plugins/goodbye-captcha/engine/modules/mc-for-wp/GdbcMailChimpForWpPublicModule.php

edit line 42 and save the file. All good now.

This type of trivial error doesn’t fill us with confidence. You gotta do more (some?) testing.