iank

Hey @bernhard, I think I've found the problem. It's relating to the fact that the view file extension can be either .latte or .view.php (I'm using the .view.php version). The logic for finding the php file edit link is stripping the view file extension and then adding back ".php". This works if it's a .latte view file, but not for .view.php files. In this case, it simply strips off the last part (.php) and adds it back, so we still have the .view.php in the full path. I added this line to ___getIcons() which fixes the problem, though there might be a more elegant solution: $ext = pathinfo($opt->path, PATHINFO_EXTENSION); // php file edit link; view file can be .latte or .view.php $php = substr($opt->path, 0, strlen($ext) * -1 - 1) . ".php"; $php = str_ireplace("view.php", "php", $php); // <============== if it's a .view.php file if (is_file($php)) { .... Regards, Ian.

Hi @bernhard, Sorry for the delay. Here's what I'm getting: Thx, Ian.

Almost! Both the icons now point to the [BlockName].view.php file. I presume one should point to the [BlockName].php and one to the [BlockName].view.php file ?? I'm just using straight PHP for my blocks, not Latte. Thx, Ian.

Hi @bernhard, I've just encountered another issue, possibly because I'm working locally with Windows. The vscode block development shortcuts for Superusers aren't linking to the block view and block php files. Specifically these: They seem to both default to pointing at the \site\modules\RockFrontend\RockFrontend.module.php rather than the individual block/view files. I'm not sure why; maybe it's a difference in the information that debug_backtrace() returns on a Windows system? I don't know if this dump of the backtrace from getTplPath() is helpful: The icons seem to be using the first 'file' entry, although the link to the view file is there... Thanks in advance, Ian.

You're welcome! ?. I can confirm that this solves the issue. Orphaned blocks are indeed removed when the page is saved. Thanks! Ian.

Hey @bernhard, me again! When developing a new block, I was adding it to a page repeatedly, but not saving the page. Instead I would cancel editing and ignore the 'changes not saved' popup, to add more features to the block and try it again. I then realised that this was creating pages under the RockPageBuilderBlocks tree that seemed to be orphaned, containing just my default settings. Of course I can delete these pages, but do you think there might be a way to identify any such orphaned blocks and remove them automatically? Thx, Ian.

Hi @bernhard, Yes, I can confirm that fixes the issue. Thanks! Ian.

Hey @bernhard, Not urgent, but I discovered a slight glitch when trying to delete a block from the dropdown on the module config page, which appears to be down to the backslash notation in Windows (I develop locally on Windows). The getFiles() method of Block.php doesn't find any matching files on a Windows setup. The path returned by the dirname($file) call is returning something like this: 'D:\laragon\www\sitename\site\templates\RockPageBuilder\blocks_general\IanTest/IanTest' whereas the wire->files->find->($dir) returns file paths corrected for backslashes like this: 'D:/laragon/www/sitename/site/templates/RockPageBuilder/blocks_general/IanTest/IanTest.view.php' If I correct the backslashes as follows on line 340, it works just fine: $dir = str_replace("\\", "/", dirname($file)); No rush - deleting the block files manually and doing a modules refresh works in the meantime. Cheers, Ian.

Aha, yes, that's it! ? I have a rich text summary field called "global_summary_rich" that I'm using across blocks. $block->edit('global_summary_rich'); //works $block->global_summary_rich(); //doesn't work $block->rich(); //works Thanks @bernhard. Now I know. I might have to re-think my naming convention though..

Thanks @bernhard, that's a good start! It seems that $block->edit('something') does work for those (textarea/tinyMCE) fields, but $block->something() doesn't. Yet it works for plain text fields. I can see in the source that calling $block->something() for a textarea field doesn't output any of the frontend stuff (pw-editcopy, contenteditable etc.). I expect this isn't a RockPageBuilder problem but something else; I just haven't figured it out yet. At least I can get it to work with the more verbose version. I did touch the frontend edit module settings briefly, but only after I encountered this problem; I thought maybe I had to switch on editing for those fields; that didn't make any difference so I turned it off again. If I can diagnose the problem I'll post back with further details. I'm running PW 3.0.229, RPB 4.7.2, PHP 8.2

Hi @bernhard, I'm working on my first site using your superb RockPageBuilder and for some reason I can't seem to get Textarea/TinyMCE fields 'properly' front-end editable - instead, double-clicking just opens the modal for the block. Standard Text fields are front-end editable, no problem. I must be missing something obvious, but I can't see it. I've installed your demo 'Text' block and the TinyMCE field works - even if I refactor your latte file to a basic view.php file (I'm using PHP view files for my blocks for now). I know that's not much to go on, but perhaps you might know of somewhere I can start to look? As far as I can tell I've pretty much followed all the instructions quite carefully! Is there a hidden setting that I'm not seeing somewhere that makes these fields front-end editable? Many thanks in advance, Ian.

Just a thought - do you have your template specific classes extending 'DefaultPage' rather than 'Page' ? The scenario you're describing has always worked just fine for me.

In your Pages::saveReady hook, the $event->object is actually \Processwire\Pages. The actual page being saved is what's returned from $event->arguments(0). In this case you are assigning it to $user, but that won't always be meaningful; only when you're saving a user. Bernhard's solution will work of course, but it may also be advisable to assign $event->arguments(0) to the variable $page (rather than $user) to avoid confusion in the future. You can then check for $page-template == 'user' if you want to do something specific for users being saved.

I did a little more digging too. It seems as part of the field rename process, the corresponding (old) table is temporarily renamed to tmp_field_yournewname, and then tries to rename this temp table to the correct new name: field_yournewname. This second part fails because the table already exists, so I believe this throws an Exception and you would expect the admin to re-render with an error notice. (Like it does with the normal duplicate field name error). However, since the underlying field's DB table has been renamed to its _tmp version, there's another exception, showing the error. At least I think that's what's happening. DB table names are lowercase by default ($config->dbLowercaseTables is true unless overridden), so 'Body' will try to create 'field_body'. @FireWire, you might find there's a tmp_field_body table in your DB, with all your content intact. Good to know there's a Github issue opened.

I think I may have replicated this. (PW 3.0.200). My suspicion is that it's related to renaming the field to 'Body' (uppercase 'B') when the field 'body' (lowercase 'b') already exists. Processwire lets you name fields with upper and lowercase characters. Here's what I did on my dev system: Create a new field 'test_content'. (The field 'content' already exists). Add 'test_content' to a template and populated several pages with data. Check the db. The table field_test_content exists containing the data just added. Attempt to rename 'test_content' to 'Content' (note uppercase C). Receive error as shown below. Check db again. The table field_test_content is no longer there. It looks as if PW correctly checks for an existing field if the case matches, but goes ahead and deletes the table if not. Subsequently, whenever I try to edit a page with a template containing that field, I now receive the same error.

Just a thought... One possibility is if you have Mod Security installed on the hosting. Often you will get a 403 (Forbidden) message on immediate posting if there's something in the page or posted content that triggers one of the modsec firewall rules. If this happens, nothing gets posted, and the 403 message is shown very quickly. I suspect the PHP Notice is probably unrelated.

@Laegnur Are you running an older version of PW by any chance? InputfieldSelect::addOptionAttributes was only added around version 3.105. The above code works for me, (PW Version 3.200) if I use: $field->addOptionAttributes('Alicante', array("selected" => "selected"));

Markup regions can keep your template files cleaner. Let's say for instance you have common header and footer section for all your pages. Without markup regions you might abstract these to include files and then include them in all your templates, for example: <head> [your template specific head content] </head> <body> <?php include($config->paths->templates . "_header.php"); ?> [Your template specific page content here] <?php include($config->paths->templates . "_footer.php"); ?> </body> Now this is fine if you only have 3 templates, but if your site grows bigger and more complex with possibly more include logic, that's where markup regions become of more value. In _main.php, I often have an empty <region id="pw-styles"> </region> just before my closing </head> tag, and a <region id="pw-scripts"> </region> before my closing </body> tag. Where I have a need for template-specific stylesheets and scripts (e.g for a lightgallery), I can just add these regions into those templates and put the necessary code in there.You can leave these entire region tags out of most templates, then just add them to the 'lightgallery' template, keeping your other templates clean. Over time you might find the need to add additional common code to all your templates. If your site has grown, this could mean updating a fair number templates with that code (or another include). With markup regions, you can just add this new code to _main.php and it's immediately included in all templates using _main.php. Meanwhile your template files remain clean with just their specific content, e.g. a basic page template might just be as simple as this: <region id="pw-content"> [your template specific page content here] </region> <?php include($config->paths->templates . "_main.php"); ?> And your _main.php would look like this: <head> [your common head content] <region id="pw-styles"> </region> </head> <?php include($config->paths->templates . "_header.php"); ?> <body> <region id="pw-main"> </region> <?php include($config->paths->templates . "_footer.php"); ?> <region id="pw-scripts"> </region> </body> Wheareas a template with lightgallery might look like this: <region id="pw-styles"> <link rel="stylesheet" href="/css/lightgallery.css"> </region> <region id="pw-content"> [your template specific page content here] </region> <region id="pw-scripts"> <script src="/js/lightgallery.js"></script> </region> <?php include($config->paths->templates . "_main.php"); ?> Whether that makes things clearer for you I don't know ?, but if you only have 3 templates for your entire site then using markup regions may be overkill.

If you're saving a field's value to a page you need to set output formatting off first. However, to quickly save a field's new value you can use setAndSave(), which doesn't have this requirement: $oldValue = $page->numbers; $page->setAndSave('numbers', $oldValue++);

I'm not sure if this should be considered a bug, a feature, or just something to be aware of, but I came across this behaviour today: Scenario: I have a 'body' field which is a CKEditor textarea field. I'm using $sanitizer->truncate() to output a truncated summary of the body for use on a parent 'list' page; e.g.: $sanitizer->truncate($page->body,200); Everything worked fine. Longer body content is truncated, shorter (<200) is output in its entirety. I then enabled the PageFrontEdit module for the site, and allowed the body field to be automatically editable (Option A). Suddenly, all the shorter body fields were being duplicated in the output. For example, when the body field contains just this: <p>More information will be coming soon...</p> The output from the above $sanitizer->truncate() call was this: More information will be coming soon... More information will be coming soon... After some investigation, I realised this is because the formatted value of the body field in this scenario looks like this: <div id=pw-edit-2 class='pw-edit pw-edit-InputfieldCKEditor' data-name=body data-page=1115 data-lang='0' style='position:relative'><div class=pw-edit-orig><p>More information will be coming soon...</p></div><div class=pw-edit-copy id=pw-editor-body-1115 style='display:none;-webkit-user-select:text;user-select:text;' contenteditable><p>More information will be coming soon...</p></div></div> ... including all the PageFrontEdit wrapping context. When stripped of the html tags the text appears twice and still being less than 200 characters, is output twice. Solution: It's easy to fix in this particular example. Just get the unformatted value before sending to $sanitizer->truncate(): $sanitizer->truncate($page->getUnformatted('body'),200); I don't know if this should be opened as an issue, since $sanitizer->truncate() doesn't know the context of what it's receiving; it's just a string. Maybe this can help others who might run into this problem.

Hi @astock, No problem. You just need to check for the new page's parent in the selector, something like this: $wire->addHookBefore("ProcessPageEdit::buildForm", function (HookEvent $event) { $page = $event->object->getPage(); $myTemplate = "logbook"; //or whatever your template is called if ($page->template != $myTemplate) return; if ($page->startMileage) return; //not if the start Mileage is present $parent = $page->parent; //get the current page's parent //get the most recent logbook with an endMileage value for the current parent $prevPage = wire('pages')->get("template=$myTemplate,endMileage!=,parent=$parent,sort=-created"); if ($prevPage->id) { $page->startMileage = $prevPage->endMileage; } });

Yes, I think a hook would be needed. Something like this should give you a start, added to site/ready.php: $wire->addHookBefore("ProcessPageEdit::buildForm", function (HookEvent $event) { $page = $event->object->getPage(); $myTemplate = "logbook"; //or whatever your template is called if ($page->template != $myTemplate) return; if ($page->startMileage) return; //not if the start Mileage is present $prevPage = wire('pages')->get("template=$myTemplate,endMileage!=,sort=-created"); //get the most recent logbook with an endMileage value if ($prevPage->id) { $page->startMileage = $prevPage->endMileage; } });

The answer's almost in your question! $s = $location->getUnformatted('location_message_start');

Hi, I'm not sure if anyone can help with this, but something odd is happening on one of my PW sites in the Admin=>Logs. When viewing an individual log's entries, the first page displays just fine, but as soon as I click Page 2 or beyond, the content doesn't refresh; the spinner icon stays visible, and the devtools console shows the 404 page is being returned, instead of JSON. I updated PW (from 3.0.94 to 3.0.165) yesterday, but that seems to be unrelated - I've tried reverting to v94, and the issue remains. I probably just haven't noticed it previously. There's nothing in the Tracy Logs or in debug mode that I can see. Lister page pagination is working OK, and pagination on the front-end is fine; it's just in the Log viewer in Admin. The same happens on localhost as well as the live site. Can anyone suggest where to look? It's not a big deal, just frustrating.

I used PDFLayer (https://pdflayer.com/) recently in a project, and it did a good job of rendering some quite complex CSS. It's free to sign up for an api and you get 100 api calls/month with the free version. It could get expensive though if you have a lot of API calls to make (e.g. $9.99/month for 1000 api calls, $39.99 for 10,000). It was quite straightforward to use though, and you can set it to "test" mode for development, where it will overlay "Sample" on the PDF output, but not use any of your API requests.