Leaderboard

This week we have 12 new commits to the dev branch largely focused on resolving older issue reports. Since the focus right now is primarily on getting the next master version live, we'll likely keep this focus for the next week or two, making sure the next big release version strikes the best balance between new features, issue resolutions and timeliness. Thanks for being here and have a great weekend!

Sorry for interrupting the usual programm and topic here but... @franciccio-ITALIANO maybe you want to look up a mentor/tutor here that helps you to maintain and build ProcessWire sites from either the ground up or even to maintain already built sites. I know you from your past questions, requests and and posts in several other topics. As much as I want to see someone helping you... the more I think you need someone that's guiding you from the basics of PHP to the basics and fundamentals of ProcessWire to the state you can work out ProcessWire sites from each and every state and upwards. So... my questions for our awesome community is... who can help and assist @franciccio-ITALIANO to get to a state where he is able to maintain a basic ProcessWire-website? Native italian speakers (is this even the correct way to write this?) go ahead... and let us know. If there is noone who can assist... let me know @franciccio-ITALIANO... I'll put time aside to guide and assist you in some kind but in english. ;)

Then Alpine JS it is ?. Learn Vue, say thanks to the creators then say hello to Alpine JS. You will write its code right inside your ProcessWire inputfields, markup, whatever. Everything will be reactive. Make use of Inputfields->attr to assign Alpine properties. You might need the full attribute, e.g. 'x-on:change' instead of @change as ProcessWire might strip the latter out. Below is a quick example. I haven't checked it for errors. Inside your ProcessWire code. <?php // get a ProcessWire inputfield wrapper $wrapper = new InputfieldWrapper(); // get an inputfield text to store a name $field = $this->modules->get('InputfieldText'); // add some usual field values $field->name = 'your_name'; // OR // $field->attr('name', 'your_name') // etc... // let's alpinejs-it! $field->attr([ // MODEL THE VALUE DIRECTLY IN THE STORE // 'x-model' => "\$store.mystore.person.name", // OR HANDLE THE CHANGE YOURSELF // @note: ProcessWire will strip out the '@' - so we use x-on:event instead 'x-on:change' => "handleNameChange",// this is a method inside your Alpine data code ]); // IF YOU NEED TO.... // set a wrapper-level class, e.g., as a show-if // @note we escape some things here, e.g. the $ // could also use JavaScript template literals for the 'some_text', e.g. `some_text` // here we add a hidden class to the wrapper depending on some store value // we could have used x-show or x-if instead $class = "{ hidden: \$store.mystore.some_text==\"some_text\"}"; $field->wrapAttr( 'x-bind:class', $class, ); $wrapper->add($field); // initialise alpine js data // 'persons' could also be an object here, but for more complex objects, better to assign to a function in your code like this $out = "<div x-data='persons'>" . $wrapper->render() . "</div>"; return $out; You JavaScript // ALPINE (version 3+) document.addEventListener("alpine:init", () => { Alpine.store("mystore", { // YOUR STORE FIELDS // for some results results: [], some_text: "some_text", is_modal_open: false, person: {}, }) Alpine.data("persons", () => ({ handleNameChange(event) { this.changeCustomerName(event.target.value) }, changeCustomerName(name) { this.$store.mystore.person.name = name } })) }) Hope this helps.

Nice! Thanks for the suggestion. Alpine looks great. I will definitely check out vue und alpine. There is a lot of new stuff to learn, working mainly with jquery in the past. This might also be a little to late for my pagebuilder module Iam currently working on (almost done, it's written in jQuery und uses the change event on the inputfields). However refactoring that, might be a nice way to learn about these reactive js frameworks ?

If you go the Vue route, the easier way is to let it create the inputs but also assign usual ProcessWire classes to them, which then, would be picked up by ProcessWire styling when rendered. However, you will need the full house of markup including the wrappers somewhere wrapping the Vue-generated inputs. Otherwise, some ProcessWire styles might not be applied. Some label inputs might not appear, etc. Better to use Alpine if you can.

One is in the works....still in my head though...as I clear my in-tray first! (you know what I'm talking about ?). Yes and yes. If you are using Vue 2, there is a post somewhere in the forums (@elabx, help please, thanks) with a copy-amend-paste code from WP. That code will enable live reload in ProcessWire backend but view will still need to be running on some other port, e.g. 3000. However, you won't have to keep an eye on that as you will be viewing the changes in the ProcessWire backend. I have since adopted Vue 3 and Vite and the live reload in ProcessWire is as simple as this: <?php // e.g., in execute() if developing a Process Module $out = " // 3000 is the port vite is running at $out .= ' <script type="module" src="http://localhost:3000/@vite/client"></script> <script type="module" src="http://localhost:3000/src/main.js"></script>'; //return $out; if in a method/function Vite does not use Webpack. So, no (crazy) Webpack configs needed! The live reload just works! Having said that, I highly recommend Alpine JS (as a Vue alternative, if you can get away with it) and HTMX (no Axios, no JSON!). With either, no build is required! You keep your DOM and work right inside ProcessWire. Future tutorials in the works, as well ?. If you understand Vue then you already understand Alpine JS. If not, I still suggest you get to know the basics of Vue anyway. Hope this helps.

@kongondo I would love to try vue for module development, but have trouble getting it to work. A tutorial would be highly appreciated! A vue module boilerplate would be nice ? I just started experimenting with vue, it looks very promising! Would it still be possible to run the module from within PW (when developing)? From what I understand vue uses it's own development server?

I prefer wireIncludeFile because of these points described by Ryan in his blog post: The foo variable is just an own variable you can pass and use in the included file. This way you can keep track where you added variables. Of course Markup Regions are also awesome and I like to combine Markup Regions with wireIncludeFile. I use Markup Regions for the whole blueprint of the templates and wireIncludeFile to split up large junks of code. Occasionally I use field templates for repeating fields markup. ProcessWire offers many ways to structure your code if you want to. ?

You can achieve this with hooks to Page::addable and Page::editable. 1. Define access controls for the news-region and news-article templates so that users with the news-editor role can add children under news-region pages and they can edit and create news-article pages. 2. Create a news_regions Page Reference field which allows pages with template news-region. Best to make it a "multiple" AsmSelect field so it covers the potential case that a user needs to add/edit within multiple regions. Add this field to the user template. 3. Edit the news-editor users and set the regions they are allowed to add/edit within. 4. In /site/ready.php: $wire->addHookAfter('Page::addable', function(HookEvent $event) { /** @var Page $page */ $page = $event->object; $user = $event->wire()->user; // Return early if PW has already determined that the user is not allowed to add if(!$event->return) return; if($user->hasRole('news-editor') && $page->template == 'news-region') { // Addability depends on if the news_regions Page Reference field has the page $event->return = $user->news_regions->has($page); } }); $wire->addHookAfter('Page::editable', function(HookEvent $event) { /** @var Page $page */ $page = $event->object; $user = $event->wire()->user; // Return early if PW has already determined that the user is not allowed to edit if(!$event->return) return; if($user->hasRole('news-editor') && $page->template == 'news-article') { // Editability depends on if the news_regions Page Reference field has the parent page $event->return = $user->news_regions->has($page->parent); } }); The result for user "ringo": You could add all the regions to that user's page, but personally I would create a different news-supereditor role and just not make them subject to the restrictions in the hooks.

Aha! The tut I intend to write will explain what all those options do (although the WordPress tut has some good explanations as well).

Thank you for this module! It works great but I have some problems with the options not getting recognised. (Iam using the dev version, because of the geocoding issues with google maps) Since I use the map as a fullscreen background I need to disable the zoom on scroll feature for usability. The option for the marker are working but the leaflet options scrollWheelZoom and dragging are ignored. This is my code: $map = $modules->get('MarkupLeafletMap'); $options = array('markerIcon' => 'flag', 'markerColour' => 'red', 'scrollWheelZoom' => false, 'dragging' => false); echo $map->render($page, 'map', $options); another option would be to disable this after init with map.scrollWheelZoom.disable() But this is also not working, because map is not defined. Whats the name of the map instance in js?