Leaderboard
Popular Content
Showing content with the highest reputation on 10/09/2024 in all areas
-
Hey all! I've been creating new block/widget buttons for the current project I'm working on and wanted to share them in case they may be useful to others. They're SVGs intended to complement the style of buttons that come with RockPageBuilder. This post has been updated with a link to a Github repository containing all of the buttons currently available. New buttons have been added. Existing buttons have have been tweaked for quality and consistency. Download from or fork the Builder Buttons Github repository Rather than keep this post up to date with every button that is added, visit the Github repo to see the most current example and download/clone buttons for use in your projects. Buttons include: Accordion Announcement Articles Audio Bios Call To Action Card Over Image Code/Embed Events Image Image Carousel Image Mosaic Image Roll List Lists Products Reviews Video Weather Preview (not in order of list) If you find them useful, let me know what you think!
3 points -
@ngrmm Hey there, Fluency author here. I submitted a PR that makes ProcessTranslatePage compatible with the new major release of Fluency. It hasn't been merged yet, but you should have success using this module with these changes. https://github.com/robertweiss/ProcessTranslatePage/pull/102 points
-
Yes, this seems to be the problem. ProcessTranslatePage works with the latest Processwire version, but not with Fluency V2 (yet). @FireWiresorry for the long wait, I did not have time to merge your PR yet, but thanks a lot for your effort!1 point
-
Nice, thanks for sharing. BTW: Works also perfect for the ProModule RepeaterMatrix from @ryan1 point
-
being 1033 the page with the children you want to get: //Given than child only returns a single page, you can use sort,to for example get the newest child of 1033. $pages->get(1033)->child("sort=-created, include=hidden");1 point
-
Hi @Ivan Gretsky I have pushed a new branch into Github here: https://github.com/horst-n/WireMailSmtp/tree/php-namespace This is called version 0.8.0 and all PW-PHP-module-files are now added into the PHP namespace ProcessWire. So now the module only can be used with PW > 3.0.62 (after merging to master branch). All the backwards compatibility to starting PW version 2.4 is lost now. 🙂 Please, can you fetch the new version from the github dev branch and test it, if it helps with your errors and let me know? For me everything is working fine here. The normal sending, the DebugTests in Frontend and in Backend, etc. PHP 8.1 + 8.2 ...1 point
-
Hey @herr rilke thx for sending me the files. The good news is that you can please mark this topic as [solved] here in the RockPageBuilder forum, because it is not related to RPB but rather to RockFrontend. The bad news is that the way I designed RockFrontends assets feature does not reliably work with template cache at all. It works with no cache, it works with procache, but it doesn't work with template cache. The problem is that with ProCache we get a 1:1 copy of the rendered page without calling any php files on the request. That's fine, because then all assets are already injected in the <head> and the browser just loads the static files. If template cache is active it's different: Files like _init.php or layout.latte are not loaded and also not all the template php files, but all other php files like RockFrontend.module.php or RockPageBuilder.module.php are loaded. So it's a problem to place $rockfrontend->styles()->add(...) in files that are not loaded and other calls of styles()->add() in files that are. That's what you are seeing. RockPageBuilder assets are being loaded from RockPageBuilder.module.php but uikit files are not, because they are injected from _init.php or layout.latte or _main.php (wherever one might place it) which is skipped by template cache. To be honest I'm not yet sure what to do about this as this would mean a major rewrite of all my projects and likely any project built on top of RockFrontend. The easiest fix for your situation would be to just use ProCache, which is worth every cent. If anybody has a good idea please let me know. I'll have to think about a good solution...1 point
-
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()1 point
