iank Posted November 13, 2023 Share Posted November 13, 2023 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. Link to comment Share on other sites More sharing options...
bernhard Posted November 14, 2023 Share Posted November 14, 2023 Hey @iank thx for your purchase ? The only thing to know is that $block is the variable for the block page and that $block->something requests the field value and $block->something() requests that field as frontend editable field, which is the same as $block->edit('something'); Does that already help? Other than that did you change the settings of the frontend editing module? I never touch these. Maybe you have a step by step guide to reproduce the issue? Link to comment Share on other sites More sharing options...
iank Posted November 14, 2023 Author Share Posted November 14, 2023 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 1 Link to comment Share on other sites More sharing options...
bernhard Posted November 14, 2023 Share Posted November 14, 2023 You can also try changing the name of the field. Maybe that makes a difference? There is a naming convention for this feature! I'm heavily using prefixes and therefore it only takes the last part after the final underscore. So a field my_great_textarea_field would be $block->field() Maybe that's the issue? Link to comment Share on other sites More sharing options...
iank Posted November 14, 2023 Author Share Posted November 14, 2023 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.. Link to comment Share on other sites More sharing options...
bernhard Posted November 14, 2023 Share Posted November 14, 2023 Ah yes sorry for that - I see it's not in the docs and I'll add that asap ? 1 Link to comment Share on other sites More sharing options...
bernhard Posted November 14, 2023 Share Posted November 14, 2023 Here you go: https://www.baumrock.com/en/processwire/modules/rockpagebuilder/docs/fields-access/ Accessing Fields All fields of your block will be available to your $block variable just like usual: echo $block->your_field_name; echo $block->edit('your_field_name'); Method Syntax RockPageBuilder comes with a helper to make working with long fieldnames easier and less verbose. The reason for that is that when I create new blocks I always prefix all fields with the block template name. That way I can be sure that when I copy that block to another project the fieldnames don't collide with existing fields. The problem here is that we end up with long fieldnames like this: rockcommerce_invoice_pdf. When using RockPageBuilder you can do this: echo $block->pdf(); This feature is actually a feature of RockMigrations' MagicPages module. You can also pass parameters to request a different state of the field: $block->pdf(); // frontend editable field $block->pdf(1); // using ->getFormatted() $block->pdf(2); // using ->getUnformatted() Note that the method call has to be the last part of the string after the final underscore: // field foo_bar_baz $block->baz() // field foo_something $block->something() 2 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now