New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require all simplecacheable views to have a filename extension #8381

Closed
ewinslow opened this Issue May 28, 2015 · 9 comments

Comments

Projects
None yet
2 participants
@ewinslow
Member

ewinslow commented May 28, 2015

The lack of an extension on views like js/elgg and css/elgg seems like the main reason we cannot have PHP-less routing of simplecached views. There is no way to have a filesystem that looks like so:

cache/12345678/default/js
  elgg # file
  elgg/ # directory
    dev.js

Note that this transition could be made in a 1.x plugin already, so authors wouldn't have to make this switch and upgrade to elgg 2.0 at the same time.

Can anyone think of a more automatic way to make this happen?

@ewinslow

This comment has been minimized.

Show comment
Hide comment
@ewinslow

ewinslow May 28, 2015

Member

Lack of an extension also prevents seamless integration with AMD, in the case of JS files.

Member

ewinslow commented May 28, 2015

Lack of an extension also prevents seamless integration with AMD, in the case of JS files.

@ewinslow

This comment has been minimized.

Show comment
Hide comment
@ewinslow

ewinslow May 28, 2015

Member

This would unfortunately be a major breaking change that would break practically all plugins 1.8-style. :(

Member

ewinslow commented May 28, 2015

This would unfortunately be a major breaking change that would break practically all plugins 1.8-style. :(

@mrclay

This comment has been minimized.

Show comment
Hide comment
@mrclay

mrclay May 28, 2015

Member

So all simplecache views would basically be:

/views/default/foo
  bar.html(.php)?
  bar.js(.php)?
  bar.css(.php)?

I suppose we could implement a limited set of aliases so extending js/elgg would actually extend js/elgg.js and similarly for CSS.

Member

mrclay commented May 28, 2015

So all simplecache views would basically be:

/views/default/foo
  bar.html(.php)?
  bar.js(.php)?
  bar.css(.php)?

I suppose we could implement a limited set of aliases so extending js/elgg would actually extend js/elgg.js and similarly for CSS.

@mrclay mrclay closed this May 28, 2015

@mrclay

This comment has been minimized.

Show comment
Hide comment
@mrclay

mrclay May 28, 2015

Member

Wrong button.

Member

mrclay commented May 28, 2015

Wrong button.

@mrclay mrclay reopened this May 28, 2015

@mrclay

This comment has been minimized.

Show comment
Hide comment
@mrclay

mrclay May 28, 2015

Member

When you say "PHP-less routing" do you mean served by the HTTPd directly?

Member

mrclay commented May 28, 2015

When you say "PHP-less routing" do you mean served by the HTTPd directly?

@mrclay

This comment has been minimized.

Show comment
Hide comment
@mrclay

mrclay May 28, 2015

Member

If so I don't see that as must-have since the entire cache/ URL space is trivially cacheable via Varnish and other HTTP caches.

Member

mrclay commented May 28, 2015

If so I don't see that as must-have since the entire cache/ URL space is trivially cacheable via Varnish and other HTTP caches.

@ewinslow

This comment has been minimized.

Show comment
Hide comment
@ewinslow

ewinslow May 28, 2015

Member

Yes, you have the right idea of what I'm going for.

Yes, served by httpd directly.

Varnish is a great point, and maybe that's a good enough reason to close this ticket.

If we do decide that, then there is no reason to block movement of all static assets including images to the views system.

I believe i recall @Srokap having concerns about this.

Member

ewinslow commented May 28, 2015

Yes, you have the right idea of what I'm going for.

Yes, served by httpd directly.

Varnish is a great point, and maybe that's a good enough reason to close this ticket.

If we do decide that, then there is no reason to block movement of all static assets including images to the views system.

I believe i recall @Srokap having concerns about this.

@mrclay

This comment has been minimized.

Show comment
Hide comment
@mrclay

mrclay May 28, 2015

Member

Service through PHP also allows auto-minify, and I don't know how we'd direct HTTPds to the "correct" view location among the plugins.

Member

mrclay commented May 28, 2015

Service through PHP also allows auto-minify, and I don't know how we'd direct HTTPds to the "correct" view location among the plugins.

@ewinslow

This comment has been minimized.

Show comment
Hide comment
@ewinslow

ewinslow Jun 5, 2015

Member

This is something we need to make a firm decision on for 2.0

Member

ewinslow commented Jun 5, 2015

This is something we need to make a firm decision on for 2.0

@ewinslow ewinslow added this to the Elgg 2.0.x milestone Jun 5, 2015

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 19, 2015

feature(assets): Get rid of js/ and css/ directories
All views are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 19, 2015

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 19, 2015

feature(assets): Get rid of js/ and css/ directories
All views are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 19, 2015

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 19, 2015

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 19, 2015

feature(assets): Get rid of js/ and css/ directories
All views are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 19, 2015

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 19, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 19, 2015

@ewinslow ewinslow referenced this issue Jun 19, 2015

Merged

Ditch js/* and css/* views prefixes #8526

6 of 6 tasks complete

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 20, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 20, 2015

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 20, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 20, 2015

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 20, 2015

chore(views): Cache assets by viewtype/view, not md5(viewtype/view)
This opens up is the possibility that we'd be able to serve cached
files directly off disk instead of via PHP for performance.

This also makes it much easier to explore the available cached resources
by navigating to dataroot/views_simplecache and browsing around.

Fixes #8381

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 20, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 20, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 23, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:
This re-configures view location storage such that full paths are stored,
not just paths to view directories. In particular, `elgg_get_view_location` and
`elgg_set_view_location` return and expect full paths respectively.

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 23, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Certain uses of the `view,$view_name` and `view_vars,$view_name` hooks will not work.
See the docs on "View aliases" for more info.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 24, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Certain uses of the `view,$view_name` and `view_vars,$view_name` hooks will not work.
See the docs on "View aliases" for more info.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 24, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Certain uses of the `view,$view_name` and `view_vars,$view_name` hooks will not work.
See the docs on "View aliases" for more info.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 24, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Certain uses of the `view,$view_name` and `view_vars,$view_name` hooks will not work.
See the docs on "View aliases" for more info.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 24, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Certain uses of the `view,$view_name` and `view_vars,$view_name` hooks will not work.
See the docs on "View aliases" for more info.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 25, 2015

feature(assets): Get rid of js/ and css/ directories
All views under these directories are implicitly "hoisted" up one level.
They are also given the appropriate extension:

 * js/view => view.js
 * css/view => view.css

The main benefit this brings is being able to co-locate related assets.
So a template (view.php) can have its CSS/JS dependencies right next to it
(view.css, view.js). Compare to the current approach which is like so:

 * Template: page/components/module.php
 * CSS: css/elements/modules.php
 * JS: None in this case, but how would you know with any confidence?

BREAKING CHANGE:

Great care has been taken to make this change as backwards-compatible as possible,
so you should not need to update any view references right away. However, you are
certainly encouraged to move your JS and CSS views to their new, canonical
locations.

Certain uses of the `view,$view_name` and `view_vars,$view_name` hooks will not work.
See the docs on "View aliases" for more info.

Refs #8381
Fixes #8382

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 26, 2015

chore(views): Cache assets by viewtype/view, not md5(viewtype/view)
This opens up is the possibility that we'd be able to serve cached
files directly off disk instead of via PHP for performance.

This also makes it much easier to explore the available cached resources
by navigating to dataroot/views_simplecache and browsing around.

Fixes #8381

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 29, 2015

chore(views): Require assets to have valid extensions
BREAKING CHANGE:
We now cache assets by `"$viewtype/$view"`, not `md5("$viewtype|$view")`
which can result in conflicts between cacheable views that don't have
file extensions to disambiguate files from directories.

This requirement makes it possibile for us to eventually serve assets
directly from disk for performance, instead of serving them through PHP.

This also makes it much easier to explore the available cached resources
by navigating to dataroot/views_simplecache and browsing around.

Fixes #8381

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 29, 2015

chore(views): Require assets to have valid extensions
BREAKING CHANGE:
We now cache assets by `"$viewtype/$view"`, not `md5("$viewtype|$view")`
which can result in conflicts between cacheable views that don't have
file extensions to disambiguate files from directories.

This requirement makes it possibile for us to eventually serve assets
directly from disk for performance, instead of serving them through PHP.

This also makes it much easier to explore the available cached resources
by navigating to dataroot/views_simplecache and browsing around.

Fixes #8381

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 29, 2015

chore(views): Require assets to have valid extensions
BREAKING CHANGE:
We now cache assets by `"$viewtype/$view"`, not `md5("$viewtype|$view")`
which can result in conflicts between cacheable views that don't have
file extensions to disambiguate files from directories.

This requirement makes it possibile for us to eventually serve assets
directly from disk for performance, instead of serving them through PHP.

This also makes it much easier to explore the available cached resources
by navigating to dataroot/views_simplecache and browsing around.

Fixes #8381

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 29, 2015

feature(views): Allow serving assets directly from filesystem for per…
…formance

BREAKING CHANGES:
Assets must have valid file extensions

We now cache assets by `"$viewtype/$view"`, not `md5("$viewtype|$view")`
which can result in conflicts between cacheable views that don't have
file extensions to disambiguate files from directories.

This requirement makes it possibile for us to serve assets
directly from disk for performance, instead of serving them through PHP.
Just create a symlink from /cache/ to /dataroot/views_simplecache/
and if your web server supports following symlinks, you'll get this benefit.

This also makes it much easier to explore the available cached resources
by navigating to dataroot/views_simplecache and browsing around.

Fixes #8381

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 29, 2015

perf(views): Allow serving assets directly from filesystem
BREAKING CHANGES:
Assets must have valid file extensions

We now cache assets by `"$viewtype/$view"`, not `md5("$viewtype|$view")`
which can result in conflicts between cacheable views that don't have
file extensions to disambiguate files from directories.

This requirement makes it possibile for us to serve assets
directly from disk for performance, instead of serving them through PHP.
Just create a symlink from /cache/ to /dataroot/views_simplecache/
and if your web server supports following symlinks, you'll get this benefit.

This also makes it much easier to explore the available cached resources
by navigating to dataroot/views_simplecache and browsing around.

Fixes #8381

ewinslow added a commit to ewinslow/Elgg that referenced this issue Jun 30, 2015

perf(views): Allow serving assets directly from filesystem
BREAKING CHANGES:
Assets must have valid file extensions

We now cache assets by `"$viewtype/$view"`, not `md5("$viewtype|$view")`
which can result in conflicts between cacheable views that don't have
file extensions to disambiguate files from directories.

This requirement makes it possibile for us to serve assets
directly from disk for performance, instead of serving them through PHP.
Just create a symlink from /cache/ to /dataroot/views_simplecache/
and if your web server supports following symlinks, you'll get this benefit.

This also makes it much easier to explore the available cached resources
by navigating to dataroot/views_simplecache and browsing around.

Fixes #8381

ewinslow added a commit to mrclay/Elgg-leaf that referenced this issue Jun 30, 2015

perf(views): Allow serving assets directly from filesystem
BREAKING CHANGES:
Assets must have valid file extensions

We now cache assets by `"$viewtype/$view"`, not `md5("$viewtype|$view")`
which can result in conflicts between cacheable views that don't have
file extensions to disambiguate files from directories.

This requirement makes it possible for us to serve assets
directly from disk for performance, instead of serving them through PHP.
Just create a symlink from /cache/ to /dataroot/views_simplecache/
and if your web server supports following symlinks, you'll get this benefit.

This also makes it much easier to explore the available cached resources
by navigating to dataroot/views_simplecache and browsing around.

Fixes #8381

@ewinslow ewinslow closed this in #8538 Jun 30, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment