I have a website running the Photocrati theme version 4.9.3 on an AWS t2.micro running Amazon Linux. I use PHP 5.6 with php-fpm and a very recent version of Nginx, compiled with a couple of modules. I have CloudFlare in front of the website, but it accepts connections only from CloudFlare not directly.

One Wordpress 4.5 site running Photocrati keeps going down, because for some reason the siteurl in the wp_options table keeps getting changed to


I can fix it with the SQL below, but it's annoying, causing downtime. I've scripted this so cron runs it every five minutes - obviously this isn't a great solution, but it will do until I can get it fixed properly.

update wp_options set option_value = "https://www.example.com/" where option_id = 1

I have three other sites on the same server that are fine. None run photocrati - they run a variety of other themes. As far as I'm aware nothing has changed that recently - I switched from Nginx to PHP 5.6 around a week ago, but this started happening 3-5 days after I made that change. All the sites run the same plugins, listed below. I've set up the MySQL query log on RDS, maybe that'll give me a hint.

Contact Form 7
Contact Form DB
Google Analytics by MonsterInsights (it just changed its name to this)
Remove query strings from static resources
Ultimate Nofollow
UpdraftPlus - Backup/Restore
Yeost SEO

Photocrati support replied and said they don't know what's going on.

I've done site security scans with securi (plugin and website) and Wordfence. No issues found.

File permissions are all set as restrictive as I can get away with while still allowing auto updates and plugin/theme installs via the web ui. I can see the SQL being executed in the database, when I look for anything malicious in the access log there's nothing significant there - an innocuous query hitting a category of the blog.

Has anyone seen anything similar? Any suggestions how to fix the underlying issue? How do I even track this one down? I need to work out which line of code is running that query.

To be clear - I can bring the site up when it goes down very easily, I'd really appreciate help working out why it's happening. I'm an ex enterprize developer so I'm fairly technical, I've been using Wordpress for quite a few years, I'm good with it - I just don't develop for it so I don't really know the problem.

Note that I posted this question on this site first, but someone told me this site isn't for support. I posted it on Server Fault and they moved it back here.

  • You are either hacked or have a bug somewhere in your site. Fixing this specific issue is easy, codex.wordpress.org/Changing_The_Site_URL but it might be a symptom of a bigger problem. Apr 17 '16 at 6:14
  • I did scans with Securi (website and plugin) and Wordfence and it found nothing. I rather suspect that it could be a bug in the theme, it's ok but can be quirky. It occurs to me that I did upgrade to PHP 5.6 recently, though that was a few days before this started.
    – Tim
    Apr 17 '16 at 7:34
  • f those plugins have any DB write audit capability, maybe it is time to activate it Apr 17 '16 at 7:43
  • as for your last update, it can always be up to selection of phrasing, but even now the question bordering off-topic because it either requires access to your server or a bug in the theme that only the author can solve Apr 17 '16 at 7:48
  • Yes I think the question may be off topic, which is why I posted it on server fault. I can see the SQL executed changes my site URL, I just don't know what piece of code is calling it. Is there any way to turn on general database auditing on Wordpress? I suspect the theme, not plugins, as the plugins have been working on other sites for ages. Plugin author is very reputable, but have said they have no idea.
    – Tim
    Apr 17 '16 at 8:55

If this is done via WP Options API (as opposed to direct SQL query on database) you can use hooks to log it.

Something along the lines of (not tested, make sure it works under normal option save first):

add_filter( 'pre_update_option_siteurl', function ( $value ) {

    error_log( wp_debug_backtrace_summary() );

    return $value;
} );

Next time it happens you should get much better idea about underlying reason from the backtrace.

Until you got it fixed you could also hardcode this into configuration to prevent breakage itself:

  • Thank you, that seems like a much better stopgap than running a database update script every minute using cron! It will give me time to work out what the actual problem is. I'm going to try migrating to another theme in the next few days, then I'll turn that setting off and see if it still happens.
    – Tim
    Apr 17 '16 at 19:05
  • Wordpress n00b question - where do I add that filter code?
    – Tim
    Apr 17 '16 at 19:42
  • Since you want to catch whatever is causing the issue you probably want it as early as possible. I would say must use plugin would be fitting for this case.
    – Rarst
    Apr 17 '16 at 19:46
  • Brilliant, thank you for that, it's very much appreciated. I'll create the wp-content/mu-plugins directory, add that code in it's own .php file, test the site works, test that Wordpress logs are enabled and showing output, take the stopgap out of the wp-config.php file, and wait. Thank you :) I'll report back in 12 - 24 hours.
    – Tim
    Apr 17 '16 at 20:14
  • I added another log statement in that block so I could easily find the output. What it output was "update_option, apply_filters('pre_update_option_siteurl'), call_user_func_array, {closure}". That doesn't tell me anything... does it tell you anything? In Java I'd print a stack trace, which would tell me exactly what line of code it was called from.
    – Tim
    Apr 18 '16 at 19:20

I think you messed up the value. home and siteurl values should not end up with a slash.

A better query (assuming WP is in the root directory) would be:

UPDATE wp_options
SET options_value = 'https://www.example.com'
WHERE option_name IN ('home','siteurl');
  • Thanks for the tweak :) It works as it was but best to have it exactly right. That's not what I need help with, I need help solving the underlying problem rather than putting a band aid on. It's happened 8 times in the past two days :(
    – Tim
    Apr 17 '16 at 7:33
  • What new values get into your tables?
    – RRikesh
    Apr 17 '16 at 13:50
  • 1
    Trailing slashes in these options are irrelevant, WP forcefully removes trailing slashes from them on option retrieval.
    – Rarst
    Apr 17 '16 at 16:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.