artfulrobot

@BitPoet Are you doing this locally or are you preparing a PR for the project? If so you're brave! I bet someone out there is relying on the existing behaviour. e.g. for cache warming or some other purpose for which my imagination was too limited. There's specific code written to implement the existing behaviour, so that ought to be removed if you're going to throw an exception. Clearly someone, @ryan maybe, had something in mind, although I stand by my opinion that it's super confusing 😆

Thanks both. I think the confusion arises because age is used to mean 2 different things in the cache context. In code, it's $expires in both contexts. For save() and also for get() when a function is also provided $expires means when the data should expire. For get() when a function is NOT provided $expires means "get if the thing expires before this new $expires, oh but also if it never expires (because of that 2010 date that's used to mean never expire...)". The 2nd case is my beef! Typically, when wanting a cached value, you care to fetch it unless it's too old for you to rely on. I can see the use case that you cache something with a long expiry, but that one user might only want to use a value if it's not that old. But that's not what we have. We have sort of the opposite: get something if it's going to expire before the given date. I'd love it if someone could give a scenario in which this was useful. Perhaps the use-case is cache warming? Like you might want to get stuff that's going to expire soon, and update the cache now. We could then use get($name, $expiry) and then recalculate the value and save() with a new expiry? This is the only thing I can think of? The fact that $expiry means 2 completely different things in the same get() api call is a trip hazard that needs flagging in the docs. I spent ages wondering why caching wasn't working and eventually stepped through to look at the SQL to get here.

According to the docs at https://processwire.com/api/ref/wire-cache/get/ for $cache->get($key, $expiry), $expiry means: I thought that meant: at 9am store something with an hour's expiry (so 10am) using $cache->save($k, $v, 60*60); At 9:01am, ask for it, if the value is younger than 30 mins, using $cache->get($k, 30*60); But it doesn't. And it seems to me it can't do as it's documented to do because the date the thing was stored (and therefore how old it is) is not stored in the db table. In fact the SQL that's run is: SELECT * FROM caches WHERE name=$k AND expires <= 9:31am So even though our data is 1 minute old, it's not considered younger than 30 mins old and is not returned. The only way the cache could honour the docs would be if the date the thing was stored in the db was saved. Then we could do whenSaved < 9:31am (though I'd suggest we also specify that it hasn't expired too, to honour the save() contract). But we don't have that field. Just wanted to sanity check these findings with the community. And if I'm right, how do we go about suggesting clarifications for the docs? If I'm just a confused noob, please explain the designed use-case for the documented get/expiry behaviour.

If it's ok to dig up old threads.... @bernhard here, aren't you double encoding url, title? Assuming this is front end code, with `$pages->of(true)` and you have html entities text formatter in place on your title, url fields then a title with - say - an & would come out looking like &amp; as it would actually be &amp;amp;

Thanks again @bernhard ! I started my project without latte, then started to despise what templates looked like with raw php, and liked the look of Latte, so I added it as an aside; I have it as an api variable $latte and use it in some places but not everywhere. I'm aware there are two projects that offer to integrate Latte everywhere, but that looked a bit daunting! I'm currently edging in the opposite direction now! Using Latte's escaping instead of PW's. So now my code is like {do $page->of(false)} <!-- but see comment below --> {var $i = $page->image->first} <h2>{$page->title}</h2> {$page->someLongBodyHTML|noescape} <img url={$i->url} alt={$i->alt} /> ... Which means cleaner templates as I only need to use `|noescape` on HTML fields (so text formatters run). I prefer to do it outside because I like the principle that a template should not have side effects. If some thing that relied on OF being either true or false but called my template to render it, and in doing so the OF got swapped, that could lead to trouble. So I prefer to pass in an object with OF correct; e.g. in my n:foreach loop I know I've got my own page that I can change OF on. The {do ...} syntax is good though, hadn't spotted that.

I like the idea but this means every reference to the field needs to be done this way, which is quite a lot to (a) change and (b) remember for future templates. At least with (1) I can do it once per page object. Also (1) fixes potential problems with other fields as well. I don't think it's relevant, but I'm using Latte, too. So my loop is like this: <li n:foreach="$downloads as $downloadPage"> {var $dummy = $downloadPage->of(true)} <!-- This is the bit I wanted to avoid --> {include 'download-list--teaser.latte', page: $downloadPage} </li> Then in `download-list--teaser.latte` (wish this editor supported semantic inline code samples!) I can just use `$page->image` like normal: {if $page->image && $page->image->width * $page->image->height < 24000000} {var $thumb=$page->image->size(400, 220) } {/if} <a target=_blank href="{$page->url}" > <article > <div class="meta body-text"> <h1>{$page->title|noescape}</h1> {$page->text|noescape} </div> {ifset $thumb} <div class='image'><img src="{$thumb->url}" alt="{$thumb->alt}" /></div> {else} <div class='image bg-stripey'></div> {/ifset} </article> </a> (I may not have all those escaping rules right yet.)

Thanks @bernhard for your reply. Front/back end: it's complex! In this situation, the front end template is being called in a back end context, by PageTableNext (PTN), to render a slice of a page in the shadow DOM. For this reason, I don't want to interfere with the global OF setting as that could risk messing up the operation of the admin forms. As I said, I'm experiencing OF=true for the value being rendered, but OF=false for $page->somePageRefField so I think what's happening is that the global setting will be false, but PTN is presumably setting OF=true on the page it renders, but this does not propagate down. (string) doesn't help me - I think - because the field I'm having trouble with is an image field. But it's useful to know that PW will output-format on toString(). The image field is configured to return a single image (when OF=true) as it will only ever hold one image. However if the template receives the owner of the field with OF=false, then image fields always return an PageImages object, which breaks the template. I think my options are: As I'm doing now: inside the render loop, do $old=$item->of(false); then do $item->of($old); at the end of my code. This means I definitely know that I'm dealing with an output formatted object. In my code set $pages->of(true). And reset that at the end. I feel uncomfortable about this somehow. I suppose I don't know what else it might affect, though it would be nice to do this outside of the field loop. Alternatively, for this specific case, I could reconfigure my image field to always return a PageImages. This impacts quite a few templates though. I think I'll stick with the solution (1) and accept it as a quirk of PTN.

I have a template with a Page Reference field on it called resources. In my template file, I'm noting this: $page->of(); // **true** foreach($page->resources as $resourcePage) { $resourcePage->of(); // **false** } i.e. the output formatting is not passed down from the main $page. This surprised me, as it means - I think - that something like <?php echo $page->resources[0]->title; ?> would be unescaped data. Is this the designed behaviour? Also, is there any way of setting the output formatting on the collection? e.g. so I could call $page->resources->of(true); // ← This bit is made up/pseudocode I'm asking about foreach ($page->resources as $resource) { echo $resource->title; }

nothing shows up? or do you see <div id="content"></div> As in: it's just $x->body that's not outputting anything? It looks right to me; my code that uses repeater is similar. So to debug I would: check that you see the <div> - it's obvious, but I for one often hammer the keyboard for ages and then realise I've edited the wrong file or such...! use Tracy console on the page to inspect $page->sections and $page->sections[0] and $page->sections[0]->body. Is there data in there? not sure what my next step would be if there was data in there but it wasn't output as you have done. Check the text format filters? Sorry, probably not much help, but thought I'd chip in. (I'm relatively new here.)

Sounds good. Ive found myself implementing a cache in front of $cache that stores stuff in ram (with db persistence too) for data you may need a few times in one request. I realized there was no way to replace $cache with my own extended class, so I just do this in another module. I could probably use a hook as alternative.

I've decided that for my use-case, a better solution is to have a 'resources' page and template, and a 'resource' template which has a singular file field and use one page per file. Then to use page reference fields to include that in actual visitable pages. This enables me to include an image field for my files, as well, of course as all the other fields I need for files.

I'm experimenting with this stuff practically now. I've since learnt that file fields can themselves use fields ("custom fields"), which is sort of what I suggested at the top of this post, but with the template hidden, and with a UI that embeds/nests the UI for these file pages. Tentatively it could work for a file to belong to a page (I have a reservation around whether the file would ever be needed when the page wasn't, but decided to push that complexity to the future!) so I thought maybe this was the way to go. I set up some fields for my 'files' field: title, description (text fields) both work fine, but when I put an image field on there it doesn't show in the UI? I wanted to include a thumbnail of each file. Is this a known limitation?

This We refers to you and your company, not the PW project? e.g. there's no .editorconfig in https://github.com/processwire/processwire ? Good tip though, it's exactly what editorconfig is for.

I had been going on a quick search result which is probably not accurate; but it said that umami did not handle events or reports (emails). I see from umami.is that it does do events, though the 4 digit precision for numerical event data is pretty strange (unless they meant 4 decimal places). Sadly neither of them accept amount/e-commerce type data - which would be summed, not counted in charts (plausible issue) Statistics can grow and the more indexed they are the more they grow. It would be interesting to run both on the same site for a comparison!

Looks great @bernhard! I use plausible at the mo, but have just discovered umami's existence. It looks like it lacks features compared to plausible, and I'd hate to run a node server (paranoid of dependency/security hell). I'm considering running plausible myself (you can self host it too) as a trial. FWIW I proxy my plausible js/ajax requests through my server, to prevent being snared by blockers.