iank

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.

Likewise. It's certainly not a deal-breaker, and the showIf fix is a big step forward for my needs. ?

Thanks @bernhard, looks like this is now fixed. I'll mark this topic as solved.

@bernhard, showIf conditions are now working as expected. These are working in all three edit modes: Full page edit, block "edit in new window" and front-end block edit with Alfred. However, This is not working for me when editing a block in full page edit mode. If a requiredIf condition is met, then none of the block's changes are persisted. When editing a block via "edit in new window" or front-end with Alfred, the requiredIf conditions work and the changes are saved. Sorry to be a pain - I think we're almost there, but I can't for the life of me figure out why this is happening only in the full page edit scenario. I can create a screencast demonstrating the issue if that would be helpful. Thx, Ian.

Hi @bernhard, Just revisiting this. I hadn't noticed, but @Klenkes is correct - the orphaned block deletion is broken again in newer versions of RockPageBuilder. It did work up to at least v5.0.3 but it looks like an extra check was later added in getUnusedBlockIds(): // never delete blocks younger than 10s 'created>' => time() + 10, Which I believe is saying "find unused blocks that also have a created time newer than 10 seconds in the future". Hence it's not going to find any. Changing to this: // never delete blocks younger than 10s 'created<' => time() - 10, Appears to resolve the problem, and I think is doing what the comment says? Thx, Ian.

The TailwindCSS JIT compiler scans the source code rather than the html output, so it's looking for full class names in your PHP code. Hence you could do something like this: <?php namespace Processwire; $bg = $page->bgSetting === "success" ? "bg-green-500" : "bg-red-500"; ?> <div class="mt-4 max-w-md <?= $bg ?>"> Lorem ipsum dolor sit amet consectetur adipisicing </div> Or you could simply fake safelisting the expected values, e.g. in a comment if you just have a few you want to make available in a template: <?php namespace Processwire; $bg = $page->bgSetting === "success" ? "green-500" : "red-500"; /** safelist values: bg-red-500 bg-green-500 bg-blue-500 */ ?> <div class="mt-4 max-w-md bg-<?= $bg ?>"> Lorem ipsum dolor sit amet consectetur adipisicing </div> As long as the full string of the class name is in the code, it will get compiled by TW (use spaces between if you're using this method though, as if you were adding classes directly). (Of course there's also Tailwind's safelist setting in the tailwind.config file: https://tailwindcss.com/docs/content-configuration#safelisting-classes) Ian.

Hi @bernhard, I discovered some more information which might help with troubleshooting. I came across this post which seemed to be related: https://processwire.com/talk/topic/29225-solved-show-this-field-only-if-doesnt-seem-to-work/. As mentioned in that post, if I use Alfred on the front end, or choose "Edit in new window" from the admin side, the changed information does indeed get saved. Only when editing the blocks in the admin in 'repeater mode' does the 'showIf' information not get saved. I hope that points you in the right direction (and for now I have a workaround!) Thx, Ian.

Edit: OK, I think we can ignore the dependent field types involved (page reference, Fieldset (page)) - a simple example with just a checkbox and a textarea exhibits the same problem. It definitely looks to be something related to the "showIf" condition rather than the underlying fields: ----------------- Hi @bernhard, sorry to be a pain. In fact, I have the same problem if the dependent field is a FieldtypeFieldsetPage, as in this example: This example is part of a Call to Action block. The 'Action' field is a Select Options field, and the 'Link to Page' field is the Fieldset (Page) field containing the three nested fields you can see. None of those three fields are saved when the block or page is saved. I think it must be something to do with the 'showIf' logic. Again this logic is just moved over from a RepeaterMatrix field where it worked just fine. Thx, Ian.

Hey @bernhard, RPB is so great I decided to migrate from RepeaterMatrix for a site I'm working on ? However, I came across a snag with a page reference field not saving to the DB. I have a fairly basic 'RichText' block which in addition to the basic title/textarea fields has a checkbox to show a page reference page (single page) via a showIf condition. If the checkbox is checked, the page reference field is shown: But when the block (or parent page) is saved, the chosen option doesn't get saved. I know the page reference field works, because this is exactly the same logic (using the same fields) I've ported across from my RepeaterMatrix field. Furthermore, if I disable the "showIf" condition in the RPB block, the page reference once again works correctly. In the example above, I'm using a select dropdown, but I get the same behaviour if it's a Radio Buttons list. Any thoughts? Much appreciated, Ian.

Thanks @bernhard, only just got around to this, but all good now. ?

Hey @bernhard, Any suggestions how to stop the RPB log from filling up with these messages? They seem to occur every few seconds. I also from time to time see a warning in the Admin along similar lines, but I'm not using Less. I just noticed the log had > 14000 such messages, so I pruned it and already a short while later it's up to 40! Many thanks, Ian.

Hi @bernhard, Many thanks. Yes, the update to v5.0.0 has certainly fixed that issue. Yes, I definitely do ? I like the drag 'n' drop sorting too, although it can be a little difficult to know whether you're dropping in the right place when you have blocks that are quite long on the page. At least you can still do it the 'old' way as well, on the admin page edit screen. Many thanks for the quick response!

Hi @bernhard, Hope I can explain this well enough: I have several RPB blocks that contain image fields (some are single image, others multiple images). I used your VScode snippets to create the image field in the block's $rm->migrate() method, e.g: self::image => [ 'type' => 'image', 'label' => 'Image', 'maxFiles' => 1, 'descriptionRows' => 1, 'extensions' => 'jpg jpeg png', 'maxSize' => 3, // max 3 megapixels 'maxWidth' => 1200, 'maxHeight' => 1200, 'icon' => 'picture-o', 'outputFormat' => FieldtypeFile::outputFormatSingle, 'gridMode' => 'grid', // left, list ], But when I then add a new block to a page from the admin, it seems the image field isn't ready to accept images, either via the "Choose File" button, or via drag and drop. In fact it looks like this: The Choose File button allows the selection of a file, but nothing is uploaded, and dragging/dropping does nothing. There are no JS errors in the console. If however I save the page, the field seems to resolve itself and is then able to receive images: I've tried various options, including saving the field again in the Admin, and copying/pasting the full RockMigrations Code from the field's Basics tab, but to no avail. Have you any ideas? Many thanks in advance, Ian.

@bernhard, That works, yes, but only if you update the $file = Paths::normalizeSeparators($step['file']); in the getTplPath() method as well, as you suggested earlier..