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+.
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.
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.
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.
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.
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.
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.
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.
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
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!
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).
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.
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.
Only a return to the backup copy is able to return the site.
All another ways you can find below.
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).
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.
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.
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.
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: /
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.
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.
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.
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.