bernhard

I don't know for sure but I don't think that this is possible. All posts that I found do not mention any solutions either: https://processwire.com/talk/topic/17834-how-to-rtl-admintheme-core-files/ https://processwire.com/talk/topic/7262-ckeditor-rtl/ https://processwire.com/talk/topic/13540-ck-editor-rlt-for-arabic/ (@flydev seems to have tested it) But UIkit supports RTL, so it might be possible?

RockForms v3.0.0 removes RockFrontend dependency for asset loading and uses RockDevTools instead. It also comes with a new config migration that creates a field to select a form (eg from your rockpagebuilder blocks):

@Stefanowitsch I'm proud to announce that this is now also successfully ported to rockdevtools 😎 Note that the syntax changed to grow() and shrink() as it is not any more a RockFrontend feature and AI told me it's safe to use these wordings as they are not used in css/less/sass https://www.baumrock.com/en/processwire/modules/rockdevtools/docs/rockcss/

Yes that should be all you need to do.

At the moment I'd recommend simply not to upgrade and use the new RockFrontend + RockDevTools just for new projects.

@FireWire thank you very much! Another little detail I just found: I wanted to translate "Telefon" to EN + CZ. For EN it's "Telephone", fine. For CZ it seems to be "Telefon", the same as in German: Now the problem is that if it is the same and it is saved like this, the field's value is lost: Not sure if that is an issue with your module or rather an issue for Ryan? What do you think? I think it's more a thing that should be handled by the core. When the field is filled out and the same as the default's language value, I think it should automatically save as "+" which tells PW to use the same value as the default.

PS: Thought it might be translation cache, but just flushed the cache and I get the same (wrong) translation 😞

Hey @FireWire any idea why this is not working: Never used this feature before, so I might be doing something wrong? Thx for your help!

Hello and welcome to ProcessWire 🙂 Seems you are lucky - this is my setup that I just shared 4 days ago:

That's wrong. It should either be $rockfrontend or rockfrontend()

RockFrontend will not be deprecated. I need it for every project. I just moved styles() and scripts() and LiveReload to another module. Regarding asset minification: I need that on almost every module that I create. I have some CSS or LESS files in the module's /src folder and I want to compile them to CSS / minified CSS. I did that using RockFrontend, which is not really what the module was built for. Now this is done with RockDevTools. Same for LiveReload. I need LiveReload for development, both on the frontend and on the backend. All the time. But only on my development machine, not on production. That's how RockDevTools works now.

Just released v5.0.0 of RockFrontend LiveReload has been removed (moved to RockDevTools) styles() and scripts() feature has been removed (moved to RockDevTools) RockDevTools is unfortunately not a drop-in-replacement as we had to change how assets are handled and included into the final website markup. The good news is that RockDevTools also supports merging multiple files to one and it will also work with template cache enabled 🙂

Imagine you have a multisite setup where you need different languages for different domains: One website might be single-language (DE only), another one might need DE/EN/CZ, and another one might need DE/EN/HU: I didn't know how to do it, and I didn't find any other posts with a similar need or solution. When looking into the code I even thought that my need was not possible yet without modifying a core file. So I asked Ryan if he was willing to make the process of adding languages to the $languages array hookable. Turns out that this is not necessary! All you have to do is to grab the Iterator of the languages array and remove languages as you need: // /site/ready.php if($anyCondition) { // remove CZ language $languages->getIterator()->remove("name=cz"); } So simple 😍 Maybe it helps 🙂

Hi everyone! I've started working on a new module that contains development tools like asset minification. Why a new module when RockFrontend and RockMigrations already have similar features? I wanted to start fresh to make the code cleaner, and most importantly make it work properly with template cache! The old implementation in RockFrontend using page render hooks simply couldn't handle that. The module is intended for development-only and should be disabled on production. The idea is to create minified assets while developing and then push the minified assets to production and there just include them in your markup! LiveReload has also been moved from RockFrontend to this module. It's simply not a frontend-tool but rather a development tool! Using RockMigrations, for example, I'm always using the LiveReload feature on the backend, so it does not really make sense to have it in the frontend module 🙂 Download & Docs: baumrock.com/RockDevTools

Anybody stumbling over this site profile might also be interested in my new RockInvoiceItems Fieldtype/Inputfield 🙂

Rock-Monthly Newsletter subscribers know that I'm rebuilding my custom CRM/bookkeeping software. It has already sparked two powerful new Rock modules! 🚀 RockInvoiceItems provides a powerful Fieldtype/Inputfield combo for handling invoice line items with real-time calculations, rich text editing, and a clean UI. Key Features: Dynamic line item management (add/delete/clone/sort) Rich text editing item descriptions with TinyMCE Automatic calculations (subtotals, VAT, grand totals) Multiple VAT rates support Drag & drop sorting Easy to use PHP API, eg $items->subtotal(), $items->grandtotal() German translations included The module extends WireArray and handles all the JSON serialization/deserialization behind the scenes. It's easy to install - just drop it in your modules folder and you're ready to go! Download & Docs: baumrock.com/RockInvoiceItems Let me know if you have any questions! 👋

This module allows you to quickly connect a datefrom and a dateto field and calculate a duration, plus it adds buttons to quickly set the date/time of both fields in customisable increments: Download & Docs: baumrock.com/RockQuickDates Let me know if you have any questions! 👋

That's a valid question by the client. That's why I do not allow images in richtext fields. But there's never an "ideal approach". Everything has pro's and con's.

RepeaterMatrix and RockPageBuilder. There you don't add content to one WYSIWYG field but instead compose your blog content from predefined blocks where you have full control over the generated markup for each block and the client still has the flexibility to choose whatever blocks he/she needs. Similar to what @Robin S suggests if you are using RockFrontend that's already on board via Dom Tools. $dom = rockfrontend()->dom($page->your_wysiwyg_field); $dom ->filter("img") ->each(function (HtmlPageCrawler $node) { $newHTML = '...' $node->replaceWith($newHTML); }); echo $dom->html(); I'd highly recommend not to use images in richtext fields, though.

It should not matter when/where you do it. The only thing that matters is that you attach your hook before you actually call the method that is hooked. If you call the method first and than add the hook it will obviously not return the hooked result but the plain result.

I'd be interested, but I don't understand what you are saying. Neither what you said yesterday nor what you said today. What is "a class loaded directly on a page"? And what is "indirectly within a form" ?!

Thx, will be added in the next version!

/site/init.php wire()->addHookAfter('Foo::hello', function ($event) { $event->return .= ' - hooked :)'; }); /site/modules/WhatEver/Test.module.php <?php namespace ProcessWire; use MyNamespace\Foo; class Test extends WireData implements Module { public static function getModuleInfo() { return [ 'title' => 'Test', 'version' => '0.0.1', 'summary' => 'Your module description', 'autoload' => true, 'singular' => true, 'icon' => 'smile-o', 'requires' => [], 'installs' => [], ]; } public function init() { wire()->classLoader->addNamespace('MyNamespace', __DIR__ . '/classes'); } public function ready() { $foo = new Foo(); bd($foo->hello()); } } /site/modules/WhatEver/classes/Foo.php <?php namespace MyNamespace; use ProcessWire\Wire; class Foo extends Wire { public function ___hello() { return "HELLO!"; } }

I'm using namespaces all the time and it works for me when not adding the namespace on the hook.