Weblog unintentionally reset by something unknown

[marc]

I've Pivotx 2.3.3 installed since two months.
Last week and this week we had a problem, the settings of the two weblogs on the website were gone, and replaced by a default setting.
I already fixed it by making the new setting, but I still don't know why the weblog settings disappeared.
Does anyone know why, or did you experienced the same problem with 2.3.3 ?

Thanks,
Marc

[hansfn]

If you search the forum, you'll notice that some users have struggled with this. The protection against such resets are better in 2.3.X that the older versions of PivotX, but it can still happen - apparently. As far as we know, it's related to file system issues in some way. There is currently no cure, except taking back-ups of the configuration from time to time. If this turns out to happen very often for you, I would recommend trying another blog tool (like WordPress) which stores also the settings in a MySQL database.

PS! For people using flatfile databases: The problem discussed above is not known to reset entries or pages.

[localhost]

Jep, I was one of them. In the end I just blamed Dreamhost. After they moved me to a different server, the issues were gone.

[RiCK]

The same thing is happening on one of my clients installations of PivotX.
I've narrowed it down to one file that seems to be the problem..

pivotx/db/ser_weblogs.php

This file resets to a default installation version.
We fix it by uploading a backup of the file over the top, and it runs fine for awhile, until next time it does this, which can range from a few days to only an hour.

Have tried changing the permissions various ways, including locking the file from writing, but then the blog nor admin panel will load with it locked.

Does anyone have any suggestions for this yet or anything further to add?

[hansfn]

If you are running the latest version of PivotX, we can't really help you. We have tried tracking it down for some other users, but failed. The problem is to catch the situastion when it happens ...

[localhost]

The same thing is happening on one of my clients installations of PivotX.
I've narrowed it down to one file that seems to be the problem..
pivotx/db/ser_weblogs.php
This file resets to a default installation version.
We fix it by uploading a backup of the file over the top, and it runs fine for awhile, until next time it does this, which can range from a few days to only an hour.
Have tried changing the permissions various ways, including locking the file from writing, but then the blog nor admin panel will load with it locked.
Does anyone have any suggestions for this yet or anything further to add?

Who is the hoster? Could be their issue. In my case, like I already mentioned, the issue was somehow caused by Dreamhost. After they moved my account to a different server, the issue was gone. And it was exactly the same issue, although I believe it was a different file in the same directory. I went as far as setting up a cronjob running every 5 minutes restoring the file to one I knew was working.

[RiCK]

The same thing is happening on one of my clients installations of PivotX.
I've narrowed it down to one file that seems to be the problem..
pivotx/db/ser_weblogs.php
This file resets to a default installation version.
We fix it by uploading a backup of the file over the top, and it runs fine for awhile, until next time it does this, which can range from a few days to only an hour.
Have tried changing the permissions various ways, including locking the file from writing, but then the blog nor admin panel will load with it locked.
Does anyone have any suggestions for this yet or anything further to add?

Who is the hoster? Could be their issue. In my case, like I already mentioned, the issue was somehow caused by Dreamhost. After they moved my account to a different server, the issue was gone. And it was exactly the same issue, although I believe it was a different file in the same directory. I went as far as setting up a cronjob running every 5 minutes restoring the file to one I knew was working.

The host in this case was GoDaddy. We still have not found a permanent solution to resolve this issue.