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;
}

Where is WordPress links / blogroll?

In older WordPress installations there was a possibility to handle links. I recently installed a new WordPress 4.9 and I can’t find links (or blogroll). i.e. the Link Manager, anymore. Where is it?

From version 3.5 of WordPress, the Links section is not visible anymore if there were no links present or if it is a new installation.

If you want it back, you can download Link Manager here.

How to keep WordPress widgets when switching themes

When you switch from one theme to another in WordPress you will discover that all widgets you had is gone. Is there a way to keep the widgets when switching themes?

Short answer is – no. The widgets are set specifically for the theme.

But it is often quite simple to resolve the situation. After you switch theme, go to Appearance -> Widgets and scroll down to the bottom of the page.

Here you will find Inactive widgets. You can simply pull them back into your new theme’s widget position and get them back where you want them.

WordPress widgets

WordPress widgets

However, if the widgets you were using was part of the theme you switched from, they will not be available when using the new theme so in that case you need to find an alternative plugin or widget.

SiteOrigin Pagebuilder and widgets not working after site move / migration [solution]

Normally when moving, mirating or deploying a WordPress site, I use the Akeeba Backup plugin for WordPress. This works excellent, also for sites built using SiteOrigin Pagebuilder and SiteOrigin widgets bundle.

If, for some reason, it is not possible to use Akeeba Backup and a more traditional approach is used, like transferring the files using FTP, dumping the database to a SQL file, replacing the urls in the SQL file from the old url to the new, you will run into trouble if the old and new urls have different lengths (number of characters) because Pagebuilder uses something called serialization.

However, there is a solution:

  1. Transfer all the site files using FTP to the new server
  2. Edit wp-config.php on the new server regarding database host, database name, database username and database password
  3. On the old server, use for example phpmyadmin to export the database to a SQL file
  4. On the new server, import the SQL file using for example phpmyadmin
  5. In phpmyadmin on the new server, go to the PREFIX_options table and find the key siteurl and update it to the new url (do not change anything else)
  6. Log in to wp-admin on the new server and install the Better Search and Replace plugin (this one handles serialization)
  7. Go to Tools -> Better Search & Replace
  8. Enter your old url in the “Search for field” and the new url in the “Replace with” field
  9. Click the “Run Search/Replace” button (this will simulate the search and replace process)
  10. If everything looks normal and it reports there are a number of replacement possible, deselect “Run as dry run” and click the button again