Leaderboard

Work continues on the new processwire.com website, while the core received several updates including support for Markup Regions "pw-optional" attributes, upgrades to WireArray that make it a lot more useful, and more. https://processwire.com/blog/posts/processwire-3.0.117-core-updates/

The page tree can actually be zero clicks or hovers away... there's an option in AdminThemeUikit to show the page tree in the sidebar. https://processwire.com/blog/posts/uikit-3-admin-theme-updates/

If anybody might wonder. This is how to setup permissions for a sub-page of a processmodule: As easy as adding the permission to the nav item! If you want the permission to be created/deleted on module install/uninstall you also have to add it in the "permissions" array: $info = [ 'title' => 'ProcessProjects', 'summary' => 'ProcessModule to manage all Projects', 'version' => 1, 'author' => 'Bernhard Baumrock, baumrock.com', 'icon' => 'thumbs-up', 'permission' => 'projects', 'permissions' => [ 'projects' => 'Run the Projects Management Module', 'aggregate' => 'Create Aggregated Reports', ], 'page' => [ 'name' => 'projects', 'title' => __('Projekte'), ], 'nav' => [ [ 'url' => '', 'label' => __('Projekte'), ],[ 'url' => 'mails', 'label' => __('E-Mails verwalten'), ],[ 'url' => 'reports', 'label' => __('Berichte verwalten'), ],[ 'url' => 'aggregate', 'label' => __('Aggregierten Bericht erstellen'), 'permission' => 'aggregate', ], ], ]; Make sure to logout/login, otherwise you won't see the changes in the menu! If you call the ProcessModule's page directly you will instantly get the result of the changed permissions: Whereas in the menu it is still there until you logout+login: @szabesz you asked for that in the blog comments...

Those are some sweet updates Ryan! Seeing as you've been working on transferring the blog posts over to the new processwire.com site, do you think you could add a feature so that blog posts automatically get anchors on every <h3>? There could be an automatic table of contents from those anchors if you think that would be good, but having anchors is the main thing. Because there is so much useful documentation of features within the blog I often want to save references to specific sections within a blog post, or provide a link to a section in a forum reply. Having heading anchors would make it possible to do this.

I'm still fairly new here having switched to using ProcessWire for pretty much every project (hence the frequent questions ? ) from Concrete5. Concrete5 has had Gutenberg-esque block-based front-end editing for nearly 10 years longer than Wordpress. Although a finished site using C5 can look great for a site editor/frontend-only user with various drag-drop layout tools, we were finding c5 development had become very convoluted and was starting to make simple website projects unnecessarily complicated. C5's core weighs in at a hefty filesize too. This is why we started researching for alternatives and landed happily at ProcessWire. I already find WP development unnecessarily convoluted, especially compared to the simplicity of ProcessWire. And with Gutenberg, I can only foresee the same sort of headaches ahead for the WP community that we were finding with C5 - namely conflicts between blocks and the core and frontend UI and your design style and functionality being dictated to by the CMS in order to work in the Gutenberg features. Discovering ProcessWire has been a revelation for us - the clean API and design agnostic approach are making everything from simple website projects to complex web apps a breeze, with the added bonus of super simple frontend editing that not only wows client's used to site builder platforms but requires basically zero onboarding too. I would urge anyone thinking of building out Gutenberg inspired modules for ProcessWire to consider the above comments to ensure that what makes ProcessWire special is retained.

"Now WireArray can be used on its own with just about any data type. No longer is this base class limited to working with just Wire-derived objects." I've been longing for this for quite a while. Sometimes dreams come true ? Thank you Ryan!

It should be even more straight forward: <p><?= $page->one_liner_group->getRandom()->one_liner ?></p> The value of a repeater field is a RepeaterPageArray, which is just a slightly extended PageArray. Edit: @Soma beat me by a few seconds ?

$page->one_liner_group->getRandom();

It both depends on how a server environment is setup. Especially if the PHP running user has write access to these files and directories. So, if you already know that the PHP user has no write access, you can do this before you start the installation process. If you don't know this, you can run the installation process and PW will tell you about the situation and guide you through the manually needed tasks. (Namly: select your drsired site profile or rename it to "site", delete the unused profiles, and also delete the install.php file after finished the process".

Here is the snippet <?php $intro = $pages->get('/intro/'); foreach($intro->images as $image) { $image = $image->size(500, 350); $lines = $image->description; $words = explode(",", $lines); echo "<div class=" . '"da-slide"' . ">" . "\n"; echo "<h2>" . $words[0] . "</h2>" . "\n"; echo "<p>" . $words[1] . "</p>" . "\n"; echo "<a href=" . '"#"' . " class=" . '"da-link"' .">" . $words[2] . "</a>" . "\n"; echo "<div class=" . '"da-img"' . ">" . "<img src=" . '"' . $image->url . '"' . " alt=" . '""' . ">" . "</div>" . "\n"; echo "</div>" . "\n"; } ?> In my above example I used php explode for a title, a paragraph and links, but as you see it, you will get the idea. Simply add your alt description as a second word in your image description field and use php explode to echo it inside alt=" . . . " Your image description field will then look like this: image description, alt description, other description, . . . . . Use a comma as a separator

Thanks for sharing this. This is something I've heard before too while giving training. I guess the Explorer / Finder kinda sidebar gives people more comfortable feeling. Especially at first sight. Usually within the first session they understand the page tree and the need for the tree in the sidebar. Jup, I've heard this too. This is where ProDrafts comes in. Or one the versioning modules by @teppo. For clients hidden / unpublished isn't always obvious and I believe the need ProDrafts in your base install to give people a comfortable way of to create content. This is a paid module. The funny thing is that while I've heard all your points come up regularly, I have never heard the term messy. All clients find the CMS very clean, focused, easy to navigate since the page tree reflects there website structure. Most say the need to unlearn other experiences like WordPress with the Custom Post Types or Joomla.

Updated ACF to make it compatible. (Hope this fixes it.)

Hi folks, I have a simple(?) question, followed by a slightly lengthy background explanation: Is it a good idea—in terms of scalability and frontend performance—to use a Repeater Matrix or PageTable field to build modular content blocks? And here is the background explanation: I’m quite obsessed with the idea of using modular blocks to build the content of a page. Each type of element (e. g. images, videos, quotes, code examples, but also more complex elements like image galleries, promotion boxes for products or events) gets its own set of input fields, encapsulated in a container. The page’s content—or certain parts of it—are then built by stacking containers of different element types. Using such content blocks allows all kinds of pre-processing happening behind the scenes. By now I implemented modular content blocks in one ProcessWire instance, using a Repeater Matrix field. This works great but comes along with some serious performance issues. Let’s ignore the backend-related performance issues. They can be solved by either not opening all Repeater items or by building a solution using a PageTable field and the PageTableExtended module instead of Repeater Matrix. Regarding the frontend: I noticed that it’s pretty much unusable without activated cache. No surprise. This article page, for example, consists of 30 different content blocks—plus some more page references for author, category, article series, etc. Without activated cache, the loading time is simply unacceptable. The PHP object with all its sub-objects must be quite big, which explains the slow server response. With activated cache, the pages load pretty fast (letting aside the external cookie banner which is an experiment), due to the performance optimization features I built into the content block templates. But there is more than just article pages: What about list pages? What about the XML sitemap which in my case iterates over all content blocks of all pages to include information about all images and embedded videos? The blog where I use the Repeater Matrix content block solution is still very small (because I haven’t had the time to write articles). But what happens when such a website gets bigger? Think of a website with 150 pages, each consisting of 20 content blocks. Let’s stick to the XML sitemap example: ProcessWire would have to iterate over 3150 pages in total to render the output. This wouldn’t happen too often because the output can be saved—using the built-in cache or ProCache. But it needs to be done on a regular basis. That’s why my question: Is it a good idea to build modular content blocks like this with ProcessWire? Does caching do the trick in the frontend? Or are there some hidden strings attached when a project scales? Is there perhaps a better solution than using a Repeater Matrix or PageTable field? Of course, I could turn to other CMSs which use such content blocks as part of their core concept: the PHP-based Neos or the Node.js-based ApostropheCMS , for example. (Even the plain old TYPO3 uses content blocks, but I would never voluntarily use TYPO3 if I can avoid it.) But those are far more complex to set up, implement and maintain, so I’d really like to stick to ProcessWire.

I'm integrating FoxyCart SSO at the moment, I want to make it so when someone registers using ProcessWire it also registers them for the Store. To do this I have to set FoxyCart up to use the same encrypting method as ProcessWire. I know it uses a hash and a salt. But I was wondering if anyone has done this before? I'm struggling to utilise the ProcessWire API to pass FoxyCart the hash and salt for a particular user.

Hello @Michael van Laar, To answer you main question first: Yes, I don't see a performance issue in using either. The RepeaterMatrix and PageTable field are similar in that they use pages which can be used for content elements. I prefer the RepeaterMatrix field, because it has a better usability in that you can edit the content elements on the same page. Before there was the RepeaterMatrix field, I also used for a few times the PageTable field with the PageTableExtend module. But if you have bought the ProFields I would recommend using the RepeaterMatrix. On the back-end it is best when using a RepeaterMatrix field to have the default option on, that all repeater items should be loaded via Ajax. I assume the page you linked is not cached? According to WebPagetest the document was loaded after 670ms, which is good (best would be under 300ms). Everything after that are your styles and scripts which are not related to the RepeaterMatrix. For a regular XML sitemap, you would just output all visible pages on your website. So in your example that would be around 150 pages. But even more should be no issue. I usually use the module MarkupSitemapXML for this. With other sitemap formats I have not much experience, I have just learned about them: Image sitemap: You could output the link of a page and all it files like this. Video sitemap: This seems to work only with self hosted videos. So not embeded videos. But I could be done like mentioned before. All of those solutions mentioned are decoupled from the RepeaterMatrix and PageTable field. On every page you only output the content elements used for the page. So the total count of content elements wouldn't matter. If you have a page with 10 or 50 content elements, it should not really be a performance issue. I can think of no use case, where you would output all content elements of all pages at the same time. As mentioned before the sitemap example can be handled without have to deal with RepeaterMatrix or PageTable. Yes, thats what the RepeaterMatrix field is build for. Caching always helps if you don't have user input on your page. But depending on how you build your templates, without cache there should be no performance issue. For content elements I can't think of a better solution than RepeaterMatrix. If you have more questions, it would be best if you would share some screenshots of your set-up. ? Regards, Andreas

Depending on what's supported processwire does use different stragegies to hash passwords: https://github.com/processwire/processwire/blob/master/wire/core/Password.php#L347-L386

Just a note if anybody gets in trouble when creating complex PDFs... It seems that there is some bug related to the tempdir that is created for the pdf. If the PDF takes long to render it can happen that this folder is deleted automatically before the PDF is done. Then you'll get an error. In my case this solved it: $pdf = $modules->get('RockPdf'); $pdf->settings([ 'tempDir' => $this->config->paths->root . 'site/assets/cache/WireTempDir/.RockPdf/test/', ]); For sure just a quickfix, but I'm busy...

Thanks Pwired I will look into this.

Created this MR https://gitlab.com/baumrock/kickstart/merge_requests/1 so weirdos like me can use kickstart.php?skiplint and the config parameter skipcompat. Other stuff: Maybe there could be a 'httpHosts' in the example kickstartfile, to show the \n and a comment emphasising that you have to use double-quotes for them to work? The function timezones() in install.php gets the tz list with PHP's timezone_identifiers_list and adds some extras. It would seem to me that the number and ordering of this data might change at any point in history, so it feels a bit awkward to rely on the IDs we happen to get at present. On the other hand, the current solution using CURLOPT_POSTFIELDS to pass stuff to install.php is simple and getting the tz IDs by parsing the select option texts would add a gymnastic extra step.

Yes you can There is a module for this somewhere that extends the images field functions. But the easiest and fastest way is to use the Processwire api together with the php explode function for this. I have a snippet for this somewhere but cannot find it right now. I will post back when I find it.

also depends on the type/scope of the site – in a vast majority of websites, the page tree is probably irrelevant, esp. when editing a page. But UiKit Admin Theme the page tree is a mouse hover away. Most sites i build now the users interact only with a custom dashboard and listers.

Please help to bump this issue in github. I think this bug is quite critical. https://github.com/processwire/processwire-issues/issues/724 Gideon

I have not seen SilverStripe's backend since version 3.0 but that version was really centered around intuitive page and content management, so I guess it is still solid at doing so. Drafts and page content versioning of SilverStripe has always been built-in, and that's the only thing I really miss in PW. ProcessWire has this covered with a commercial module, but still... I prefer ProcessWire to SilverStripe because of two things: PW does not introduce breaking changes between mayor versions while SS does because of refactoring how things work. Also, PW does not require a template language while SS relies on its own implementation. Anyone can add a popular templating engine to ProcessWire if one wants to.

I include the Tag Manager script normally. You can create a trigger in the Tag Manager which react on every change in the url. The trigger is included in the Tag which creates a Google Analytics Pageview. This works perfect and is easy to configure. Here is a screenshot from the Tag Manager (The UI is on german):

I kept running into the issue of self-invalidating access tokens and wanted the site's content editors to be able to handle the generation of new access tokens themselves. The module, however, limits those functions to superusers. Could you change the module to check for the module-admin permission? It's ProcessWire's internal permission to check who can edit module configurations. It's deactivated by default and has to be created and assigned manually, so there's no additional risk or security concern. On a standard PW installation, it still only applies to superusers. However, it gives people the possibility to allow editors to generate access tokens. So instead of if ($this->user->isSuperuser()) { $href = self::API_URL_AUTHORIZE . '?' . http_build_query($request); $link = "<a href='$href'>" . __('get Access Token') . "</a>"; } it's if ($this->user->isSuperuser() || $this->user->hasPermission('module-admin')) { $href = self::API_URL_AUTHORIZE . '?' . http_build_query($request); $link = "<a href='$href'>" . __('get Access Token') . "</a>"; } (There's a second check somewhere further down). Thanks for considering this. I forked the module for now, but would much rather like this to be incorporated into master.

UX wise the best would probably be opening the folder after some time hovering over it.

Agree. @tpr maybe an idea for AOS to add some hints to the tree when moving items around? I have no specific idea yet ?

Since PW >= 3.0.105 you can easily use the following hook. $wire->addHookBefore('InputfieldSelect::render', function($e) { if ($e->object->name != 'myfield') return; // quick exit if fieldname doesn't match $restrictedIDs = array(); // array of option values to be modified, page IDs in case of pagefield $optionAttributes = array_fill_keys($restrictedIDs, array('disabled' => 'disabled')); $e->object->addOptionAttributes($optionAttributes); }); Related commit: https://github.com/processwire/processwire/commit/07ab8ef9fcefff6a97c688599fb08fb0d462332e#diff-79808b1661a74c0668ee6157537ae478R390

snippet mania continues ? "Add hook with separate method": { "prefix": "hook", "body": [ "\\$this->wire->addHook$1('$2', \\$this, '$3');$0", "/**", " * $4", " */", "public function $3(HookEvent \\$event) {", " $5", "}", ], "description": "Add hook with separate method" }, "Add hook with closure": { "prefix": "hook", "body": [ "\\$this->wire->addHook$1('$2', function(HookEvent \\$event) {", " $0", "});", ], "description": "Add hook with closure" },

Did you logout/login the client user?

Make sure to "open" the new parent page before moving stuff there. It needs to be highlighted to receive a page as child no matter if there are already children or not.