Jump to content

iank

Members
  • Posts

    96
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by iank

  1. 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.
  2. iank

    Dynamic CSS

    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.
  3. 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.
  4. 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.
  5. 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.
  6. Thanks @bernhard, only just got around to this, but all good now. 👍
  7. 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.
  8. 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!
  9. 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.
  10. @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..
  11. 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.
  12. Hi @bernhard, Sorry for the delay. Here's what I'm getting: Thx, Ian.
  13. 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.
  14. 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.
  15. You're welcome! 😁. I can confirm that this solves the issue. Orphaned blocks are indeed removed when the page is saved. Thanks! Ian.
  16. 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.
  17. Hi @bernhard, Yes, I can confirm that fixes the issue. Thanks! Ian.
  18. 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.
  19. 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..
  20. 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
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.
×
×
  • Create New...