Leaderboard

Relative to ProcessWire 3.0.182, today's version (3.0.183) contains about 30 commits and resolves 23 issues. It also contains various small tweaks and improvements throughout. For example, when editing the title of a page, it updates the headline as you type in the page editor (in Uikit and Reno admin themes). I think we've got another 1-2 weeks of these kinds of updates (resolving issues and minor improvements) before we release the next master version, and am currently thinking that version will carry version number 3.0.184. I'm also continuing work here on the page snapshots module I wrote about earlier, but am going to wait releasing it until the next master version is complete. If you have a chance to test out ProcessWire 3.0.183 on the dev branch, please let us know how it works for you, and especially if you run into any issues. Thanks for being here and have a great weekend!

You have to first get the "itinerary" array as a variable distinct from the $session->itinerary overloaded property, modify it as needed, and then set it back to $session->itinerary. if(isset($_GET[$key])){ $itinerary = $session->itinerary; if(is_array($itinerary)) { // destroy a single element of an array unset($itinerary[$key]); $session->itinerary = $itinerary; $session->redirect($page->url); } }

$wire->addHookAfter('InputfieldPage::getSelectablePages', function (HookEvent $event) { if ($event->object->hasField->name === 'category') { // Server path to the PW installation $path = '/home/modules/www/'; // The root URL for the PW installation $url = 'http://modules.processwire.com/'; // Create a new ProcessWire instance $site = new ProcessWire($path, $url); // Find some pages $items = $site->pages->find("template=categories, limit=5, sort=-created"); $event->return = $items; } }); https://processwire.com/api/ref/inputfield-page/get-selectable-pages/ https://processwire.com/blog/posts/multi-instance-pw3/

I developed the new Geffen Playhouse website over the course of 2018/2019 and launched it in September 2019. It has been perhaps the largest project I have been involved in. The Geffen Playhouse went through an entire re-branding done by Base (including a custom font), and I worked with Teak on the new website. Website https://www.geffenplayhouse.org/ Wikipedia https://en.wikipedia.org/wiki/Geffen_Playhouse Base write-up https://www.basedesign.com/work/geffen-playhouse-always-geffen-playhouse-always-new Teak SF write-up https://teaksf.com/work/geffen-playhouse-ticketing-ecommerce-website-design/ Another write-up: https://www.laurentakayama.com/geffen Their previous website was severely antiquated and it wasn't a responsive website (as of 2019!). Instead, it forwarded mobile users to a "mobile-friendly" website on a different subdomain, which I think was hosted by a third party service. However the data containing all the actors, shows, seasons, news and press articles were all in there. So one major aspect of this website was de-duping and importing their data into ProcessWire, along with some post-import cleaning… that's ~25 years of data. The site is built with UIkit 3 for the most part, and also uses FullCalendar for the large and small calendars. There is a custom integration with AudienceView, their ticketing system, which is used to import all the performance showtimes of their shows into ProcessWire. It's not the easiest API to work with (XML), but I eventually got it working. Repeater Matrix is being heavily used for section-based page building. Building out all the necessary matrix types took a long time as there was quite a bit of thinking what types and layouts we needed as we went along. However the end result has given the editors a lot of flexibility. ProCache is being used as well, including a CDN for all assets. This is crucial because when opening season sales are announced, the site gets slammed, but with caching turned on, it's not a problem anymore. On a deeper level, the site uses my new (well 2 years old now), universal and very opinionated base module that provides a menu builder, a standard set of fields/templates/pages, and a bunch of other tweaks that I tend to use on every site. All the fields, templates and pages are set up in a streamlined and editor friendly way. I wasn't able to access their previous CMS backend for various reasons (I only got the MySQL dump), so when developing the site and data model in ProcessWire, I was able to completely re-envision the editor experience and the data model without bias. A quote from one of the marketing directors at Geffen Playhouse: "We absolutely love ProcessWire." More details on my personal website: https://jonathanlahijani.com/projects/geffen-playhouse/

@Robin S you are my hero! It works perfectly.

Dailymotion is French, you could give it a try.

Thanks @teppo Didn't look close enough in the select list to see all available files.

You have several possibilities depending on whether you are looping through items or whether you just needed a single item from your items. Here are examples of both scenarios. Inside a loop <div> <!-- getGridItems here is a function that returns the current grid items --> <template x-for="(item, index) in getGridItems"> <!-- bind id to item id and its text to item state --> <span :id='item.id' x-text='item.state' :key="index"></span> </template> </div> Get One Item Several possibilities here: // use filter and since expecting only one item, get it at the first array index const myItem = items.filter((item) => item.id === itemId)[0]; // loop let myItem; for (const item of items) { if (item.id === itemId) { // you have found your item myItem = item; // break out of your loop break; } } // find const myItem = items.find((item) => item.id === itemId); // do some sanity checks here before using myItem For more on loops and iteration, have a look at the Mozilla docs. Depending on the app you are building, you might want to keep a caniuse tab open ?. I see that you are storing tagName (div, etc), meaning you are creating elements on the fly? You can use vanilla JS for this or depending on the number of element possibilities (div, span, ...n), you could use a number of x-ifs. Note, though, that there is no x-else in Alpine. The flatter an object, usually the easier your work. However, sometimes this is not always possible. To access nested data, again, you have several options. You could create a function that returns the object property you want. You can also use either of brackets or dot notation (myItem.breakpoints.base.css.color). However these can get messy if the nesting is very deep. Maybe you could flatten the breakpoints object since really, it is all mainly CSS? It would make it easier to bind styles to an element.

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!

Thanks! Looking forward for to see the video. I am sure that just looking at the list of available sections/components and Mystique configs can give me a lot of inspiration. And that part about automatic fields setup sounds magical. Is that base module or some of its parts open to read the code? Sorry, got too exited))

I'll make a video of this in the near future but here's the extremely short version of the page builder journey I went on. There are 2 approaches that ultimately make sense: section-based and component-based Section Based: This is the "intended" way repeater matrix (and similar fieldtypes in other CMSes -- WordPress ACF has flexible content, Craft has Matrix) is supposed to be used. Each matrix-type represents a section with the necessary fields to populate that section. No depth. Pros easy for editors to understand they just need to put in the content and it will work; no need to worry about layout because it's baked in; hard to mess up Cons not flexible / requires a lot of discussion to make sure all sections, fields and their variations are covered can't move content from one section to another can lead to field bloat Component Based: Each matrix-type represents a component (headline, text, image, video, description list, etc.). Furthermore, 4 additional matrix-types for layout: section, container, row, column. Depth is enabled as well as the new "family friendly" option which I pushed Ryan to implement earlier this year and makes this approach more usable. Pros extremely flexible; closely follows YOOtheme Pro's approach but in a matrix-way can move content anywhere Cons higher learning curve compared to section-based since layout and nesting is involved structures must be repeated over and over again since each component is independent uses many more pages behind the scenes -- Which approach is better? The answer is it depends on the nature of the content of the site and the technical ability of editors. If the site has a level of consistency from page to page, the section-based approach would work better. However if there is less consistency and/or the editors need and/or are willing to put in extra effort to build truly unique pages, then the component-based approach makes sense. The thing is, you can actually use both approaches. The matrix field name for the section-based approach that I use is called 'sections' and the component-based approach field name is called 'builder'. My base module sets up these fields automatically and uses Mystique for all the settings. You can add both the 'sections' and 'builder' fields to a template and the editors can decide which one makes more sense given a page's needs.

Great job and write-up @Jonathan Lahijani! Could you expand a bit on the RM based content builder? Maybe even post some screenshots or even videos, if that is allowed by the customer. We had a great conversation about content builders in the beginning of the year. And you are a named expert in the field, so would love to read/see/watch anything more detailed from you.

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.

I was fighting same issue once. Four hours to understand that I forget to install php-zip ^_^.

Unexpectedly found a half day to spare, so I've pushed 0.0.3 to GitHub. New features: Field settings for custom date, date+time and text fields can now be made on the inputfield's input tab, e.g. date and time formats, placeholder text or text validatoin patterns (numeric field settings are on the todo list) Names for custom fields are limited to start and end with ASCII letters and only have alphanumeric ASCII characters and hyphens in between Custom field name of "data" is silently stripped to avoid bollixing up all entries The custom fields table in the backend is now sorted by name (new entries simply get appended) The module is still alpha. Things are getting smoother, but there are still a few items on the todo list.

Awesome site! You create some of the most beautiful ProcessWire-powered sites I've seen.