All Atahualpa settings suddenly reset
 

Has anyone been in a similar situation:

On one of the sites I've made with Atahualpa, all Atahualpa settings have been reset. Can the site have been hacked?

It seems like the widget areas I've defined is still there, but all other settings including CSS inserts, are gone.

I do have a backup of the settings from February 1st, but this doesn't seem good.

Any similar experiences?

I was able to restore the settings from the backup file, and adding the changes I made since the backup, but I'm still wondering how this can happen?

Will now make it a habit to use the "export settings" function every time I make changes.

The only way I've seen the settings reset is by pressing the 'Reset all settings' button

Yeah, and that possibility is almost certainly ruled, unless some cracker has gained access to one of the admin accounts.

We will contact the host to see if they have any relevant information.

Take a look at the plugin 'wp dbmanager' if you can get it to work you can schedule automatic database backups.

I have Austin Matzko's WP DB Backup plugin doing that already, but thanks for the tip :-) It works okay, even though it's beginning to get old. I have restored DBs from it though.

I see that the one you mention are more up to date.

It has happened three times more since I wrote the first post.

The webhost suggests that it looks like the reset is made by some plugins, that uses cache and tries to optimize the theme. I have asked for more details. I have no clue yet to which it could be.

What command, code or action could reset the Atahualpa settings except clicking on the reset button?

If anyone has had related experiences, I'd be glad to hear them.

I did have something similar happen a while back on a clients' site. It turned out that the webhost was applying a (old) backup periodically. There was some setting in the hosting control panel that turned it off... It was definitely an "odd" thing for them to do.

I can't remember off the top of my head who the hosting company was.

The way I finally figured out what was going on was when I noted that the date stamps on some files would overnight change to an earlier date.

Go figure!

Ken

Hi Ken,

Sounds like a strange practice, but it's not what's happened in my case, because if the host in my case had gone back to a previous backup, it would not be the same as a total reset of Atahualpas settings.

In my case I believe it has something to do with W3 Total Cache, which someone else than me activated on the site. My research show that the problem started the day after the date this plugin was activated.

The host has written back that W3 Total Cache has some function, where it reverts to a lightweight theme or someting like that, when the server is under pressure, and one of these breakdowns did happen one night when the server had severe problems.

The strange thing is that the problem continued when W3 Total Cache was deactivated. But the other day I discovered that there was left-over W3 Total Cache-directives in the .htaccess in the rootfolder of the domain. I removed them. I don't know, if those directives would be able to do something on their own. I saved them, if anyone is interested.

Kind regards,
Jakob

I'd like to see what they are.

Okay, they are attached here in a txt-file.

I just found out that the connection between the activation of W3 TC and the mishap is maybe not so solid, because I just looked at the timestamp of the plugin folder and files, but the breakdown also happened before that date, i.e. around the time when I started this thread.

it doesn't look like it should cause an issue.

No, it would also be strange.

I guess some SQL-query would have to happen in order to reset all settings of Atahualpa. It has happened at times when the server(s) were under high pressure and other sites/domains on the same server didn't work either.

the fact is that the atahualpa settings are stored in the database. There are two ways I can think of to reset the theme settings.
1) delete the row containing the settings from the wp-options table or
2) hitting the 'Reset ALL theme options' button and then saying yes to the dialogue box.

there is a thire whidh would be to restore the database to a time befor the theme was activated, but that would effect all the posts too so I don't think that is in consideration.

now maybe, and this is a maybe, there is some way to craft a html statement that will cause the theme to think the 'reset' button was pushed AND bypass the confirmation dialogue, but I have no idea how you might do that and can't see it being done by anyone by visiting the site.

If I was investigating this I would
1) do a hourly backup of the database.
2) get a hold of the error and access logs daily

then when it happened I would look at the logs to see if I could see what was going on.
I'd run a compare of the database export files to see when the change occured and see if anything else happened.

Once I figured out the time frame, I'd be on the horn to the host and have them investigate. If the tech can't help, I'd ask to speak to his manager, if he can't help I'd go to his manager.

Actually I think I would be moving hosts if the only thing they are doing is pointing the finger at a plugin that is used by lots and lots of people. You would think the issue would have cropped up for the options of other themes and plugins by now.

1) Well, if the row was deleted, wouldn't I then have a problem using the import function in ATA afterwards, because there would be no row to save to?

2) This seems very implausible in this case.

3) Not the case, because all WP content was still there.

My first reasoning was that it was some kind of attack, maybe some sort of SQL-injection, but I have nothing to hang my hat on there.

Your methodology sounds good and indeed, another host is in the cards.

if the theme can't find the row with it's options, it builds it with all the defaults. this is what it does when you first activate it.