Leaderboard

A big shout-out and thank-you to @bernhard for keeping on improving the RockFronend. (and the whole Rock-EcoSystem) continuously. I asked for a minify-feature and here it is! I am using RockFrontend in every project now as it combines some must-have features for frontend development (IMHO!). Today a new feature was added (or lets say improved as auto-minify was included before) The Minify Feature (for Styles and Scripts!) See the Wiki entry here Lets start simple: How do I include stylesheets with RockFrontend in the first place? RockFrontend always had the feature to bundle stylesheets via the styles() function. For example I am loading some LESS partials into my header like this. You don't have to use LESS files, regular CSS files work the same. Note: Since RockFrontend offers LESS support you can add those files directly, no need to compile them and add the CSS files. For this you have to install the ProcessWire Less module. <? $rockfrontend->styles() ->add($config->urls->templates . 'styles/less/uikit/_custom-import.less') // add single LESS or CSS file ->addAll($config->urls->templates . 'styles/less/project') // point to folder to include files automatically ->addAll($config->urls->templates . 'styles/less/custom') ?> The result in this case is a single compiled CSS file that will be included in your head automatically. RockFrontend is very smart. You don't have to include tons of partial LESS project files here. Just use the addAll() function and point to a folder where your assets are saved and the module does the import for you. This is how my folder structure looks like. If I create new LESS files in there, they will be added and compiled automatically at runtime. How to minify For debugging and development purposes I don't use the minify feature. Instead I use it on the staging server exclusively. To generate a minified version of your stylesheet just add minify(true) <? $rockfrontend->styles() ->add($config->urls->templates . 'styles/less/uikit/_custom-import.less') ->addAll($config->urls->templates . 'styles/less/project') ->addAll($config->urls->templates . 'styles/less/custom') ->minify(true); ?> If you want to chain the minify function it to your debug-mode state you can do it like this (my preferred solution). <? $rockfrontend->styles() ->add($config->urls->templates . 'styles/less/uikit/_custom-import.less') ->addAll($config->urls->templates . 'styles/less/project') ->addAll($config->urls->templates . 'styles/less/custom') ->minify(!$config->debug); ?> That's it! Does minify work with Scrips? Yes, exactly the same. But you make use of the scripts() function in this case. <? $rockfrontend->scripts() ->add($config->urls->templates . 'scripts/script1.js') ->add($config->urls->templates . 'scripts/script2.js') ->add($config->urls->templates . 'scripts/script3.js') ->minify(!$config->debug); ?> Note that these script files are not bundled (even if you chose minify false). Instead they all come out as minified versions separately. I find that this workflow I straight forward and it combines some of the best features that RockFrontend offers! If you combine this with the awesome autorefresh feature, frontend development becomes a breeze!

I think what you are looking for is an https://processwire.com/api/ref/inputfield-markup/ inside your Block Ordering Tab. You can use that to output the markup that is being supplied by your Hannacode. And you don't even need that Hannacode. Because your development template ordering lives on a single page that doesn't change in different contexts. So you can produce the markup for InputfieldMarkup from that page id. For InputfieldMarkup you can set the property markupFunktion to a closure that outputs your block order. Something like /** @var InputfieldMarkup $f */ $f = $this->wire->modules->get('InputfieldMarkup'); $f->set('label', 'Development Template Ordering Status'); $f->set('markupFunction', function () { $markup = ''; foreach(wire('pages')->get(yourid)->get('block_order_field') as $block) { $markup .= "{$block->title}<br>"; } return $markup; }); $inputfields->add($f); This will output something like

@Stefanowitsch thanks for your input here... After I worked for years with the combination "setlocale" & "strftime", I realize today through my intelephense that strftime is DEPRECATED. So I went looking for a successor and ended up here with your article. I like the one-liner very much! I had to adapt it only a little, because I got otherwise errors with the classes and with the format of the date... Therefore here my adapted version... echo \IntlDateFormatter::formatObject( new \DateTime(date("d.m.Y", $page->getUnformatted('date'))), "EE dd.MM.YYYY", 'de_DE' );

Hi all, Media Manager Next/013 Sorry I haven't posted here in a while. I am currently working on the next version of Media Manager. It will part be refactoring and part be some new (some requested) features. I have been having some very helpful conversations with a number of you. Below are the current plans for the next version. Any other thoughts and/or ideas I should consider? It is a bit of work so I might have to stretch this into several updates (versions). Thanks. New Features Upload from external sources (Amazon, Google, etc.). Point media to external resource (e.g. to a video in YT, Vimeo, etc.). Independently set media title on upload Improve/extend media filter/profiles to MM Inputfields (possibly pick and apply a profile from a list) (thanks @gebeer) PDF thumb preview (thanks @gebeer) Upload and replace media (for single media MM inputfields). API (thanks @MrSnoozles) Any other thoughts.....? Refactor Remove dependency on JqueryFileUpload Remove dependency on jQuery -> use htmx and alpine JS instead. Easier to maintain for me as well as more flexibility. Improved preview of media and their properties. Better preview of media before upload. Redesigned GUI - Intuitive (like GDrive(?)), do away with media menus (use filters instead), need oMedia is just media. Remove/reduce use of modals. Allow grouping of media (link an album) <- not yet confirmed if will be implemented Implement hookable methods to allow easier developer control for those who need advanced/custom control of their MM. A number of reported bug fixes as well. ETA? I cannot give a firm date about this, sorry.

Hello, Is anyone using static analysis tools like Psalm/PHPStan and/or Semgrep on PW here? If so, could you share a little wisdom with tricks/config that can help get started with them on a PW project? I've got a few semgrep rules worked out, and they seem to work well, but I'm struggling with the huge number of detections when using Psalm vs a PW project. I guess I could just baseline the current state of play and take things from there, but wonder if there is anything else I should be doing to make Psalm more aware of PW itself. Thanks for reading.

I just came across this issue and the solution is pretty simple: replace strftime() with date("YmdHMS", $seconds) I don't really understand the use of strftime() here since there's no use of language-dependent strings... @horst Could you have a look at this or would you rather accept a PR?

I agree it's not the best UX, but have a read here: https://processwire.com/talk/topic/14979-why-is-a-value-required-to-pre-check-checkboxes/?do=findComment&comment=134243 I think that makes sense and your Pages::added hook seems to be a good solution as it's the only other possible option that ryan mentioned. PS: If you are using custom page classes you can make it a MagicPage and then it's simply this: public function onCreate() { $this->youroptions = [1, 2]; }

Hi @Boost This may help. Gideon

@AAD Web Team, this module can help with that: https://processwire.com/modules/find-merge/

So i tried the other way around and formatted a date using the IntlDateFormatter. This thread helped me find my way: https://stackoverflow.com/questions/71874030/local-language-without-strftime-deprecated-but-with-date So imagine we want to output "today" like this (formatted for german) Mittwoch 8 Juni 2022 This was the old way to to it: echo strftime('%A %e %B %Y', strtotime('now')); Since this will be deprecated in PHP 8.1 and removed in PHP 9 now we have to make use of this instead: $fmt = new IntlDateFormatter('de_DE', IntlDateFormatter::FULL, IntlDateFormatter::FULL ); $fmt->setPattern('EEEE d LLLL yyyy'); echo $fmt->format(strtotime("now")); The only thing that freaked my out about this was the weird formatting pattern. At first sight it makes no sense (to me), but the ICU documentation offers a big list of available options for formatting the date in any way you could imagine: https://unicode-org.github.io/icu/userguide/format_parse/datetime/ If you are looking for a "one liner solution" then this seems to be the right way (https://stackoverflow.com/questions/12038558/php-timestamp-into-datetime) echo IntlDateFormatter::formatObject( new DateTime('@' . strtotime("now")), "EEEE d LLLL yyyy", 'de_DE' ); EDIT: Beware that timezone settings get ignored when you work with timestamps. This might get you into some trouble. My solution was to format the timestamp into a date string: echo IntlDateFormatter::formatObject( new DateTime(date("d.m.Y", $timestamp)), "EEEE d LLLL yyyy", 'de_DE' );

Found it! Leaving up for future people.

Hi @VeiJari It's usual practice, but not compulsory, to put hooks into /site/ready.php. site/ready.php loads before _init.php. You're changing the saved page data so you may need to turn off outputting formatting first if saving the entire page, or simply set-and-save the 'ajasta' field, eg (untested): wire()->addHookAfter('Pages::published', function($event) { $page = $event->arguments('page'); $t = wire()->templates->get($page->template); if($t->name == 'artikkeli' && $t->hasField("ajasta") { $page->setAndSave('ajasta', 0); } $event->return = $page; });

I've done quite a number of forms with this type of setup, not sure if any of this js would help but just in case... (using custom timepicker init and callbacks)

To point it down: For everything you want to do, but can't do with built in functionality, you need to find the appropriate hook and then use it!

An extra +1 for using the the Console panel's code injection feature for testing hooks

via page save hook would be the only reliable way. via some javascript would be the more user-friendly way. $(document).on('change', '#Inputfield_yourdatefield', function(e) { var yourdate = $(e.target).val(); var yourotherdate = ...; if(yourdate < yourotherdate) { alert('yourdate must be higher than ...'); // reset field $(e.target).val(''); } }); doing both would be the best don't think there's a built in way...

Hi @cjx2240 Here is Ryan's note about that: The question is an easy one when talking about forms that get submitted once, but not so easy when talking about forms that edit existing pages and will continue to do so indefinitely in the future. That's why you see in initial value support in many Inputfields that doesn't apply when used in a page/field context. Meaning, you see the option when using an Inputfield in FormBuilder, but not when using the same Inputfield for editing a page field. When it comes to this FieldtypeOptions module, initial value support (pre-selected options) needs "required" status for the Inputfield because it has to have some way to know when to populate the initial value. It knows to populate the initial value when there is no selection present. There isn't any other straightforward way for it to make that determination, unless we limit the feature only to newly created pages. If the user were to de-select everything so that no options are selected, then the initial value would once again get populated the next time they edited the page. That's why we only support initial values if "required" status is active, as it prevents the possibility of the user de-selecting all options and assuming it will stay that way. There is an easy way around it though. Create an option to represent "no selection", likely your first option. If the user literally wants no selection, they would select that, and still meet the "required" status of the field. From there you can have any pre-selected option(s) you want. Since you as the site developer put that option there, you can likewise know when to act–or not act–upon it in your output code.

meanwhile i have found out, that if i set the cloning permission directly at role level (Access -> Role -> editor) and disable the cloning permission on template access level, the page tree cloning works, but now the cloning functionality is assigned to all editable templates. I think for now i can llive with that, although i'd be happier if i would have been able to configure cloning per template...