WP Booking Calendar – style width and height of calendar

In WP Booking Calendar, the calendar when displayed in a widget has a fixed size of 284px using inline css which makes it impossible to override in an external or internal css style.

However it is possible to override this by additional options in the shortcode. This is from the comments in the source code:

[booking type=56 form_type='standard' nummonths=4 options='{calendar months_num_in_row=2 width=568px cell_height=30px}']

In the options the width of the table can be given, also in % like 100% for example if you want the calendar to fill the surroinding container.

WordPress error 500 – Uncaught Error: Call to undefined function trailingslashit() in wp-includes/class-wp-textdomain-registry.php:103

When updating the plugins in a WordPress site prior to updating it from WordPress 6.0 to 6.1.1 the site halted with error 500. Investigating the logs I found “Uncaught Error: Call to undefined function trailingslashit() in wp-includes/class-wp-textdomain-registry.php:103

Solution

How to make WordPress display PHP errors

Your site is down just displaying “This site is experiencing technical difficulties” and you need to investigate what is causing the error. If you turn on PHP error reporting at your hosting provider, WordPress still just displays the generic message.

Turn on PHP error reporting at your hosting provider.

Edit the wp-config.php file and comment out the line define( ‘WP_DEBUG’, false );

// define( 'WP_DEBUG', false );

Then add the following lines and make sure they occur before the line /* That’s all, stop editing! Happy blogging. */

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );
@ini_set( 'display_errors', 1 );

When you are done, remember to revert the above changes.

“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