iank

Hi @adrian, Thanks - I shouldn't have been so hasty - it was just in one PW install, where I'd (several years ago) set the $config->externalPageID to 0 to try to work around this situation when logging 404s: https://github.com/processwire/processwire-issues/issues/259 In other installs everything is fine; and I don't even think that config setting is actually solving anything for me anyway; But thanks as always for such a quick response! Regards, Ian.

Hey @adrian, I came across a minor problem which prevents the Tracy console showing in the debug bar when bootstrapping PW in a standalone PHP script. The error shown is: ErrorException: foreach() argument must be of type array|object, null given in D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\panels\ConsolePanel.php:172 Stack trace: #0 D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\panels\ConsolePanel.php(172): Tracy\Bar->Tracy\{closure}(2, 'foreach() argum...', 'D:\\laragon\\www\\...', 172) #1 D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\tracy-2.10.x\src\Tracy\Bar\Bar.php(143): ConsolePanel->getPanel() #2 D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\tracy-2.10.x\src\Tracy\Bar\Bar.php(115): Tracy\Bar->renderPanels('') #3 D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\tracy-2.10.x\src\Tracy\Bar\Bar.php(89): Tracy\Bar->renderPartial('main') #4 D:\laragon\www\[sitename]\site\modules\TracyDebugger\tracy-2.10.x\src\Tracy\Debugger\DevelopmentStrategy.php(123): Tracy\Bar->render(Object(Tracy\DeferredContent)) #5 D:\laragon\www\[sitename]\site\assets\cache\FileCompiler\site\modules\TracyDebugger\tracy-2.10.x\src\Tracy\Debugger\Debugger.php(314): Tracy\DevelopmentStrategy->renderBar() #6 [internal function]: Tracy\Debugger::shutdownHandler() #7 {main} And this is what the debug bar looks like: I think it should be a simple fix - it looks like the line 172 is traversing $p->fields, but $p is a NullPage at this point. Kind regards, Ian.

I've recently started moving some of my PW sites over to 20i.com after becoming disenchanted with my current host. I've found their systems to be performant and reliable and their support to be really helpful and responsive (although they've recently adopted an AI bot intermediary for support questions - which to be fair is quite good, and if it doesn't answer your question you can get straight through to tech support via a ticket). Support tickets are usually answered within a few minutes. They have a custom Control Panel rather similar to cPanel, which is fine; I've not encountered any problems with it. They provide a CDN by default and the handful of PW sites I've moved over are running perfectly happily. Their migration mechanism is a cinch (I'm migrating from cPanel). I've a couple of small cloud servers with them and I'm trying out the reseller offering at the moment. The only downside is that to use their free SSL certs you need to have your domain either hosted with them or if hosted elsewhere, to use their nameservers. For some of my clients that's a non-starter, so I may look at Krystal as well. HTH.

Hi @adrian, No, I don't have Ghostscript installed; and I'm not sure about the fonts path thing - I'm no server expert.. I agree - I don't think it's worth you spending any more time on this unless other people report similar issues. I have a good workaround thanks to your input, so that's very much appreciated. Maybe I should rename the title of this post, given that we eliminated the logs panel as the source of the issue?

Hi @adrian, It appears to be mainly queryformats() that's the culprit - this is taking 40-odd seconds when first run after a few minutes idle time ; though if I run getVersion() first (similarly after some idle time) the latter can take 20s or so. Most of the sites are running PHP 8.1.32 and the Imagick version details are as follows: Thanks, Ian.

Hi @adrian, I've now narrowed it down to a couple of elements in the panel code. The main one is the Imagick code, which seems to be the one that creates the 45s delay if you don't visit a page for 5 minutes or so. https://github.com/adrianbj/TracyDebugger/blob/5e5d483a7f4d30c4e3f52c40921897a4603b6151/panels/ProcesswireInfoPanel.php#L264-L278 There's also some slowdown on the Apache modules section, though this varies and I can't quite put my finger on it, but sometimes takes a few seconds: https://github.com/adrianbj/TracyDebugger/blob/5e5d483a7f4d30c4e3f52c40921897a4603b6151/panels/ProcesswireInfoPanel.php#L230-L250 I commented both those sections out and re-enabled the ProcessWire Info panel and all its subsections (and the Logs panel) and pages are now loading reliably in less than 200ms. 👍 I don't know if there's anything you can (or should) do about this, given the highly specific nature of this environment, but at least I now have a workaround and can troubleshoot again without going for a cup of tea while the page loads! I'm happy to continue with further checks for you if necessary. Many thanks, Ian.

Happy to, Adrian, though it will be tomorrow now. It's nearly midnight now here in Blighty! 😴

Hi @adrian, Many thanks. I think your suspicions are correct. It looks like the Versions info that's causing the problem. I presume there's some caching going on here too? If I refresh the page within a few seconds, it loads fairly quickly, but if I leave it for a few minutes, I get the long delay and large ms count on the next page view. This is with everything disabled in Processwire Info except Versions Info. I wonder if it's something to do with the mySQL server version query? There have been a couple of mySQL updates in recent weeks/months and it certainly didn't used to behave like this. Cheers, Ian.

OK, so here's a turn up for the books - it's not the Processwire logs panel that's the issue - it's the Processwire Info panel! I noticed that the ms/kb count on one page refresh seemed to be next to the Processwire Info, so I turned that off and bingo! Everything loads consistently in milliseconds! Even with the logs panel turned back on, the pages are loading really quickly. I think it's somehow a misplacement of the counts and they're ending up next to the wrong checkbox. I've been through some of my other sites on that server, all exhibiting the same issue; turned off Processwire Info and - consistent millisecond loading across all those sites. And here's a screenshot of one of them that might show the misplacement better (before I toggled the Info panel off): I think it's the ProcessWire Info here that's taking 17 seconds. So - I don't know why that should be, but at least that's something to work with 🙂 Regards, Ian.

What's also interesting is that the Tracy Bar shows just a few hundred ms loading time, even though the page took 45s to load:

Hey @adrian, Thanks for the quick response! In answer to your questions: Yes, that's what confused me as well - I thought unchecking the box and choosing 'sticky' would completely disable it, but after a minute or two (presumably after one or more of the files gets updated) the page slows down again and the ms/kb notification reappears, even though the box is still unchecked. This is reproducible. Some of my sites are quite busy so the logfiles are getting modified frequently. Yes, I copied the logfiles down to the dev so they'd be exactly the same in number and in size. The largest is 1.6Mb. There are quite a few logs (78 to be exact - though many of those are empty - I have a Cron job that prunes them to 30 days each night). Total size of all files is 6.1Mb. However, I deleted all the log files a short while ago to see what effect that would have - now there are only 11 that have been recreated since I did that - totalling 9.7kb. I've just gone back into the admin and the page took over 45 seconds to load, showing the counts even though that checkbox is 'sticky unchecked'!: No, in fact I'd reduced this to 10 lines to see if that would help. Ah, yes - that would probably explain why things seem quick again for a minute or two and then slow down. Thanks for all your help! Ian.

.. Though I don't believe this is the issue - with Tracy disabled, loading the PW Setup=>Logs overview page is pretty much instant...

Hi @adrian, I'm unsure what's going on here but for a while now on a specific host (it's a cPanel server) I've been experiencing severe slowdowns when Tracy is enabled and it seems to be related to the reading of the Processwire logs Info. It's a bit like the old problem from 2022 when reasonable numbers of logs / large log files were slowing the page loading down when the debug bar was enabled. The odd thing is, I don't have the same problem on my local dev environment, or indeed on a different host, so I'm not sure where to look to troubleshoot. The environment in question is: PW 3.0.200-3.0.229 (various sites with different PW versions) PHP 8.1.32 MySQL Server: 10.6.22-MariaDB Sometimes, depending on the site and the number of log files, it can take up to 45 seconds to load, even though I've disabled the Processwire Logs panel: Whereas the same site (with the same log files) on my dev environment (and similar sites hosted elsewhere) are fine, even with the PW logs panel enabled: So I'm thinking it's some setting on the server - perhaps something like Imunify360 - could this be scanning the log files every time they're loaded and that's what's slowing it down? If I disable Tracy entirely, the same pages load happily in milliseconds, so it's some combination of Tracy and this specific server environment. I tried to disable the Processwire logs (as per the first screenshot above) but that only seems to work for a minute or so, and then the long loading time reappears. Hoping you can point me in some direction to narrow this down.. 🙏 Thanks, Ian.

Hi @bernhard, Thanks for the reminder. I'd forgotten about this, but you prompted me to take another look. Since my original post I've added RPB to a couple of other sites, and the trash icon shows up just fine for non-superusers. So it made me think this was a problem just with that one specific site. The site in question has a lot of templates and a much more granular set of permissions for the non-superuser (editor) role. I had the "page-delete" permission checked for that role, and then had certain templates where this was revoked, one of which was the home template: And when I unchecked that checkbox for the editor role, suddenly the trash icon appeared on all the RPB blocks. I guess I don't need that revoke, since I don't think you can delete the home page regardless. Anyway, that seemed to be the problem, and it's now working, so I'm happy ?. Wondering if this behaviour is because the RPB blocks are children of the home page, and whether that has a bearing on the issue. Regards, Ian.

That's great, thanks @Robin S! Works perfectly. A bit stupid of me - looking back at my old code I did use hasField, but evidently changed it during some other troubleshooting and didn't realise/forgot to change it back ?. As usual, the problem was entirely mine, and when in doubt, read the instructions!!

Hi, I'm not sure if anyone can help with this, and it may just be a limitation of the repeater nesting situation I've found myself in, but here's the background: I have a site built some time ago (and I'm sure this used to work, but I've since upgraded Processwire). It has a structure that guides the visitor through a series of questions to an ultimate end point, and is structured something like this: Plants (page, template = ndf) Step 1 (page, template = step) Question 1.1 (page, template = substep) Answer (field, repeater matrix) [used because the answer isn't always Yes/No, but there are alternative answer types] Yes/No Answer (field, repeater) Yes (repeater item) Next step (page reference field (ref_step), referencing multiple substeps) [should only show substeps inside parent Plants] No (repeater item) Next step (ref_step = page reference field (ref_step), referencing multiple substeps) [should only show substeps inside parent Plants] Step 2 Step 3 etc.. Timber (page,template =ndf) Step 1 Step 2 Step 3 etc When a substep page is displayed, it allows the visitor to choose Yes or No, and they will then be redirected to the next step (another substep page). These are different substeps for Yes and No. The answers Yes and No are (standard) repeater items, with various bits of content (summary text etc), but have a Page reference field that should allow the selection of the next step, (which is another substep) in the admin. This all works, but the choice of substeps should be limited to those inside their ultimate (grand)parent (ndf template page - just those inside Plants, or inside Timber respectively). Hence I have an 'After' hook on Inputfield::getSelectablePages where I identify the parent ndf page (Plants or Timber) and select the corresponding substep pages and allocate these to $event->return. The selection of the correct pages is working (I can see this from a Tracy dump), but this is never returned to the field instance, and instead it just uses the default settings for the field, which is based on template=substep and is returning all substep pages for all (grand)parents. Code for the hook (in ready.php): $wire->addHookAfter('InputfieldPage::getSelectablePages', function (HookEvent $event) { $page = $event->arguments('page'); $fieldName = $event->object->name; if ($fieldName == 'refStep') { $ndf = $page->getForPage()->getForPage()->parents("template=ndf")->first(); //move up the tree to get the correct ndf grandparent //get the steps only for the current ndf $selector = "template=substep,has_parent=$ndf"; $steps = $event->pages->find($selector); //<== contains the correct PageArray, verified in Tracy bd $event->return = $steps; //<==doesn't seem to do anything. } }); Sorry that's so complex, but I'm a bit stuck. I've used Inputfield::getSelectablePages many times before without issues, and as I mentioned, I feel sure this used to work. I may have to revert my Processwire upgrade to prove that however ? Any thoughts are welcome! Thanks, Ian

Hi @bernhard - the clone icon is visible for the user. This is what they see on the front end with Alfred: Regards, Ian.

Sorry @bernhard, I now have another question! I've given a user role the necessary "rockfrontend-alfred" permission and that role is able to edit/add blocks etc., but only the superuser gets to see the trash icon on the Alfred front-end. (Users with that role can trash blocks in the back-end). Can you advise how to make this available for a non-superuser role? It seems to be related to $block->trashable() but they have page-delete permission and can trash pages OK (as well as blocks) in the admin . Thx, Ian.

That's great @bernhard thanks! All now working as expected!

Hey @bernhard, Not sure if this is a bug or a feature, but if I clone a page in the admin that contains a RockPageBuilder populated field the new (copied) page has all of the blocks marked as "Temporary Item" and are greyed out (or at least opacity is reduced). It's possible to unmark them as Temp by changing something in each block and then saving the page, but this doesn't seem logical to me (or potentially to my clients). If there are a lot of blocks that might be some effort. I guess that if a copy was made, it might be expected to change something anyway, but I wonder if this is just an oversight relating to RockPageBuilder's logic designed to delete orphaned blocks? Happy to be corrected if this is the intended behaviour. PW 3.0.229, RPB 5.5.3 Many thanks, Ian.

This looks like a PHP version issue. Are you running an old PHP version on the centos server? The newer versions of Processwire require PHP 7.x minimum I believe. If you're running PHP 5.x and trying to upgrade to PW 3.0.229 you are likely to run into PHP parse errors like this. If error reporting is off this will result in a blank page. If that's the case, and you are able to switch PHP to a 7.x version that should allow the upgrade to work. That also depends on the PHP versions you are running on the old and new servers. If your new server is running PHP 8.x then you might encounter parse errors in the /site/ folder, particularly if you have any third-party modules; these might need updating too. However the Processwire core will be OK.

@leode, you'll have to make sure your page classes now extend DefaultPage, rather than Page: <?php namespace ProcessWire; class ArticlePage extends DefaultPage //not Page { //your article page specific methods } ?> <? pages()->get('/mytestpage/')->test(); //should now work

An approach I sometimes use is the following. It seems to work quite well and is fairly clean: Put all your class-specific hooks in your page class, let's say in a ready() function (can be named anything of course, but ready() is a good convention for me). In /site/ready.php, just instantiate a single instance of the page class and call its ready() method. So, if we have let's say a NewsarticlePage class and we want to keep all news article related hooks together, we might have something like this in the page class: <?php namespace ProcessWire; class NewsarticlePage extends DefaultPage { public function ready() { $this->addHook('ProcessPageEdit::buildForm', $this, 'addImportOptions'); $this->addHookAfter("Pages::saved(template=newsarticle)", $this, 'processAfterSaveActions'); $this->addHookAfter("Process::execute", $this, 'processAfterExecuteActions'); } And in site/ready.php: <?php namespace ProcessWire; //required to trigger ready hooks in custom page classes: (new NewsarticlePage())->ready(); (new SomethingElsePage())->ready(); //etc... You can instantiate one empty page object for each Page class you need to run hooks for. There's some overhead, but not much, and it keeps your site/ready.php clean and your hooks where they make sense. Of course you still have to make sure the hooks only target the desired pages/templates. Inspired by some of @bernhard's earlier posts on the subject.

@ryan - thanks for the quick response! That worked perfectly. ? I'll mark this as solved. Much appreciated, Ian. P.S. For anyone interested, here's the site and the specific page that the client noticed had the issue - content in 4 languages (English, French, German, Dutch) all now rendering as expected: https://www.traffic.org/unite-fr/

Hi, I have a site that uses Multi-language URLs and Multi-language Page names to present different language content for the same page, using a language specific URL. After upgrading PW to version 3.0.229, the language-specific field data is only displayed if the home page has the language name (segment) specified and marked as active. Prior to this ( version 3.0.165, I'm not sure at which version this changed), it wasn't necessary to set the home page language name and make it active. Instead, I could just create a specific name for a page beneath the home page (e.g. /test/ for the default language, and /test-fr/ for French), and mark that language as active just for that page, and it would work, displaying the language specific content for that page. The problem I have is that not all pages are translated - in fact there are just a few - and these might have different combinations of language-specific content. One page might have default (English), French and Spanish content, another page using the same template might have default (English), German and Dutch, for example. Hence I don't want the whole site to have a language prefix at the root for every language - just to have language-specific names for those (few) pages that are affected. Until now, this has worked fine, but since upgrading the site to 3.0.229, only the default (English) language content is being shown for those pages, even when accessed via their language-specific URL. Essentially the detection of the language from the page name is now fully dependent on the home page having that language active (and hence a segment prefix) whereas before it wasn't. Can anybody suggest a way around this? If I replace the core LanguageSupportPageNames module with the version from 3.0.165 then the previous behaviour is restored, but obviously that's not a very robust solution. Thanks. Ian.