CRITICAL ISSUE

POSSIBLE ROLLBACK OF THE SITE VERSION TO THE STATE OF THE DEMO THEME

Yootheme Pro for Wordpress

This article is regularly updated and supplemented with new data.

Last update: 30 September 2021

On Yootheme support section sometimes meet messages that the user's site was unexpectedly reset to the state of a demo theme. This happened spontaneously, without the user's participation, and was not the result of an update or any operations on the site…

Michael Maas immediately conducted his investigation and collected all similar cases for analysis. The results of the investigation were passed on to the development team, who were able to find out that in some cases the `/wp-content/install.php` file was not deleted from the folder after the installation was completed, as it should happen and remained in place.

The team immediately released an update Yootheme Pro 2.5.6 where an additional check was added, which checks for the presence of a file and tries to delete it again. Warp 7 themes have received an update also.

Despite this, the reset cases are still ongoing, so the team added another alert in version 2.5.9+.

Is your site already damaged?

Everything that is written at the very beginning does not matter, if you have Yootheme Pro or Warp theme, you should immediately read the section on how to fix everything.

What happens to the site as a result of this problem?

All content, menus, and settings of the theme and plugins return to the state of the demo theme at the time of its upload to the site.

This means that you and your clients may lose all the results of their work.

How does this happen?

For this to happen, someone must call the file using a direct request with the necessary parameters. I believe that this can be done by exploit scanners that visit various sites daily in search of vulnerable sites. An ordinary person cannot accidentally open this file by clicking on a link on the site, this can only happen if his address is specially entered manually with a certain parameter in the url.

Why is this happening?

I believe that some servers have special security settings or a PHP configuration that does not allow you to perform the `unlink` function, which is written at the end of this file, or the access rights to the file prohibit its deletion.

Which sites are at risk?

All sites that were deployed using the demo theme and use Yootheme Pro and Warp on Wordpress are at risk. 

The version of the theme does not matter, it can be any site starting from Yootheme Pro 1.0.

Is there a problem with the site on Warp?

Yes, this problem also exists for sites based on the Warp framework. The team made corrections for all demo packages and updated them on their website.

Which sites are safe?

Sites on WordPress on which the theme was installed as a separate package (uploaded a new theme only), without using the demo version and installing demo content are also out of danger.

However, there may be other scenarios that will have a different reason. Read the entire material to the end to get the information I know.

What should I do now?

You should do 3 things:

  • make a backup of the entire site

  • update the theme version to a version not lower than 2.5.9

  • be sure to check the presence of the `install.php` file in the `wp-content`folder, if it is still there – delete it immediately

If you found a file: /wp-admin/install.php

Pay attention to the name of the folder, the problem occurs only with the file in the /wp-content/ folder.

The file in the wp-admin/install.php is the WordPress core file, it is safe file.

You should not delete it!

What should I do if I no longer have access to the site?

I assume that the problem can concern any site for your customers, regardless of whether it is on your support or not. I recommend checking all your work over the past years to find problematic sites.

You just need to type a request like: [domain.name]/wp-content/install.php in the address bar.
If the site does not return a 404 error, then there is a reason for concern.

You can contact the site owner to tell them about this problem. I believe you can turn this situation around in such a way as to get your own benefit or increase your business reputation. A direct request for an address is safe for the site, the problem occurs only when requesting an URL with a certain parameter (I will not write an example so as not to teach you bad things).

Can this situation happen again in the future when updating Wordpress or the site theme?

No. If you solve the problem now, it will never bother you on this site again. I advise you to update your work/local demo packages to the latest versions (download the new ones from the Yootheme website) or check the file deletion if you are using an old demo package.

I also believe that the problem depends on the server, so if you host sites on the same server and do not find traces of this file, then you are safe, and if you find the installation file on one site, then all other sites are at risk.

What did the Yootheme team do to fix the problem?

The algorithm for installing demo data in themes has been completely revised, now it is impossible to repeat this problem with any queries and url parameters.

Also, as I wrote above, the team has released a theme update that checks for the presence of the install.php file and tries to delete it. However, the same unlink function is used to delete the file as before. Therefore, if the server prohibits calling this function or the file access rights do not allow you to delete it, the problem will remain and you will need to delete the file through FTP or a file manager on your hosting.

In version 2.5.9, the team has additionally changed the verification algorithm. Now the theme checks for the presence of the file every time the control panel loads and tries to delete it. If this file is not deleted, a message will appear on the control panel, as shown in the screenshot.

27.08.21 all Warp themes have received an update also.

What should I do if the site has already suffered from this problem?

Only a return to the backup copy is able to return the site.

All another ways you can find below.

I still see my pages on the site, but they are not in the admin panel
You are seeing pages from the cache. Save them to your computer, it may be useful to you if you have to create layouts again. Do not clear the cache until you have saved all the contents. This is not an error, if you do not see the page in the admin panel, then it definitely does not exist, but if you reset the cache, you will lose the little that remains!
Reasons for concern

Despite the efforts of the team from the release of version 2.5.6 to the release of version 2.5.9, we received messages from several users who encountered this problem. Most often, the problem was on sites that were not updated to version 2.5.6 +, so it is important to check your sites for an installation file or update the theme to the latest version.

If the file is still in the folder, then most likely the theme will not be able to delete it and in any case, manual intervention will be required. Otherwise, it would have been deleted immediately after installing the demo theme. Below you will find a list of hosting companies on whose servers problems were noticed.

Do not expect to be tested in the new version of the theme.

The current file verification algorithm looks for the phrase "shutdown" in the first 500 lines, but I can't be sure that this is enough. Although I fully trust the team, I can't check this for Warp themes, I also believe that such a mode of writing files via FTP is possible, which adds empty lines through one (you probably have encountered this once). Therefore, I recommend that you check the sites again yourself through a request [domain.name]/wp-content/install.php (this request is safe).

You didn't find the file, but the site was reset

It's amazing, but I've seen a couple of such messages. I investigated these cases and they had a completely different characters.

In the first case, the site was broken simply because of an incorrect htaccess file configuration, and in the second case, a backup of the site was stored on the hosting, which was deployed at the request of the recovery file.

This means that you should check how your backups are stored, whether there is a copy of the site, and a script for restoring it in the site folder.

If you use Akeeba backup plugin, then check that there is no kickstart.php file in the root folder, it can be used to restore a backup copy, as well as to unpack any ZIP archive from the same folder.

Reasons for calm

I would like to note that the probability of detecting this problem is quite low, since we have not received mass complaints for the last 10 years and the first reports appeared only at the beginning of June 2021. 

The update has already been released, and we expect that the problem will be solved independently by users as soon as they see a new notification in the control panel.

I have sites only on Joomla

Sites on Joomla are not affected by this problem.

However, if you are an active user of the Akeeba backup component, make sure that the demo package of the theme is not saved in the root of the site and there is no kickstart.php file. This is unlikely to cause a site reset, however, a copy of the project may be detected by another person.

Also, the kickstart.php file can be used to unpack any ZIP archive that will be found in this folder.

List of hosting companies that can be classified as a risk group

  • Genesys Informatica s.r.l.
    http://www.gif.it/
  • Media Temple Hosting
    https://mediatemple.net/webhosting
  • Liquid Web Managed WordPress Hosting
    https://www.liquidweb.com/products/managed-wordpress/
  • GoDaddy.com Inc.
    http://godaddy.com/
  • DinaHosting S.L.
    http://dinahosting.com/
  • PrivateSystems Networks
    http://privatesystems.net
  • World4You Internet Services GmbH
    http://www.world4you.com/
  • CyrusOne LLC
    http://www.cyrusone.com/
  • Domainfactory
    https://www.df.eu
  • M-net Telekommunikations GmbH
    http://www.m-net.de/
  • Bluehost
    https://www.bluehost.com
  • Sternforth Ltd t/a Web World
    https://www.webworld.ie
  • Ionos
    https://3elementos.eu/

How to restore a website if the problem has already happened

Only a return to the backup copy is able to return the site.

Set a prohibition on indexing the site by search robots until the site is restored. This will allow you to minimize the loss of SEO positions.

The code you should put in your robots.txt to disallow all:

User-agent: *
Disallow: /
I have a backup

Just deploy your backup to return to this version of the site, then make the changes that occurred on the site after creating this archive.

I don't have a backup

1. Have you installed any site backup plugins on this site?

If so, then you should look for saved backups in the folders of these plugins. Refer to the plugin documentation on the developer's website to get information on where to find the backup file and how to use it to restore the site.

2. See the list of backups in the hosting control panel.

Request your hosting provider for the possibility of restoring a backup copy of the database or the entire site from those copies that are stored with them. Providers always make their own backups, even if you use your own VPS server and manage the resources yourself. You can motivate him to do this work, offer to replenish the balance of your personal account for an additional 3-6-12 months (this way you will simply extend the payment period for your placement, but the provider will be able to use this money immediately).

It is also possible that you will receive an answer that the backups are stored only for a few days, but this is not enough for you. In this case, ask the hoster about the availability of a backup copy for the entire server, which will also include your site, among other things. To restore a site from such a copy, you need to put a lot of effort, so be prepared for negotiations and additional motivation for the company to do this work. This may be your only chance.

Evaluate your risks

If you understand that the project is very important and you will have to restore it anyway, start acting right now.

As I said above, install immediately a prohibition on indexing the site by search robots until the site is restored.

If the site was indexed by search engines, you need to view and download cached copies of the previous pages of the site as soon as possible. Act very quickly, because the data in the cache can be updated within 1-3 days.

How to view the cache page of the site

To search for cached site pages, you usually need to enter a query like as site:[domain.name] and click the action icon to select viewing a cached copy of the page.

Save the cached copies of the pages to your computer.

If you didn't find anything in the cache of the main search engines, then look in Google for a list of other search engines, there are several dozen of them around the world, so there are still chances to find something.

Your last hope will be an Internet archive, which can find snapshots of the site for past dates.

Copy the HTML content of the pages and use it to restore the content of the pages in HTML form. This will allow you to return most of the style and data, but then there is a lot of work to reassemble all the layouts.

Based on this, half of your efforts should be directed to finding a backup.

Good luck!


If you need my help or advice, contact me in the chat on my website or write me an email, I will be happy to help you.
If you are a website developer, subscribe to my newsletter to receive important news.
You can also find them on my Twitter and Telegram channel.

Subscribe to Our Newsletters

Yootheme Tricks

Newsletter Yootheme tricks

Yootheme news
For developers

Newsletter for developers