View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002741 | Composr | core | public | 2016-07-25 00:14 | 2018-05-02 13:56 |
| Reporter | Patrick Schmalstig | Assigned To | |||
| Severity | Feature-request | ||||
| Status | non-assigned | Resolution | open | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0002741: Option for blocks to be statically/predictably locked to a point in time instead of dynamic | ||||
| Description | I think a good feature for Composr CMS is to have an option when adding blocks to something to make the block static instead of dynamic. What this means: Instead of the block loading with the latest content every time it is viewed, the block generates the latest content one time and gets imported in the content (aka. it does not update to the latest content on each load... it is static). Usage scenarios where this could be useful: *Showcasing things in news posts or newsletters. For example, if I want to show the week's leaders in a news post, I don't want the block updating automatically each week; I want it to render the same leaders each time on that specific news article. It is inconsistent for it to auto-update to the current leaders on, say, a news article meant to showcase the leaders from 3 months ago. *Showcasing latest uploads in a gallery for that specific time period. Again, if the block automatically updates each time it loads, it becomes inconsistent if I want people to see the latest uploads for that specific time... when the news article was created. | ||||
| Tags | No tags attached. | ||||
| Time estimation (hours) | 16 | ||||
| Sponsorship open | |||||
|
|
This would be highly complex to do but could be considered if someone can sponsor it. We can't just copy rendered block data into another table, something similar to a block cache but permanent - because it would make data portability between sites and systems too complicated. As far as possible we want content to standalone rather than weaving across tables unexpectedly. What we'd need to do is we'd need to evaluate the block the first time the page is saved, then copy the Tempcode output of that block somehow back into the Comcode. It couldn't copy it as HTML, as it would lose potential dynamism (E.g. keep_* URLs). We currently have no way to turn run-time Tempcode back into template-style written Tempcode (in-fact, it's almost impossible - as at this point it's been compiled to PHP code) - but we could probably make a fudge where we shove it basically in a black box within the Comcode. This black box would also need to include references to CSS/JS/lang-file dependencies used by the Tempcode. Further complicating it is that all the styles of this (use of CSS, etc), would have been baked-in, so content would 'rot' as themeing happens. I worry this issue (which can't be resolved) would severely hamper the appeal. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-07-25 00:14 | Patrick Schmalstig | New Issue | |
| 2016-07-25 15:15 | Chris Graham | Time estimation (hours) | => 16 |
| 2016-07-25 15:19 | Chris Graham | Note Added: 0004180 | |
| 2016-07-25 15:21 | Chris Graham | Note Edited: 0004180 | View Revisions |
| 2018-05-02 13:56 | Chris Graham | Summary | Option for blocks to be static instead of dynamic => Option for blocks to be statically/predictably locked to a point in time instead of dynamic |
