I don't manage to update Flag module in remote server, while it worked like a charm on local environment. The stage site is cached with Zend opcache, Apcu, Varnish and Redis. I suspected Opcache was faultier but no way to get it work.

The steps I did (local dev) :

  • drush up flag -y
  • drush cc all. Tested flag features, OK.
  • Commited & pushed files to stage on a flag branch

The steps then on remote server :

  • git checkout flag
  • Reset Opcache various times (thanks to this great Opcache GUI)
  • Saved database
  • Ran update.php, which returned

    flag module
    7300 - Rebuild the class registry due to classes moving files.
    7301 - Rename {flag_content} table to {flagging} and {flags} table to {flag}.
    7302 - Rename database columns on the {flag} table.
    7303 - Rename database columns on the {flagging} table.
    7304 - Rename database columns on the {flag_counts} table.
    7305 - Convert flag roles to permissions.
    7306 - Convert flag view modes settings.
  • Ran Apply pending updates, which retunred An unrecoverable error has occurred, Ajax error, http status 200, followed by 4 notices. These notices are known, but caused no update crash on local site.

  • if I go to the "error page", I'm sent back to Review updates page.

If I try to visit dblog, I have this fatal php error : Class 'flag_flag' not found in profiles/commons/modules/contrib/flag/flag.module on line 1948. But if I check the remote files, I can find that class in profiles/commons/modules/contrib/flag/includes/flag/flag_flag.inc .

I invalidated that file namely in Opcache and invalidate full Opcache. I also checked in varnish.vcl that update.php is in the list of bypassed URL.

Then after a while, Varnish finds backend server is not responding and boom : Error 503 Backend fetch failed, ending restarting php5-fpm...

To be honest, I understand about nothing anymore, "eating my hat" or "banging my head" or how would you say that ? Help really welcome !

  • And you don't have drush access on the remote server, right? Jan 26, 2017 at 16:21
  • Yes i have remote drush access
    – Kojo
    Jan 26, 2017 at 16:23
  • 1
    Do you use Drush? It seems like a case of a moved class file, which can sometimes cause these issues with caching, and can be solved using Drush Registry-Rebuild. If you have Memcache on the server, you should restart that too.
    – Beebee
    Jan 26, 2017 at 16:23
  • 1
    Some people also attribute this to APC. (Warning: old thread circa 2011) See here
    – Beebee
    Jan 26, 2017 at 16:25
  • 2
    And I would also try running the updb from drush, I am not sure if op-caching applies there, so it could help. Jan 26, 2017 at 16:28

1 Answer 1


Short answer : make extensive use of drush !

This was quite straightforward and successful, though I'm still not really sure if I have to empty both opcache and Varnish. This would be a huge performance hint on production server. IMO the best would be to invalidate only the changed files in opcache and voilà ?

Steps I did (local dev) :

  • drush up flag -y
  • drush cc all
  • tested flag features, OK.
  • commited & pushed files to stage on a flag branch

The steps then on remote server :

  • git checkout flag
  • varnishadm -T -S /etc/varnish/secret (enter Varnish Cli)
  • varnish> ban req.http.host ~ dev.example.com && req.url ~ . (clear varnish cache)
  • reset Opcache with Opcache GUI
  • drush updb
  • drush rr (optional in that case since this was performed in flag_update_7300)
  • 1
    Thanks a lot to @Beebee and StefanosPetrakis for their quick help and putting me on the right direction !
    – Kojo
    Jan 27, 2017 at 10:11
  • 1
    Glad you got it sorted. Varnish shouldn't be mandatory to empty, as it doesn't really touch PHP and MySQL until next time it talks to Apache, so it should clear by itself soon afterwards. However, I think you should instead add OPcache, APCu and Redis cache clears (no redis experience, correct me if I'm wrong) when you make a release which changes php files/updates the db.
    – Beebee
    Jan 27, 2017 at 10:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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