artfulrobot

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.

Erm, bit late, but found it here: https://github.com/ryancramerdesign/SkyscrapersProfile

Erm, bit late, but found it here: https://github.com/ryancramerdesign/SkyscrapersProfile

@WillyC yes, the use case was an import - a big migration from another CMS; I wanted to maintain a known list of tags in memory for efficiency, rather than sending an airplane to fetch all tags again and again - you know, for the climate's sake ? But anyway, it's fine. I suppose I could have maintained my own vanilla array index instead of a PageArray but I thought I was being cool using the new tools, until I found out it's a tractor. Anyway, tis done now. @flydev thanks, but that requires me to know that there aren't two distinct items: "system change" and "change system". At first I posted because I thought there might be something I was missing (like WireArray::setCaseInsensitiveMatching() or such). But then as I dug into it I found that the limitations are hard coded. None of the help/docs pages I read have any warning of this; there's many examples of chaining from a db query ($pages->find()) into some other filter without warning. I think there should be warnings in the docs about the different implementations, when suggesting filtering on a WireArray, as opposed to a $pages query. I think there should be an equals operator that is explicitly case insensitive. (though perhaps we've exhausted every combination of symbol already...!) I think the codebase should be updated to be UTF-8 compatible so that É matches é, for example on the case-insensitive matchers. But I'm too much of a noob to do PRs yet (and I have to train my editor to use tabs not spaces ?) Anyhoo, thanks for the suggestions, all.

Just linking back to https://processwire.com/modules/publish-date/ which is a module that "is an extended version of what the ProcessWire community came up with in this thread" Although, also noting that it seems PW core now creates a published field on the pages table which holds the datetime that the page was published, or `null`; so that module no longer seems to be needed.

The rabbit hole gets weirder: it seems the SelectorEnds `a$=b` is case-insensitive - at least to simple western languages (it uses `strcasecmp` which does not handle UTF-8 multibyte characters). But that's the only one of all the selectors to use it. Though others do use `preg_match` with the `i` flag (though not the `u` flag for unicode, so probably same as strcasecmp)... and others use stripos. At this point in my digging, I thought: I'll consult the unit tests, then realised there aren't any - I've made a suggestion that tests would be a good thing (EDIT: and I see others have gone further and implemented some frameworks)

I've just discovered something that appeared strange: selectors work transparently, but are actually context sensitive, yielding different results. // Check for a 'hello' tag: $selector = 'template=tag, title=hello'; $existingPages = $pages->find($selector); d($existingPages->count, "✔ No pages, as expected"); // Create the hello tag (noting capital letter): $aTagPage = $pages->newPage(['template' => 'tag', 'title' => 'Hello']); $aTagPage->save(); // Add the newly created page to the empty $existingPages PageArray $existingPages->add($aTagPage); // Repeat the search for the hello tag: $pageArray1 = $pages->find($selector); d($pageArray1->count, '✔ Works ok'); // The following methods fail. d($pageArray1->get($selector), 'Tag hello not found, despite same selector'); d($existingPages->get($selector), 'Tag hello also not found this way.'); d($pages->find('template=tag')->get('title=hello'), 'Not found like this, either'); Output: I believe what's happening here is that when the data is loaded, the selector uses a PHP implementation, and when the data is not loaded, it uses an SQL implementation. And the results likely differ (depending on your exact set-up of database tables and collations). I can see that one solution might be to set collation of all text fields to binary/case sensitive, and just do without being able to search case insensitively; but this would create a lot of problems, since search, especially user-entered search, typically needs to be case insensitive to meet user expectations. So the solution I'm going with for now is to try to programmatically avoid using find() etc. methods on a PageArray. This is quite inefficient. I'd love to know if there is another solution? I read through the Select operators documentation but couldn't find mention of case sensitivity.

I'm pretty sure @Kai no longer needs an answer to this problem, but I'm documenting here that I hit it, too. The clue is in the error message: You (and I) were trying to set description on the Pageimages (note plural) object, which is invalid; you can only set it on a singular Pageimage object. For me, the confusion came because I have my field configured for max 1 image, and 'Automatic' on the formatted value, meaning I should expect a singular Pageimage object or Null. However, as the help text says on the field config page "When output formatting is off, the value is always a Pageimages array." So my bad (import) code was: $pwPage->image = $localPath; $pwPage->image->description = 'My ALT Text'; $pwPage->save(); And the fixed code is: $pwPage->image = $localPath; $pwPage->image->first()->description = 'My ALT Text'; $pwPage->save(); Hope this helps another searcher (probably me, next time I do it!)

Thanks @ryan I'm glad to hear that you hit this problem too. The client in mind uses comments as ... well ... just blog comments! ... and their need of asking for an Organisation field does not seem to take that use-case away from it primarily being comments. I'm glad also that you implemented a solution 10 months ago, too! So you implement a custom comment form class, and use `getMeta()` in the template output, as you describe in your July 2022 update (and when it comes to me implementing this, I'll figure out where to hook to call `setMeta()`) [EDIT: Ah, looks like I'd just override processInput()] That sounds like the way to go. Thanks for your time and support.

Thanks for the responses so far, everyone, really appreciated! "page" - fine / thanks for the analogies and sympathy! I think if anything my questions are around why are comments not pages? They seem an ideal candidate and the comments field seems to reinvent an already good wheel. Docs: Thanks for the links, always useful in a forum post to have links to something evergreen, but I have already read them all. @WillyC thanks for the tip re the comment manager, that moves comments out of the page edit form, I'll check that out. My main reservation about comments as a field is that fields are not field-able, right? Say I need to ask for an Organisation from commenters. It looks like I would need to: Create a custom CommentForm Replace the Comment class since this hard-codes a preset list of possible fields. Replace the ProcessCommentsManager class since this also hard-codes the fields. Create a new table to hold the comment, and by various hooks, intercept the save/load to use that table. Or ALTER the core-provided table by adding a column. This then creates a lot of maintenance work since I'd be replacing the core Comment class, and the custom CommentForm whose markup/logic tweaks would need to merge in future core markup and logic tweaks - just to add a field. And if in future someone adds organisation to the core comment and I'm unlucky enough that they use the same column name, then it will be a right faff. Had a comment been a Page, I would simply add an Organisation field to that Template - the design of the classes could mean that no hacks would be required at all. I can see that comments have a lot of functionality attached - looks like a lot has been bolted on over the years - so maybe this design decision was the only sensible option in 2011 and now it's set in stone. But coming anew to this, comments overlap a lot with pages; there's lots of features implemented in the comment field type that would be brilliant if abstracted (e.g. notification, voting, spam submission, etc.) and extensible, rather than tightly bound to the Comment class. Please understand I'm not here to criticise with any ill-intent, I'm just probing and questioning to find out if there's anything I've missed/mis-understood. All long running projects inherit some decisions that could do with a refactor at some point, which is normal and very understandable. I'm a noob to ProcessWire but I have dozens of years' experience implementing, extending, coding other CMSes, which is why I'm particularly interested to understand the architecture decisions, and limits to extensibility early on in a project. To focus the thread: am I right above about what would be required to add a field to a comment? Thanks for your interest.

I'm implementing my first site in ProcessWire and I will be migrating some content from a Drupal 7 site. I've just come to considering the blog + comments. I've read @ryan's tutorial post (from 2011!) and I've experimented with the ProcessBlog module, but I'm not convinced. Here's what I don't like It creates a lot of special pages which then become intermingled with what I might call "content pages", e.g. actual blog posts. This makes the Pages menu quite problematic - on an empty install there must have been around 10 items, and if I'm importing a blog with hundreds of posts that menu is just going to be unhelpful as it's clearly not a sensible way to navigate huge content lists. It uses PageReference for a simple options field. So we have "pages" for things like "Always show comments". I realise that in ProcessWire "everything is a page", and in my head I try to say "it's ok, they just mean entity or object or thing, don't think of it as page. Then why use a word that has such strong meaning in the context of a CMS? Oh just accept it. Hmph. Alright." but it seems that this is going to be very confusing for my clients who will use the site I build for them. Perhaps the Select Options field was not available when the ProcessBlog module was created. Needing to edit a page to get to moderate the comments is not natural to me, and it seems that the edit page form brings in an edit form for every single comment. We have hundreds of comments - this is going to be thousands of DOM nodes, and lots of data being loaded every time. Just doesn't seem sensible, as Ryan said in his 2011 post! Comments as a field definitely has a logic, but also seems to bring problems (above) and also makes comments not easily searchable because they - unlike everything else - are not a page. So I'm thinking I might step out in the following direction instead: So, in words: We'd have templates: comments-template and comment-template, with suitable "Family" settings. And blog-listing-template whose children will all be pages using the blog-post-template. The comment-template: uses a PageReference field to point to which page the comment belongs to. can hold any fields we need for comments - the message, the poster's display name and email, optional user ID, date posted, and potentially other user-entered fields. can use normal page hierarchy for comment hierarchy (i.e. replies to comments). could have moderation field(s), although I might be happy with just published/not published for my use-case. I'm not sure about the /admin/ part of the hierarchy but I really just want to indicate that those parts are not publicly accessible. This to me means: Can load comments as pages, so can easily fish out unmoderated comments and link to their posts in-situ. Can continue to edit a blog post without needing to load all the comments. I'd be grateful to anyone who had time to sense-check this idea, or tell me why it's better to do it another way. Thanks ?

There's these URL/path hooks from ProcessWire 3.0.173 : https://processwire.com/blog/posts/pw-3.0.173/ which seem very promising for the sorts of problems encountered in this discussion.

The automated email tells me: But I can't find that button.

@Zeka ah, thanks. The link above takes you to a long and old forum thread that began in 2012. For anyone finding my duplicate question here, I think the TL;DR of that thread might be: You can get rid of the title field (advanced » uncheck "Global" for the field), but you will get looks like ?, may encounter weird issues including problems with page names which are not optional. So getting rid of the title field is not generally the way to go. You can rename the title field in the context of its use on a particular template. So just name it something that every one of those pages would need. No good if those don't have such a field, and anyway bit weird in templates where you're accessing `title` but meaning `last name` or whatever, and also, title had probably best be unique. Since 2013, you can use a new feature to automatically generate the title, when you have a template that only allows one type of template below it. See Ryan's initial explanation. You can also auto-generate a title using hooks though a lot of testing is needed.

Requiring a title for each 'content-element' on a page gets quite cumbersome. I don't need the "PageTitle" field on a 'page' that is just an element *of* a page. Just wondering if there's workarounds to disable this?

The forum software is nagging me to "Help others by going to the topic and use the 'Mark as Solution’ button on the post with the best answer" but I don't see any of those buttons!

Re leaking: I believe nginx uses the request url as the cache key and that only GET requests are cached (not sure about OPTIONS or HEAD). So if you have caching enabled and a logged in user, Wilma, requests /processwire/user to see their profile, the next user, logged in or not, will also see Wilma's record. Typically it's ok to disable caching for logged in users, and/or you can also disable caching on certain urls (or patterns of url) that you know to be sensitive. Don't know if this is helpful or not, but here's the sort of thing I use for Drupal. map $http_cookie $session_cookie_set { default 0; ~SESS 1; # PHP session cookie } ## Identify ajax requests so we can choose to not cache them map $uri $is_drupal_ajax_request { default 0; /system/ajax 1; } # ... then in your server block ... fastcgi_cache_bypass $session_cookie_set $arg_nocache $is_drupal_ajax_request; fastcgi_no_cache $session_cookie_set $arg_nocache $is_drupal_ajax_request; What this does is: set up a variable `$session_cookie_set` which will be 1 if there is a PHP Session cookie in the request Set up a variable `$is_drupal_ajax_request` if the path is `/system/ajax` (a special path for drupal, but you can add your own var name and url patterns in here for your own use/processwire uses). Tells nginx to bypass and not cache results if any of these, or the `nocache` URL query variable is set. I'm keen to use pw with nginx because .htaccess is ineffficient (from what I've read) and because I get on better with the reasoning of nginx's config; it seems to have fewer quirks than apache!