?flush=all or ?flush=1 with SS 3.1.0

2,480 views
Skip to first unread message

swaiba

unread,
Oct 9, 2013, 11:05:41 AM10/9/13
to silverst...@googlegroups.com
Hi,

During the betas I noticed that I needed to use ?flush=1 on any page if there had been a template change, a dev/build is there was a config.yml change and that ?flush=all didn't replace the ?flush=1 for each individual page.

This still seems like the case on final release and I haven't seen this mentioned in the release notes - can anyone please confirm this is intended behaviour as it is rather annoying to have to manually ?flush=1 all the pages all the time.

Marcus Dalgren

unread,
Oct 9, 2013, 3:02:35 PM10/9/13
to silverst...@googlegroups.com
I have this issue too.
I always do dev/build?flush=all which used to flush everything but now I also have to do ?flush=all on the regular site as well.
This flushes all my templates so I don't have to flush every page individually but it's still kind of annoying to have to flush twice.

Simon Welsh

unread,
Oct 9, 2013, 3:10:18 PM10/9/13
to silverst...@googlegroups.com
What each function does:
?flush: (just existing, the =1 isn’t needed)
- Rebuilds the manifests (YAML, statics, classes, templates)
- Flushes the current page’s templates
- Regenerates images on the current page

?flush=all:
- Removes all cached templates *if the page uses SSViewer*. This means it doesn’t happen under dev/build (and never has)

dev/build:
- Rebuilds the database.
- Used to also rebuild the manifests. If your ?flush redirects you to something with a flush token in the URL, this no longer happens.

For template changes, you almost never need to flush as of 3.0. With 2.4, you need to flush if changing an include. As such, you also almost never need to use ?flush=all.

For config changes (either YAML or static based in 3.1) you need to flush.

For adding in classes or templates, you need to flush like normal.

For database changes, you tend to need to dev/build AND flush as then config needs to be flushed before changes get picked up.
>--
>You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
>To post to this group, send email to silverst...@googlegroups.com.
>Visit this group at http://groups.google.com/group/silverstripe-dev.
>For more options, visit https://groups.google.com/groups/opt_out.
>

---
Simon Welsh
Admin of http://simon.geek.nz/

Nicolaas Thiemen Francken - Sunny Side Up

unread,
Oct 9, 2013, 9:29:56 PM10/9/13
to silverstripe-dev
Thank you for the clarification Simon.  If you run ?flush=all then it also runs ?flush=1  (or flush anything as you say) ?
Nicolaas Thiemen Francken  
Sunny Side Up Ltd  {
  Skype: atyourservicehour
  Phone: +64 4 889 2773 
  Emergencies: 0221697577
  n...@sunnysideup.co.nz
  http://www.sunnysideup.co.nz
}







Will Rossiter

unread,
Oct 10, 2013, 1:33:17 AM10/10/13
to silverst...@googlegroups.com
@Simon Welsh might to good to explicitly declare those in the documentation somewhere / how.

swaiba

unread,
Oct 10, 2013, 11:14:13 AM10/10/13
to silverst...@googlegroups.com
Thanks for the response and clarification - just to confirm the answer to my question is that...  after a scripted update that may affect dataobjects, templates, nested/included templates and config yml files The site requires...

1) a dev/build
2) a flush=all (called separately against any valid url)

those two requests will mean every page public or admin will be based on any of the updated items?

swaiba

unread,
Oct 29, 2013, 11:11:49 AM10/29/13
to silverst...@googlegroups.com
FYI Have final found a method for this... here is the code I've used to ensure a dev/build?flush=all acts the same as 2.4...

config.yml

DevelopmentAdmin:
  extensions:
    - FlushOnDevBuild


FlushOnDevBuild.php

class FlushOnDevBuild extends Extension {
function beforeCallActionHandler($request,$action){
if(!$this->owner->response->isFinished() && $action=='build' && $request->getVar('flush')){
SS_TemplateLoader::instance()->getManifest()->regenerate(true);
SSViewer::flush_template_cache();

Nicolaas Thiemen Francken - Sunny Side Up

unread,
Oct 29, 2013, 3:21:50 PM10/29/13
to silverstripe-dev
Can we add this to the core.  A one-stop shop for flushing and building will save a lot of hassle for a lot of people. 

Daniel Hensby

unread,
Oct 29, 2013, 5:33:47 PM10/29/13
to silverst...@googlegroups.com

Yes, part of our deployment relies on being able to call dev/build?flush=all from the cli, so this being in core is somewhat vital!

matt clegg

unread,
Oct 29, 2013, 6:26:49 PM10/29/13
to silverst...@googlegroups.com
If your working from cli you can just use curl todo ?flush=all

Simon seems to have answered this best, it should be in the docs somewhere. I have seen a few people do dev/build?flush=all


Matt Clegg

--Does anyone ever read these things anyway?

swaiba

unread,
Oct 30, 2013, 6:04:44 AM10/30/13
to silverst...@googlegroups.com
I'm sure Simons answer is correct - he normally is - however as you read it notice that he is saying in SS2 you rarely needed to make both calls - but you do in SS3

So I've simply aimed at retaining the same benefit - one call to fully "build" after any change

Daniel Hensby

unread,
May 2, 2014, 9:06:17 AM5/2/14
to silverst...@googlegroups.com

Jonathon Menz

unread,
Aug 25, 2014, 12:16:25 AM8/25/14
to silverst...@googlegroups.com
Hi Simon,

You said that for templates you almost never need to flush as of 3.0 - can you give an example of when you would need to flush after a template change?

Simon J Welsh

unread,
Aug 25, 2014, 12:28:59 AM8/25/14
to silverst...@googlegroups.com
On 25/08/2014, at 14:16, Jonathon Menz <jono...@gmail.com> wrote:

> Hi Simon,
>
> You said that for templates you almost never need to flush as of 3.0 - can you give an example of when you would need to flush after a template change?

When you add a new one or when the modified time of the template file is older than that of the generated template but has newer content. The latter case is extremely rare.

Jonathon Menz

unread,
Aug 25, 2014, 6:49:08 AM8/25/14
to silverst...@googlegroups.com
Thanks for the clarification Simon!

It looks like this is all going to be a lot simpler soon: (perhaps slated for 3.1.7?) https://github.com/silverstripe/silverstripe-framework/commit/2b316e79e5f957bfe06385f762c237acaf75b0e7
Reply all
Reply to author
Forward
0 new messages