Leaderboard

This week I've worked through a few minor issue reports in both the core (ProcessWire) and InputfieldTinyMCE repositories. In addition, a new version of InputfieldTinyMCE was released that includes various improvements. We'll likely go through a few minor versions of this module before it is added to the core. I recommend downloading the latest posted version (6.0.3). Thanks to all that have been helping to test and report issues as they come up. I'm going to give the core another week or so of updates before we bump to the next version there. If you've recently launched any new sites, please add them to our sites directory at processwire.com/sites/submit/ when you have a moment. And if you aren't already subscribed to the ProcessWire Weekly updates email be sure to subscribe. Thanks and have a great weekend!

Most of the time I use Combo for settings in my MatrixFields to build sections of content. Like this: Or like that: All the fields are in one place and showif works great within Combo. Not so great if you have a dependancy in a parent field.

The latest version of RockMigrations comes with a console on the module's settings page. What does that mean? It is now easier than ever to create custom "site-profile" like installation scripts that you can just copy and paste into that console. Add or remove the lines that you need or don't need, check the checkbox to run code on save and hit the save button!! ?

Is it trying to display thousands of pages and timing out? If so maybe an input type such as Page Auto Complete, which doesn't load all of the pages at once might work.

(In my first message, I didn't understood that you was going to modify an existing ProcessWire site). But the message is still valid to get an introduction before the update. What do you mean by "just find the code" ? You mean in an admin page ? You have everything you are looking for in `home.php`, read below. Not really, you could even forget the admin, (even if it's not really the case, but that's how I still see it and saw it), the admin pages, fields and templates let you manage and organize what's inside the db, it's just easier. On your screenshot, we can see that the code of the homepage, is in `/site/templates/home.php` and pull from the database the title of the page from the field `title`, some images for what it look to be, a carousel or hero block `hero_image`, also some client testimonials from `testimonials` field. As you are old, to refresh your memory, remember when you was getting theses data from a database with `select * fields from site_db where page="home"`, now you have it at hand, in an admin page, with a lot of API helpers given by ProcessWire to get/set all of that. Now, if you understand that the $page call give you the current visited page, called `home` in your example, in the page-tree, with a template (file with code) `home.php` then you can understand that $page->title, $page->hero_image and $page->testimonials give you the value (from the db) of theses fields. Anyway, please open with notepad the file /site/templates/home.php and paste it here in the thread so we can get the strategy used (I bet it's the simple one with php include() calls) and we will be able to make things more clear to you.

As an aside, I started using Settings Factory for this - it's an interesting alternative if you ever want a combo setting that isn't tied to a page, but it does require some scripting knowledge to configure. Not meaning to derail from the combo discussion.

While I'm not using it in real world project yet, the Combo field works well for a "link" field. For example, you could link something to a page (page field), a external website (url field) or a modal (page field), or a page + url parameters. Also, what about absolute vs relative URLs? Here's an export of that field you can import and play around with: https://pastebin.com/N8UuiFKQ Somewhat related is this module:

I think it should be enough to just remove the hook once it got triggered? It's definitely better to add the script in the renderReady method rather than hooking buildForm or something, because in buildForm() you don't know whether your alpine field will be rendered or not (or you'd have to check that yourself and don't forget about nested fields etc...). <?php $this->addHookAfter('AdminTheme::getExtraMarkup', function ($e) { $parts = $e->return; $parts['head'] .= "<script defer src='https://unpkg.com/alpinejs@3.10.2/dist/cdn.min.js'></script>"; $e->return = $parts; $e->removeHook(null); // add this line });

You could call $modules->getModuleInfo('all', ['minify' => false]) and iterate over the results. Each entry has a "core" property and an "installed" property you can check.

Love that ? RockFrontend uses this syntax which I think is simpler and better than array syntax, because you don't have to think about all the custom attributes one might need. It's simply a suffix as a plain string: $rockfrontend->scripts()->add("foo/bar.js", "defer"); // the last part is simply a string, so you can do anything you need ->add("https://code.jquery.com/jquery-3.6.1.min.js", 'defer integrity="sha256-o88AwQnZB+VDvE9tvIXrMQaPlFFSUTR+nldQm1LuPXQ=" crossorigin="anonymous"');

Padloper 2 uses Alpine.js (and htmx) in lots of places, including Process modules and Inputfields. Without defer, as you point out, Alpine.js goes funky. My solution is to use inline scripts. ProcessWire does so itself, in several places. For Process modules, I have a method like below that I use to inject Alpine.js script where I need it: <?php namespace ProcessWire; private function getInlineScripts() { // @note: need to load alpine as 'defer' $url = $this->wire('config')->urls->$this; $alpinejs = "{$url}vendors/scripts/alpinejs/alpinejs.3.2.4.min.js"; $out = "<script src='{$alpinejs}'defer></script>\n"; return $out; } It might not look pretty for some people but your browser doesn't care and it doesn't bother me either . For Inputfields, I have this: <?php namespace ProcessWire; public function ___render() { // .....some code /** @var PageArray $value */ $value = $this->attr('value'); $form = $this->buildForm($value); $out = ''; //---------- // ...etc //---------- // MAIN render content $out .= $form->render(); // ------- /** @var str $preloadInlineAssets */ $preloadInlineAssets = $this->renderPreloadInlineAssets(); if (!empty($preloadInlineAssets)) { $out .= $preloadInlineAssets; } //---------- // APPEND any configs for this Inputfield that might be needed by JavaScript // E.G. translated strings. $out .= $this->renderJavaScriptConfigs(); //------------- return $out; } private function renderPreloadInlineAssets(){ // ...some code: conditions, etc // ---- $out = "<script src='{$source}'{$defer}></script>\n"; return $out; } I've been meaning to make a request to have this handled by config->scripts->add(), e.g. <?php namespace ProcessWire; $config->scripts->add($alpinejs, ['defer' => true, 'integriy'='some_hash', type="module"]);

I've been using panels a lot in the past but I switched to using modals as they seem to have more features like the one you are asking for. Maybe it's also possible with panels, but I've done it using modals and adding the "data-autoclose" attribute to the link. This is a link created by RockFrontend's Alfred editor: <a href="/cms/page/edit/?id=1047" class="icon pw-modal alfred-edit" data-barba-prevent="" data-buttons="button.ui-button[type=submit]" data-autoclose="" data-reload=""><img src="/site/modules/RockFrontend/icons/edit.svg"><span class="alfred-cover" title="" uk-tooltip="" aria-describedby="uk-tooltip-34" tabindex="0"></span></a>

@protro do you get same result with jsConfig() ? Also, I think it's only exposed on admin pages by default. For frontend you will need (as always) to make it available yourself, as nothing is done on frontend things by default, except processwire api: On your <head> tag in frontend, eg. _main.php : <!-- credit to @soma --> <script type="text/javascript"> var config = <?php echo json_encode($jsConfig); ?>; </script> Then // Set a property from PHP // $config->js() is still here for backward compatibility, use jsConfig() $config->jsConfig('mySettings', [ 'foo' => 'bar', 'bar' => 123, ]); // Get a property (from PHP) $mySettings = $config->jsConfig('mySettings'); // Get a property (from Javascript): var mySettings = ProcessWire.config.mySettings; console.log(mySettings.foo); console.log(mySettings.bar);

Not all. ?

On many of my sites I have a page for business information which includes: toggle for site down for maintenance or live combo field for business name, address, phone, email, contact name, etc functional field for common phrases The combo field is great in this scenario. The data is fairly static and I only need to add the one combo field for a bunch of 'sub' information, bits of which may be used throughout the site. The alternative is to create a fieldset with individual fields, all of which would only be used in a single template and have one entry per field.

You could just use ->parent twice: $parent = $page->parent; $grandparent = $parent->parent;

It is something I have used a little bit when the alternative would be too many additional fields created in the list that are just taking up space. Say if I have a set of fields that I know are only going to be used in a single field group, it makes sense for me to store those in a combo field because I never plan on calling them independently. For example, if I have a product, odds are good I may pull the product title in a number of different contexts, and perhaps prices and variants - so I'll set up normal fields for those. But things like manufacturer, dimensions, weight, checkbox features, warranty length, UPN etc. are things it doesn't necessarily make sense to have a separate field for because outside of the context of recalling a particular item/page, those fields are never referred. I see it as the difference between having a sort of 'local' field group where everything is 1:1 and bound to view together, vs a 'global' field where I may want to include it of view in it context with other templates, other indices, other tags, etc. That being said, I have also run into situations where I have a value that originally is in a combo field, but then we discover that we want to actually build that piece of information out into a separate template entity - so it is most valuable when you plan ahead. Things like testimonial entries, product reviews, these each have multiple fields, but honestly, they could each be put on a card and stored away - there is no real value that any single field in the group has independent from the card - indeed, sometimes having the information in separate places can sometimes make the information more confusing and less valuable.