Require all simplecacheable views to have a filename extension #8381

ewinslow · 2015-05-28T18:12:26Z

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?

The text was updated successfully, but these errors were encountered:

ewinslow · 2015-05-28T18:13:39Z

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

ewinslow · 2015-05-28T18:14:16Z

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

mrclay · 2015-05-28T20:19:12Z

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 · 2015-05-28T20:19:21Z

Wrong button.

mrclay · 2015-05-28T20:20:51Z

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

mrclay · 2015-05-28T20:23:46Z

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 · 2015-05-28T21:28:07Z

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 · 2015-05-28T23:57:31Z

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 · 2015-06-05T02:50:03Z

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

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 Elgg#8381 Fixes Elgg#8382

Fixes Elgg#8381

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 Elgg#8381 Fixes Elgg#8382

Fixes Elgg#8381

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 Elgg#8381 Fixes Elgg#8382

Fixes Elgg#8381

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 Elgg#8381 Fixes Elgg#8382

Fixes Elgg#8381

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 Elgg#8381 Fixes Elgg#8382

Fixes Elgg#8381

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 Elgg#8381 Fixes Elgg#8382

Fixes Elgg#8381

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 Elgg#8381

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 Elgg#8381 Fixes Elgg#8382

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 Elgg#8381 Fixes Elgg#8382

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 Elgg#8381

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 Elgg#8381

…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 Elgg#8381

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 Elgg#8381

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 Elgg#8381

ewinslow added performance bc break labels May 28, 2015

mrclay closed this as completed May 28, 2015

mrclay reopened this May 28, 2015

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

chore(views): Cache assets by viewtype/view, not md5(viewtype/view)

97dcdb6

Fixes Elgg#8381

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

chore(views): Cache assets by viewtype/view, not md5(viewtype/view)

66841af

Fixes Elgg#8381

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

chore(views): Cache assets by viewtype/view, not md5(viewtype/view)

63cdbab

Fixes Elgg#8381

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

chore(views): Cache assets by viewtype/view, not md5(viewtype/view)

cb4902c

Fixes Elgg#8381

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

chore(views): Cache assets by viewtype/view, not md5(viewtype/view)

e7ee012

Fixes Elgg#8381

ewinslow mentioned this issue Jun 19, 2015

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

Merged

6 tasks

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)

5b81d7c

Fixes Elgg#8381

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)

28c0273

Fixes Elgg#8381

ewinslow mentioned this issue Jun 20, 2015

perf(views): Allow serving assets directly from filesystem #8538

Merged

6 tasks

ewinslow closed this as completed in #8538 Jun 30, 2015

ewinslow mentioned this issue Jun 30, 2015

perf(simplecache): Allow 304 responses even with simplecache off #8636

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Require all simplecacheable views to have a filename extension #8381

Require all simplecacheable views to have a filename extension #8381

ewinslow commented May 28, 2015

ewinslow commented May 28, 2015

ewinslow commented May 28, 2015

mrclay commented May 28, 2015

mrclay commented May 28, 2015

mrclay commented May 28, 2015

mrclay commented May 28, 2015

ewinslow commented May 28, 2015

mrclay commented May 28, 2015

ewinslow commented Jun 5, 2015

Require all simplecacheable views to have a filename extension #8381

Require all simplecacheable views to have a filename extension #8381

Comments

ewinslow commented May 28, 2015

ewinslow commented May 28, 2015

ewinslow commented May 28, 2015

mrclay commented May 28, 2015

mrclay commented May 28, 2015

mrclay commented May 28, 2015

mrclay commented May 28, 2015

ewinslow commented May 28, 2015

mrclay commented May 28, 2015

ewinslow commented Jun 5, 2015