MarkE

I seem to have a few pages which show they have been modified recently by 'guest'. However, they appear to be unchanged and the related templates have set guest access to view only. I thought it might be something to do with page hit counters, but that seems not to be the cause. Some of the pages are only archives and are not directly accessible from the website (i.e. can't be retrieved by following links from the home page), so it seems a bit like a bot, but surely it should not mark the pages as modified? Any ideas?

PasteUrl from @Robin S?

Did you try snippets in Windows? No need to save, it is automatically put in the screenshots folder which you keep open, so just snapshot it, edit as required and drag. When done, delete all the contents of your folder. Ok so that’s one more step than ideal, but at no development effort!

Not exactly sure what you want @bernhard, but if you are on a Windows machine, just use the snipping tool, select 'open screenshots folder' from the dropdown and drag to the field.

Thanks @bernhard I use RockFrontend and am fairly happy with that approach, although I would prefer to say which template to add, for example, favicon to (e.g. my settings template). Re the new logo field. Would that be accessible elsewhere in the API? I sometimes use the logo in other places than just the admin masthead.

I mean adding a field to a pre-existing template. My preferred approach is that modules may add templates and fields, but not automatically modify existing ones - that should be left to the webmaster or superuser, whether directly via setup or via module settings. Also, any new templates and fields should have names that are unlikely to conflict, e.g. by using an appropriate prefix.

Interesting thought. I'm not too keen personally on modules modifying the database in this way. Another approach would be to have a page ref field and a field with the name of the image field. That said, the solutions suggested above work well anyway. Having tried both of them I am marginally inclined towards @BitPoet's solution as the entry in the module settings is clear and it seems a bit more 'Processwiry'.

That's a really neat trick - useful in a bunch of other contexts too! So 2 great solutions from @BitPoet and @Markus Thomas - spoilt for choice (and I will get back to @bernhard with ideas too). ?

That's great @Markus Thomas. The only slight disadvantage is that it may not be obvious to the website manager that setting the logo in the Uikit admin settings has no effect. So what I did was entered 'not_used_Overriden_in_admin.php' in the logo image file field.

I did think of that, but with multiple installations I am not confident that the id of the settings page will be identical. Maybe I’m just being overly cautious.

The standard admin themes (UI, Rock etc) permit you to modify the logo by giving a path to it. I would like to be able to specify the logo as being an image field on a settings page? I know I could do this with a fairly ugly hack using regex in a hook on Page::render, but I wonder if there is a better way?

Hi @dotnetic. Hopefully @flydevpointed you in the right direction. What I was referring to was @ryan’s snippet to prevent multiple booting of the instance.

Does this help?

I have tried multi site and there are pros and cons, chiefly: Pros - only one core codebase to maintain ( & smaller footprint, but at less than 30mb, that's not such an issue) Con - All your sites need to run on the same PW (and PHP) version. Sometimes, you may be ready to upgrade one site, but not another. On balance, I now tend to go for a different PW install for each site.

I use that - a really nice module

Thanks @szabesz. I'll stick with 8.0 for the production environment for now.

Hi @Roope, can we have a module update with the fix? Ta.

I am still getting a deprecation warning with that combo. I think it is caused by the cookie module MarkupCookieConsent passing an explicitly null param, but it should be caught by the cookie() method in WireInput. Easily fixed by changing line 371 to if($key === null || !strlen($key)) return $this->cookieVars; Worth a PR?

A couple of simple things: Good support for xdebug So easy to switch php versions

Process modules as per @bernhard’s post are the main tool. If you don’t feel confident with that (and do have a try, it’s not that hard) then I suggest you avoid a custom solution. I really like HTMX for that. There are quite a few forum posts about it.

I’ve done several quite complex apps like that. Not quite the same as your requirements, though. Lots of complex calculations and relationships. A clear spec and entity model are absolute musts. But as @dotneticsays If it’s just for the client then the admin is fine. However a key issue is whether there are likely to be concurrent users. If there are only a very small number of users then you can use ProDevTools to handle edit collisions. Otherwise it’s a whole lot more complex and you may be better buying an accounting package.

@adrianI think the answer was given later - hooks need to be bypassed if null page Also I did: if(isset($p) and $p and $p->id and method_exists($p, 'ready')) $p->ready(); I can't recall now what actually fixed it!

I've not been following this very closely, but this statement caught my eye and caused me to worry. Are you saying that (for example) the selector string option for $cache->save (as per https://processwire.com/api/ref/wire-cache/save/) will no longer be supported? That would be a big problem for me as one of my web apps uses it extensively. The app provides a spreadsheet-like user interface but only updates data if precedent data has been changed (otherwise every 'cell' gets recalculated on every page view which would be a huge delay). Maybe I misunderstand, but I would be grateful for clarification.

Why don't you just set the field to default to 'today' (in the input tab)?

I’ve found that the most irritating situation is when the editor leaves a page open, then comes back to it some time later and makes a big edit only to find it won’t save because they’ve been signed out. The UserActivity module fixes this nicely, but it would be better if it was fixed in the core. Just a simple message to say you’ve been signed out would help.