Posts

“There has been a critical error on your website. Learn more about debugging in WordPress.” and web error log reports “Call to undefined function the_field()” [Solved]

After an upgrade of WordPress, the site reported “There has been a critical error on your website. Learn more about debugging in WordPress.”. When investigating the web server log files, errors reporting “Call to undefined function the_field()”.

Solution: During the upgrade process, the plugin “Advanced Custom Fields” had been disabled. By activating the plugin, the problem was solved.

“There has been a critical error on your website. Learn more about debugging in WordPress.” after updating to WordPress 5.7 (All in one WP security and firewall) [Solved]

Investigating the error log reveals that the problem has to do with All in one WP security and firewall plugin:

Got error 'PHP message: PHP Fatal error:  Cannot redeclare retrieve_password() (previously declared in /www/wp-includes/user.php:2671) in /www/wp-content/plugins/all-in-one-wp-security-and-firewall/other-includes/wp-security-rename-login-feature.php on line 358'

The problem has been solved in All in one WP security and firewall plugin version 4.4.8, so it means your WordPress site was updated to 5.7 prior to updating the plugins.

To solve it, you need to update All in one WP security and firewall but not being able to login to your site you will need to solve this using FTP.

Using FTP, rename the folder wp-content/plugins/all-in-one-wp-security-and-firewall to something else. Now you can log into your site and reinstall All in one WP security and firewall. Make sure you get at least version 4.4.8.

WordPress displays 'Connection Information'

WordPress displays “Connection Information” asking for FTP credentials

WP displays “Connection Information” and a text “To perform the requested operation, WordPress needs to access your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host.

To solve this, add the following line to your wp-config.php:

define('FS_METHOD','direct');

If that doesn’t solve the problem you need to check the file access rights for the WordPress installation on the web server.

WordPress shows white page after site move

WordPress just showing a white page means it is experienceing PHP errors. When it occurs after a site has been moved from one hosting to another it can be caused by several reasons.

To make it possible to track down the cause you can temporarily add the following to the .htaccess file in the root. If this gives you a internal server error 500 it means it is not allowed by the host. If allowed, you will get error messages from PHP dispayed on screen when accessing the site:

php_flag display_startup_errors on
php_flag display_errors on

There are visbible PHP ending tags ?> on the site

If you see more or less normal output from the site but once in a while you see lines ending with ?>. This can happen if the site has been running on PHP 5 where the short PHP start tag <? is allowed (instead of the longer <?php.

If the site has been moved to PHP 7 where this is not longer allowed, it can cause this kind of strange behaviour.

If you don’t want to go through all the code and find all the occurrences of <? and replace them with <?php (which is one solution), you can simply add the following to your php.ini:

short_open_tag=On

You need to restart Apache after this.

Wordfence plugin is installed

You need to manually edit the system specific paths in the following files:

  • .user.ini in the site root, change the path after auto_prepend_file
  • wordfence-waf.php in the site root, change the paths on all occurrences

WP Rocket plugin is installed

The file wp-content/advanced-cache.php contains system specific paths. You can manually update them or just simply delete the file and login to wp-admin of the site and it will be recreated automatically with the correct paths.

WP Live Chat custom js attack

WordPress Live Chat support plugin redirect vulnerability – how to fix

A security problem in the WordPress Live Chat support plugin made it vulnerable for XSS making it possible for an attacker to add custom javascript to the configuration of the plugin. This can be done from the outside world without being logged in to the site.

The exploit has been used to infect WordPress sites with for example redirect scripts, causing the visitor to be redirected to other sites when clicking on internal links in the site. More information about the details of the exploit can be found here.

The vulnerablity in WP Live Chat support plugin has been fixed in version 8.0.29 of the plugin but just updating the plugin will not solve the problem if the site already has been infected with custom javascript code.

To solve the problem:

  • Make sure WP Live Chat support plugin is updated to version 8.0.29
  • In WP backend, go to Live Chat -> Settings -> Custom scripts and remove the unwanted code from the Custom JS box (see image)
WP Live Chat custom js attack
WP Live Chat custom js attack

Akeeba restore error – 1118 – Row size too large (>8126) [solution]

When restoring an Akeeba backup of a WordPress site the restore process was interrupted with the error message saying 1118 – Row size too large (>8126).

Solution:

  • Use SSH to log in to your database server
  • Edit /etc/mysql/my.cnf or if you use a config file under /etc/mysql/conf.d, edit that one
  • Under the [mysqld] section add:
    internal_tmp_disk_storage_engine=MyISAM
    innodb_strict_mode = 0
  • Restart mysql:
    service mysql restart

Edit: After you successfully restored the site, remove the lines and restart MySQL. I didn’t do this and later tried to move another site from this server to another using Akeeba. When the site was installed on the new server, I just got an error message saying “Error Establishing a Database Connection”. To resolve it, I had to go back to the above server, remove the lines from mysql config, restart MySQL, make a new backup of the site using Akeeba and successfully restore it on the new server.

Credit: The solution to this problem was found here.

Contact Form 7 not working with All-in-One Intranet plugin [solution]

When using Contact Form 7 forms in a site where the All-in-One Intranet plugin is installed, it will not be possible to submit the CF7 forms. The solution is quite simple.

In the Advanced settings of the Contact Form 7 form, add the line:

subscribers_only: true

open_basedir restriction in effect. File(/) is not within the allowed path(s) in WordPress [Solved]

After a WordPress site move to new hosting, some images wouldn’t load and investigating the php error log revealed:

open_basedir restriction in effect. File(/) is not within the allowed path(s)

The solutions was to edit the database using phpMyAdmin, go to the table wp_options and set the correct value for upload_path.

Mega Menu doesn’t display down arrow for submenus

The WordPress plugin Mega Menu has the possibility to display a “down arrow” for a menu item where a submenu is available (i.e. the menu item has “children”). The problem was that the arrow was not displaying.

It turned out it was a collission with the theme, Cherry Framework 4. In the settings of the theme’s native menu, there is a possibility to enable “arrow markups”. When this is enabled in Cherry Framework 4, the arrows in Mega Menu is not displayed.

Solution: Go to Cherry -> Options -> Navigation -> Set Arrows Markup = off

Cherry Framework 4 header not using full page width when breadcrumbs are disabled

When you disable breadcrumbs in Cherry Framework 4, it still reserves space for it in the header/title section of the page. This is a bit annoying, because it makes the title wrap when there still is space on the right side.

A simple CSS solution can fix this. By applying this, the breadcrumbs will not be visible even if they are enabled again.

.cherry-breadcrumbs .col-md-5 { /* no breadcrumbs, title in full width */
width: 100%;
}
.cherry-breadcrumbs .col-md-7 { /* no breadcrumbs, hide the breadcrumb container */
display: none;
}