Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba

?flush=all not working


Go to End
Reply


7 Posts   2111 Views

Avatar
Rossel

Community Member, 18 Posts

3 August 2013 at 12:33am

?flush=all or ?flush=1 does not work in any situation. everything else seems to be working fine.
Has anyone had this happen before or know what might be causing this?
I have no idea...

Avatar
martimiz

Forum Moderator, 1199 Posts

3 August 2013 at 1:33am

I've never encountered it just 'not working'. I had some issues where erights were not set properly on building the silverstripe-cache for the first time, so that I got a 'not writable' error each time I used ?flush, but...

So no errors? And your template (or yaml) changes are never aplied? Do you have the silverstripe-cache directory in your site root and is it writable?

Avatar
Rossel

Community Member, 18 Posts

4 August 2013 at 1:45pm

thanks martimiz, would have never noticed that.
So the silverstripe-cache didnt exist so ive created it. ran dev/build?flush=all and the cache has been populated with files. however all I get in dev/build is an 'Enviroment Builder' title along with my base url and dev breadcrumbs but nothing else.

Avatar
martimiz

Forum Moderator, 1199 Posts

4 August 2013 at 9:09pm

Edited: 04/08/2013 9:10pm

So no list of database tables and fields? Might be an error along the way, that isn't displayed... Is your site in dev mode? Is your php.ini set to report errors? Uncle Cheese has a page on debugging SilverStripe on his site:

http://www.leftandmain.com/silverstripe-tips/2010/09/08/8-common-silverstripe-errors-explained-and-solved/

I'm not sure if it includes v3.x but it might give you some clues

Note: basically the flush bit is what updates the SilverStripe cache files, the dev/build is what builds the database table. The combi does all :) If the silverstripe-cache dir is missing, SilverStripe will use the tmp directory, that doesn't always work well.

Avatar
Rossel

Community Member, 18 Posts

5 August 2013 at 6:44pm

Its strange, the database was generated, site was set to dev mode, php.ini was set to report errors and I had a look at the 8 common erros a few time and it didnt help. Dev/build works on its own but with ?flush=all or ?flush=1 it failed. (Had been trying to flush when adding a couple of modules)

I ended up doing another clean install and this time it seems to work. I did noticed that my url would not redirect from mydomain.com.au/silverstripe/ to mydomain.com.au/silverstripe/install.php like normal, as i found this is in the .htaccess file but it seems to be ignored.

When re-installing there were no errors in the installer. but it didnt create silverstripe-cache again, had to do that manually. It does seem to be all working fine at the moment. so thanks for your help @martimiz.

Avatar
Sygmoral

Community Member, 31 Posts

10 February 2015 at 2:25pm

Edited: 10/02/2015 2:45pm

I ended up here after a search on Google, so I thought I'd share the solution to a similar problem I had.

I just upgraded to php 5.6, and all my SilverStripe installations stopped working, displaying only a fatal error (some memory overflow while in Core.php I believe). Calling flush=all solved the issue on half of the sites, but for the others that simply didn't do anything. I ended up removing the cache folders manually, which by default are located under /tmp/ with names such as /tmp/silverstripe-cache-*

Avatar
martimiz

Forum Moderator, 1199 Posts

10 February 2015 at 10:11pm

Great that you have everything working again!

I always add the silverstripe-cache directory to the root of my websites. This will Make SilverStripe automatically use it, and I find it far better to maintain, then finding out where the tmp dir is all the time. On a PHP upgrade nowadays I always just empty the cache by hand, to avoid problems - but some may have reasons to not want to do that.

Still - I strongly object to providers doing major software upgrades without informing the users. But some do....

Note: In contrary to what I said above in ss3.1 doing a /dev/build?flush=1 doesn't seem to automatically flush the cache anymore.