Leaderboard

This week I was back to focusing on the core and got quite a lot done. A lot of GitHub issue reports were resolved, plus several minor tweaks and additions were made in 3.0.156 as well. But the biggest update was the addition of the $pages->parents() API, which is something that I think you’ll likely have zero use for (and why I’m not putting it into a blog post) but something that the core itself will use quite a bit, and is a really nice improvement for the system and its scalability. So if you don’t mind some technical reading, read on. Whenever you call a $page->find() method ($page, not $pages) or use a “has_parent=“ in a selector, ProcessWire joins in a special table for the purpose called pages_parents. It uses this table to keep track of family relationships that aren’t otherwise apparent. For instance, let’s say we have page “g” that lives at path /a/b/c/d/e/f/g/. Page “g” only knows that it has page “f” as its parent. It doesn’t know that page “e” is its grandparent unless or until page “f” is loaded. Once “f” is loaded, then “f” can reveal its parent “e”. It works the same for every relationship down to the root parent “a”. So the pages are like a linked list or blockchain of sorts, where only 1 relationship forward or backward is known per page. The “pages_parents” table fills in this gap, enabling PW to quickly identify these relationships without having to load all the pages in the family. This is particularly useful in performing find() operations that you want to limit to a branch started by a particular parent. It’s the reason why we have both $pages->find() that searches the entire site, and $page->find() that limits the search within the branch started by $page. I haven’t paid much attention to the code behind this pages_parents table because it generally just worked, needing little attention. But I came across a couple of cases where the data in the table wasn’t fully accurate with the page tree, without a clear reason why. Then I became aware of one large scale case from a PW user where it was a huge bottleneck. It involved a large site (250k+ pages) and a recursive clone operation that appeared to involve hundreds of pages. But that operation was taking an unreasonable 10 minutes, so something wasn’t right. It came down to something going on with the pages_parents table. Once I dove into trying to figure out what was going on, I realized that if I was to have any chance of keeping track of it, we needed a dedicated API for managing these relationships and the table that keeps track of them. So that’s what got a lot of attention this week. While still testing here, it does appear initially that the 10 minute clone time has gone down to a few seconds, and everything about this relationship management is now rewritten, optimized and significantly improved. It was a lot of work, but absolutely worth it for PW. Rebuilding the entire table from scratch now takes between 2-3 seconds on a site with 250k pages and 150k relationships. The new API can be accessed from $pages->parents(). This API is really useful to the work that I do here (maintaining the core) but I’ll be honest, it’s probably not useful to most others, so I won’t go into the details here, other than to say I’m happy with it. But if you are interested, there are methods finding all the parents in a site, or a particular branch, and methods for rebuilding the pages_parents table, among others. Maybe more will be added to it later that actually would be useful in the public API, but for now I’ll likely leave it out of our public API docs. The $sanitizer->selectorValue() method also got a full rewrite this week (actually, one the last few weeks). It’s now quite a bit more comprehensive and configurable (see the new method options). The previous version was just fine, and actually still remains — you can use it by specifying [ ‘version’ => 1 ] in the $options argument to the selectorValue() method. But the new version is coded better and covers more edge cases, plus provides a lot more configurability for the times when you need it.

I've seen a couple of questions regarding namespaces and autoloading floating around the forum recently, so I decided to write a little tutorial. In general, I often see people getting confused when they try to wrap their head around namespaces, autoloading, Composer and the mapping of namespaces to directory structures all at once. In fact, those are very much independent, distinct concepts, and it is much easier to explain and understand them separately. So this guide is structured as follows: How namespaces work in PHP. How autoloading works in PHP. Conventions for mapping namespaces to directory structures: PSR-4. How autoloading works in Composer and ProcessWire's class loader. How to use the class loader in a ProcessWire module. Feel free to skip the sections you're already familiar with. Namespaces in PHP The purpose of namespaces in PHP is to avoid naming conflicts between classes, functions and constants, especially when you're using external libraries and frameworks. Nothing more. It's important to understand that this has nothing at all to do with autoloading, directory structures or file names. You can put namespaced stuff everywhere you want. You can even have multiple namespaces inside a single file (don't try this at home). Namespaces only exist to be able to use a generic name – for example, ProcessWire's Config class – multiple times in different contexts without getting a naming conflict. Without namespaces, I couldn't use any library that includes a Config class of it's own, because that name is already taken. With namespaces, you can have a distinction between the classes ProcessWire\Config and MoritzLost\Config. You can also use sub-namespaces to further segregate your code into logical groups. For example, I can have two classes MoritzLost\Frontend\Config and MoritzLost\Backend\Config– a class name only needs to be unique within it's namespace. You can declare the namespace for a PHP file using the namespace statement at the top: // file-one.php <?php namespace ProcessWire; // file-two.php <?php namespace MoritzLost\Frontend; This way, all classes, methods and constants defined inside this file are placed in that namespace. All ProcessWire classes live in the ProcessWire namespace. Now to use one of those classes – for example, to instantiate it – you have a couple of options. You can either use it's fully qualified class name or import it into the current namespace. Also, if you are inside a namespaced file, any reference to a class is relative to that namespace. Unless it starts with a backward slash, in this case it's relative to the global namespace. So all of those examples are equivalent: // example-one.php <?php namespace ProcessWire; $page = new Page(); // example-two.php <?php use ProcessWire\Page; $page = new Page(); // example-three.php <?php $page = new ProcessWire\Page(); // example-four.php <?php namespace MoritzLost\Somewhere\Over\The\Rainbow; $page = new \ProcessWire\Page(); The use statement in the second example can be read like this: “Inside this file, all references to Page refer to the class \ProcessWire\Page” How autoloading works Every PHP program starts with one entry file – for ProcessWire, that's usually it's index.php. But you don't want to keep all your code in one file, that would get out of hand quickly. Once you start to split your code into several individual files however, you have to take care of manually including them with require or include calls. That becomes very tedious as well. The purpose of autoloading is to be able to add new code in new files without having to import them manually. This, again, has nothing to do with namespaces, not even something with file locations. Autoloading is a pretty simple concept: If you try to use a class that hasn't been loaded yet, PHP calls upon it's registered autoloaders as a last-ditch attempt to load them before throwing an exception. Let's look at a simple example: // classes.php <?php class A { /** class stuff */ } class B { /** class stuff */ } // index.php <?php spl_autoload_register(function ($class) { include_once 'classes.php'; }); new A(); new B(); This is a complete and functional autoloader. If you don't believe me, go ahead and save those two files (classes.php and index.php) and run the index.php with php -f index.php. Then comment out the include_once call and run it again, then you'll get an error that class A was not found. Now here's what happens when index.php is executed (with the autoloader active): Our anonymous function is added to the autoload queue through spl_autoload_register. PHP tries to instantiate class A, but can't because it's not loaded yet. If there was no autoloader registered, the program would die with a fatal error at this point. But since there is an autoloader ... The autoloader is called. Our autoloader includes classes.php with the class definition. That was a close one! Since the class has been loaded, execution goes back to the index.php which can now proceed to instantiate A and B. If the class was still not loaded at this point, PHP would go back to the original plan and die. One thing to note is that the autoloader will only be called once in this example. That's because both A and B are in the same file and that file is included during the first call to the autoloader. Autoloading works on files, not on classes! The important takeaway is that PHP doesn't know if the autoloader knows where to find the class it asks for or, if there are multiple autoloader, which one can load it. PHP just calls each registered autoloader in turn and checks if the class has been loaded after each one. If the class still isn't loaded after the last autoloader is done, it's error time. What the autoloader actually does is pretty much wild wild west as well. It takes the name of the class PHP is trying to load as an argument, but it doesn't have to do anything with it. Our autoloader ignores it entirely. Instead, it just includes classes.php and says to itself “My job here is done”. If class A was in another file, it wouldn't have worked. This process has two main advantages: Since autoloaders are only called on-demand to load classes just in time, we only include the files we actually need. If in the example above class A and B are not used in some scenarios, the classes.php will not be included, which will result in better performance for larger projects (though this isn't as cut and dry, since autoloading has it's own overhead, so if you load most classes anyway during a single request, it will actually be less efficient). If the autoloader is smart enough to somehow map class names to the files they're located in, we can just let the autoloader handle including the classes we need, without having to worry about jamming include statements everywhere. That brings us to ... PSR-4, namespaces and directory structures As you see, namespaces and autoloading are both pretty limited concepts. And they aren't inherently linked to each other. You can namespace your classes without ever adding an autoloader, and you can autoload classes that are all in the same namespace. But they become useful when you put them together. At the core of all that autoloading talk is a simple idea: By putting classes in files named after their class names, and putting those files in directory hierarchies based on the namespace hierarchy, the autoloader can efficiently find and load those files based on the namespace. All it needs is a list of root namespaces with their corresponding directories. The exact way class names and namespaces are mapped to directory structures and file names is purely conventional. The accepted convention for this is PSR-4. This is a super simple standard which basically just sums up the ideas above: A base namespace is mapped to a specific directory in the file system. When the autoloader is asked to load a class in that namespace (or a sub-namespace of it), it starts looking in that folder. This "base" namespace may include multiple parts – for example, I could use MoritzLost\MyAwesomeLibrary as a base and map that to my source directory. PSR-4 calls this a "namespace prefix". Each sub-namespace corresponds to a sub-directory. So by looking at the namespace, you can follow subdirectories to the location where you expect to find the class file. Finally, the class name is mapped directly to the file name. So MyCoolClass needs to be put inside MyCoolClass.php. This all sounds simple and straightforward - and it absolutely is! It's only once you mash everything together, mix up language features, accepted conventions and proprietary implementations like Composer on top that it becomes hard to grasp in one go. Composer and ProcessWire's class loader Now all that's left is to talk about how Composer and ProcessWire provide autoloading. Composer, of course, is primarily a tool for dependency management. But because most libraries use namespaces and most developers want to have the libraries they're using autoloaded, those topics become a prerequisite to understanding what Composer does in this regard. Composer can use different autoloading mechanisms; for example, you can just give it a static list of files to include for every request, or use the older PSR-0 standard. But most modern libraries use PSR-4 to autoload classes. So all Composer needs to function is a mapping of namespace prefixes to directories. Each library maintains this mapping for it's PSR-4-structured classes through the autoload information in their composer.json. You can do this for your own site to: Just include the autoload information as shown in the documentation and point it to the directory of your class files. Composer collects all that information and uses it to generate a custom file at vendor/autoload.php — that's the one you need to include somewhere whenever you set up Composer in one of your projects. Bells and whistles aside, this file just registers an autoloader function that will use all the information collected from your own and your included libraries' composer.json to locate and include class files on demand. You can read more about how to optimize Composer's autoloader for production usage here. If you want to read up on how to set up Composer for your own sites, read my ProcessWire + Composer integration guide instead. And finally, what does ProcessWire do to handle all this? Turns out, ProcessWire has it's own autoloader implementation that is more or less PSR-4 compliant. You can access it as an API variable ($classLoader or wire('classLoader'), depending on context). Instead of using a static configuration file like Composer, the namespace -> directory mapping is added during the runtime by calling $classLoader->addNamespace. As you would expect, this function accepts a namespace and a directory path. You can use this to register your own custom namespaces. Alternatively, if you have site-specific classes within the ProcessWire namespace, you can just add their location to the class loader using the same method: $classLoader->addNamespace('ProcessWire', '/path/to/your/classes/'). Utilizing custom namespaces and autoloading in ProcessWire modules Now as a final remark, I wanted to give an example of how to use custom namespaces and the class loader in your own modules. I'll use my TrelloWire module as an example: Decide what namespace you're going to use. The main module file should live in the ProcessWire namespace, but if you have other classes in your module, they can and should use a custom namespace to avoid collisions with other modules. TrelloWire uses ProcessWire\TrelloWire, but you can also use something outside the ProcessWire namespace. You need to make sure to add the namespace to the class loader as early as possible. If either you or a user of your module tries to instantiate one of your custom classes before that, it will fail. Good places to start are the constructor of your main module file, or their init or ready methods. Here's a complete example. The module uses only one custom namespaced class: ProcessWire\TrelloWire\TrelloWireApi, located in the src/ directory of the module. But with this setup, I can add more classes whenever I need without having to modify anything else. /** * The constructor registers the TrelloWire namespace used by this module. */ public function __construct() { $namespace = 'ProcessWire\\TrelloWire'; $classLoader = $this->wire('classLoader'); if (!$classLoader->hasNamespace($namespace)) { $srcPath = $this->wire('config')->paths->get($this) . 'src/'; $classLoader->addNamespace($namespace, $srcPath); } } Source Thanks for making it through to the very end! I gotta learn to keep those things short. Anyway, I hope this clears up some questions about namespaces and autoloading. Let me know if I got something wrong, and feel free to add your own tips and tricks!

Most of us know and use site/config-dev.php file. If present, it is used instead of site/config.php, so it is easy to set database connection and debug mode for local development, not touching the production config. It is also very useful when working with git. You can simply ignore it in the .gitignore file, so local settings won’t end up in the repo. But sometimes you need to add code to site/ready.php or site/init.php just for the dev environment. For example, to add ryan’s super cool on demand images mirrorer. I can’t live without it when working with big sites, which have more assets then I want to download to my desktop. It would be great if there was something like site/ready-dev.php for this. Not out-of-the-box, but it’s pretty easy to achieve. Unlike site/config-dev.php, site/ready.php is not hardcoded. It’s name is set with a special config setting: // wire/config.php $config->statusFiles = array( 'boot' => '', 'initBefore' => '', 'init' => 'init.php', 'readyBefore' => '', 'ready' => 'ready.php', 'readySite' => '', 'readyAdmin' => '', 'render' => '', 'download' => '', 'finished' => 'finished.php', 'failed' => '', ); As you can see, we can not only define, which files are loaded on init, ready and finished runtime states, but probably even add more if we need to. So we override this setting in site/config-dev.php like this: // site/config-dev.php // Change ready.php to ready-dev.php $temp = $config->statusFiles; $temp['ready'] = 'ready-dev.php'; $config->statusFiles = $temp; For some reason we can’t just do $config->statusFiles['ready'] = 'ready-dev.php'; and have to override the whole array. Maybe you PHP gurus can explain this in the comments. Now we can create the site/ready-dev.php file and place all the dev-only code there. Important thing is to include the main site/ready.php. // site/ready-dev.php include 'ready.php'; // DEV HOOK TO MIRROR ASSETS ON DEMAND $wire->addHookAfter('Pagefile::url, Pagefile::filename', function($event) { $config = $event->wire('config'); $file = $event->return; if($event->method == 'url') { // convert url to disk path $file = $config->paths->root . substr($file, strlen($config->urls->root)); } if(!file_exists($file)) { // download file from source if it doesn't exist here $src = 'https://mysite.com/site/assets/files/'; $url = str_replace($config->paths->files, $src, $file); $http = new WireHttp(); try { $http->download($url, $file); } catch (\Exception $e) { bd($file, "Missing file"); } } }); Do not forget to replace "mysite.com" if you’re copypasting this)) Now, add the newly created file to the `.gitignore` and we’re done. # .gitignore # Ignore dev files site/config-dev.php site/ready-dev.php Thanks for reading!

I have added a new field type to the FieldtypeColor package. It is still in beta, but is already working quite well. The module is an extension of the Core FieldtypeOptions module and offers colors as predefined selectable options via 4 different input field types (Select, SelectMultiple, Checkboxes and Radios). Please try it out and if you like it, recommend it in the modules directory ? 2 Screenshots

Have a look at this: Or if you'd like to buy me coffee, have a look at this ?

For a gallery of images you wouldn't want to insert the images separately into the CKEditor field. You'd want to loop over all the images in the field and output markup for each of them. A typical approach would be to show thumbnail images linked to larger images that display in a JS lightbox (I like to use Fresco), so your template code might look like this (assumes your images field is named "images"): <?php if($page->images->count): ?> <div class="gallery"> <?php foreach($page->images as $image): ?> <a href="<?= $image->maxSize(1000,1000)->url ?>" class="fresco" data-fresco-caption="<?= $image->description ?>"> <img src="<?= $image->size(300,300)->url ?>" alt="<?= $image->description ?>"> </a> <?php endforeach; ?> </div> <?php endif; ?> So the simplest scenario is if your blog text and gallery are separate from each other - e.g. the gallery appears before or after the text. This way you just output the gallery and text separately in your template file. Chances are that's what you want to do, but here are a couple of other scenarios and possible solutions... 1. You want to optionally insert one gallery somewhere within the blog text. In other words, you want some text, followed by the gallery, followed by some more text. One way to do this would be to have two CKEditor fields in your template, labelled "Before gallery" and "After gallery". You divide your text between these two fields. The two CKEditor fields and the images field are all output directly by code in your template file. Another way is to have a single CKEditor field use the Hanna Code module to insert the gallery somewhere in the text. You would create a PHP Hanna tag named "gallery" and use the gallery code shown above for the tag. Then you'd insert [[gallery]] in your CKEditor field wherever you want the gallery to appear. 2. You want to insert multiple galleries somewhere within the blog text. If you stump up some $$ to buy the excellent ProFields module you could use the included Repeater Matrix module to create separate matrix types for Text and Gallery. Then you just add alternating Text and Gallery items to the page as needed to build up the blog post content. Another approach for this that is a bit more advanced but that doesn't cost anything is to use a standard Repeater field for the galleries. You would add an Images field and the Title field to the Repeater field and create a Repeater item for each gallery on the page. Then you'd use Hanna Code to insert the galleries within a single CKEditor field. And to make it easier to select a gallery in the Hanna tag you can use the Hanna Code Dialog module. The "gallery" Hanna tag would have a "title" attribute and the code would look like this: <?php $repeater_item = $page->galleries->findOne("title=$title"); ?> <?php if($repeater_item->id): ?> <div class="gallery"> <?php foreach($repeater_item->images as $image): ?> <a href="<?= $image->maxSize(1000,1000)->url ?>" class="fresco" data-fresco-caption="<?= $image->description ?>"> <img src="<?= $image->size(300,300)->url ?>" alt="<?= $image->description ?>"> </a> <?php endforeach; ?> </div> <?php endif; ?> And the Hanna Code Dialog hook in /site/ready.php to build the dialog form would look like this: $wire->addHookAfter('HannaCodeDialog::buildForm', function(HookEvent $event) { // The Hanna tag that is being opened in the dialog $tag_name = $event->arguments(0); // The page open in Page Edit /* @var Page $edited_page */ $edited_page = $event->arguments(1); // The form rendered in the dialog /* @var InputfieldForm $form */ $form = $event->return; if($tag_name === 'gallery') { $modules = $event->wire('modules'); $gallery_titles = $edited_page->galleries->explode('title'); /* @var InputfieldSelect $f */ $f = $modules->InputfieldSelect; $f->name = 'title'; $f->id = 'title'; $f->label = 'Gallery title'; $f->addOptions($gallery_titles, false); $form->add($f); } }); And this would give you an interface in Page Edit that looks like this (when the Hanna Code dialog is open):

Developing custom fields for ProcessWire is great! And it's easier than many might think once you get the basic concepts. But it's hard to learn those concepts by reading the code and doing some trial and error... That's why I think we need a good tutorial about that topic. It took me quite long, but now I feel knowledgeable enough to write such a tutorial. I also have the idea (or the need) for some new fields that might be helpful to the community. What I don't have is time ? So I thought to share the workload and share my knowledge while the development of the module (and testing, writing docs, etc) could be done by someone else under my supervision (hope that does not sound scary ? ). What do you think? I'm happy to hear your opinions - we are in the PUB ? Have a great week and happy coding!

Hi Ivan, very nice tip. I haven't known about this. May come in handy. Thank you for sharing. ? Regarding your question on overwriting single items of config arrays, you can do it this way: $config->statusFiles('ready', 'ready-dev.php'); Also, if I want to overwrite more then one item, I prefer this way: $config->statusFiles = array_merge($config->statusFiles, [ 'init' => 'init-dev.php', //'readyBefore' => '', 'ready' => 'ready-dev.php', ]);

Great read! Perfectly laid out! A ready Medium article in a post! And maybe it should be published elsewhere, as it provides a lot of useful info not only for PW devs (and would bring some attention to PW).

@MarkE - should be ok to use this, and i wouldn't say that this module is no longer supported, if there were to be a bug report, pull request, or feature request, this module is still live and functioning, and may receive future updates, especially with regards to permissions and flexibility of use. But in the meantime as mentioned above, ProcessDocumentation is a bit of a larger scale module and was designed so that it would be possible to have unlimited documentation pages, all accessible from the top admin menu, as well as the ability to download the PDF; In conjunction with the ContextHelpTemplate, you can achieve the same functionality ad Admin Help, so that you have a tab for help right on the page editor, which can open in the panel (instead of wiretab) if preferred. So in that sense, ProcessDocumentation is an evolution of this module, but doesn't necessarily replace it for simpler use cases. It is also possible that this module, AdminHelp could use updates to support pw panel, or other features of ProcessDocumentation.

Hi, I am working on a site where people can enter iframes which will be saved and displayed to other users. I want to prevent XSS but at the same time I want that any site can be embedded as iframe. I want to prevent something like <iframe src="javascript:alert(0)"></iframe> but it should still be possible to use any src url for the iframe. I know that one can use the sanitizer with htmlpurifier options to only allow safe origins (say youtube, vimeo). echo $sanitizer->purify($str, $options = ["HTML.SafeIframe" =>true, "URI.SafeIframeRegexp" =>'%^https://(www.youtube.com/embed/|player.vimeo.com/video/)%'] ); Is there are smart way to have a minimal level of protection whilst allowing any url for the iframe? Expanding the RegEx in the options obviously works but is this already enough? echo $sanitizer->purify($str, $options = ["HTML.SafeIframe" =>true, "URI.SafeIframeRegexp" =>'%^https://%'] ); Would love to hear some other opinions.

The first selectors would not return unpublished pages. You have to use $pages->find('your-selector, include=unpublished') or include=all instead. The $pages->get() method already includes hidden and unpublished results, as you are explictly requesting pages. Regarding your problem: You want to hook the ProcessPageView::pageNotFound method and modify the output. I made a little proof-of-work module for you. It is a combination of the hooks for pageNotFound and Page::viewable. Maybe there could be a better and easier solution. Install the attached module to test it out. previewOption.module.php

As far I can see you handle only the array version of the get parameter 'level', but not the pipe separated version. I didn't tried it out, please check: if($input->get->level) { if (is_array($input->get->level)) { // Level is an array. Code adapted from Ryan's snippet here: // https://processwire.com/talk/topic/3472-enable-pagination-for-search-results/?tab=comments#comment-38042 $level = array(); foreach($input->get->level as $id) $level[] = (int) $id; // sanitize to INTs $level = implode('|', $level); // convert to 123|456|789 string, ready for selector } else $level = "$input->get->level"; } else { $level = ''; } @flydev ?? ... one second quicker ?

@jacmaes you can simply add a new condition if the the GET var level is a string ? let's try : if($input->get->level && is_array($input->get->level)) { // level as array given $level = array(); foreach($input->get->level as $id) $level[] = (int) $id; // sanitize to INTs $level = implode('|', $level); // convert to 123|456|789 string, ready for selector } elseif($input->get->level && is_string($input->get->level) && $input->get->level !== '') { // level as string given // can be optimized (sanitizer) $level = array(); foreach(explode('|', $input->get->level) as $id) $level[] = (int) $id; // sanitize to INTs $level = implode('|', $level); // convert to 123|456|789 string, ready for selector } else { $level = ''; }

If I remember correctly I think they do something similar on the https://processwire-recipes.com/ site using the code from https://github.com/processwire-recipes/ProcessRecipeInstaller Markdown files are stored in this repo https://github.com/processwire-recipes/Recipes Maybe that can give you some ideas?

@Jorge, Welcome to the forums ? There's 2 - 3 issues here: Every time a page is saved: Easily achieved using ProcessWire Hooks Commit and Push to Github: How are you currently doing this? Are you pushing from the server where you have installed ProcessWire? This is related to #1, basically, what you will do when you call your Hook Automation: Depend on your case this and #2 could be one and the same. Or this could be an independent process, e.g. a cron job triggered by #1 which then calls #2

Thanks for the cheat sheet, @szabesz. And you're code is great inspiration @Pixrael. Here's my code, @elabx, or parts of it. This is the code that gives me correct output. _main.php <?php namespace ProcessWire; ?> <!doctype html> … template stuff <footer pw-id=footer> … more template stuff </footer> </body> </html> some-page-template.php, the relevant code at the bottom: <?php namespace ProcessWire; ?> … template stuff <?php echo "<script data-pw-append=footer src=\"" . $config->urls->templates . "theme/js/showmore.min.js\"></script>"; echo "<script data-pw-append=footer type=\"application/ld+json\">" . json_encode($schema_review) . "</script>"; ?> But if I edit the last part, to <script pw-append=footer… instead of data-pw-append, it will output the scripts before <!doctype html>. That is what I don't get. Reading about the two variations being similar in usage.

We recently relaunched the website of IBIS Backwaren, a brand for international pastries and bakery products. Concept, design and implementation by schwarzdesign, built with ProcessWire. As always, we aimed to deliver a clean website design with a focus on content and fast loading times. Here's a list of modules used on this site, followed by a couple of interesting features included. The site is bilingual, though currently only the German version is available. The English version will be released at a later date. ProFields FormBuilder WireMailSMTP Cache Control MarkupSitemap Hanna Code Automatically link page titles Unique image variations Product database and product collections The website features a product database with all the products IBIS distributes. The product template is rather extensive, including fields for product categories and attributes, nutrition facts, certifications etc. We make heavy use of page reference fields, e.g. for product categories and attributes such as vegan or gluten-free products. Nutrition facts are stored in a Textareas field. There are multiple ways for visitors to explore products. One is a classic product finder with filters for product category and attributes. But there are also individual product collections (Produktwelten) which can be regularly updated by the client. Product collections include a list of related products. This allows the marketing department to quickly set up targeted landing pages. Recipes and custom forms Another approach to marketing and activating fans is the recipe section. Each recipe uses at least one IBIS product to give visitors some ideas. Of course, recipes and products are cross-linked to allow for exploration and discovery. There's a recipe submission form which allows you visitors to send in their own recipes, as well as a couple of other forms. All forms on the site are built with the Form Builder module. We made use of the form submissions to pages feature, which automatically creates a new (unpublished) page for new recipe submissions. Those can be reviewed by the staff and published directly. We also use a hook to automatically transform the plaintext fields for ingredients and instructions into HTML lists. Multi-brand IBIS uses different brands for different sets of products. Some landing pages as well as the gluten-free selection are branded differently. To accomodate this, we create an additional "brand" template with an override for the default logo. Each page has a brand selection field to allow switching the logo / branding for that page. Since brands are represented by normal pages, then client can create additional brands on their own.

Just here to say that I'm the kind of person whom prefer to learn by watching videos, so it would be great if someone could create a series about this topic :)

"Markup Regions pw vs data-pw different behavior" I have not yet experienced such a behavior. Maybe you are mixing up "Boolean action attributes (inner HTML)" with "Action attributes with value (outer HTML)"? Regarding the differences between these two, see my explanation below. +1 Here is my simplified docs for markup regions, we can also call it "cheat sheet". I wrote it some time ago: Defining markup regions Basic region Wrapping tags do appear in the final markup. Children tags are preserved if not explicitly replaced. <div id="hello"> OR <div data-pw-id="hello"> data-pw-... They are removed from the final output and thus not visible to front-end markup, while id="..." is not removed! Placeholder region Only the inner HTML will be used and the wrapping tags won't appear in the final markup. <pw-region id="hello">...</pw-region> Good for groupping tags in the <head> eg.: <pw-region id="site_scripts"> Optional region It will be automatically removed from the document markup if nothing populates it, so it is a region which should be empty by default. <div id='hello' data-pw-optional></div> Examples: an <ul>, which [according to HTML5 specs] is required to have one or more <li> elements within it, otherwise it's invalid HTML. a sidebar which is only needed on pages populated with widgets /* -------------------------------------------------------------------------------------------------- */ Populating markup regions Available action attributes: data-pw-replace: replaces a region’s markup data-pw-append: appends markup to a region data-pw-prepend: prepends markup to a region data-pw-before: inserts markup before a region data-pw-after: inserts markup after a region Boolean action attributes (inner HTML) Only applies the inner HTML to the region. TARGET CODE: <div id='hello'> <h2> Hello World </h2> </div> <p data-pw-id="hello" data-pw-append> This text will APPEND to div#hello </p> <p data-pw-id="hello" data-pw-prepend> This text will PREPEND to div#hello </p> <p data-pw-id="hello" data-pw-before> This will insert this text BEFORE div#hello </p> <p data-pw-id="hello" data-pw-after> This will insert this text AFTER div#hello. </p> RESULTS: This will insert this text BEFORE div#hello <div id='hello'> This text will PREPEND to div#hello <h2> Hello World </h2> This text will APPEND to div#hello </div> This will insert this text AFTER div#hello Action attributes with value (outer HTML) All of the markup that you specify (the outer HTML) becomes part of the final document markup (except for the pw-* attributes): TARGET CODE: <div id='hello'> <h2> Hello World </h2> </div> <p data-pw-append="hello"> This paragraph will APPEND to div#hello </p> <p data-pw-prepend="hello"> This paragraph will PREPEND to div#hello </p> <p data-pw-before="hello"> This will insert this paragraph BEFORE div#hello </p> <p data-pw-after="hello" class="world"> This will insert this paragraph with class "world" AFTER div#hello. </p> RESULTS: <p> This will insert this paragraph BEFORE div#hello </p> <div id='hello'> <p> This paragraph will PREPEND to div#hello </p> <h2> Hello World </h2> <p> This paragraph will APPEND to div#hello </p> </div> <p class="world"> This will insert this paragraph with class "world" AFTER div#hello. </p> /* ------------------------------------------------ ------------------------------------------------ */ Adding HTML attributes Any HTML attribute you add to the action tag that does not begin with pw- or data-pw- will be added to the originally defined region tag. TARGET CODE: <ul id="foo" class="bar"> <li> First item </li> </ul> ACTION CODE: <ul data-pw-append="foo" title="Hello"> <li> Second item </li> </ul> RESULTS: <ul id="foo" class="bar" title="Hello"> <li> First item </li> <li> Second item </li> </ul> Adding and removing classes Classes from the action tag and the region tag are merged by default. To remove a class by the region action: prepend a minus sign to the class to be removed, eg: class="-foo bar" will result in class="bar"

@bernhard I am up for it if you can share the knowledge, I can write an article around it as a tutorial since I tend to write tutorials. Ironically this was part of a series I am creating for Processwire, just video editing skills delaying but writing this as a tutorial shouldn't be a problem. Just let me know what you need me to do, I will create time for this. Take care

Hi @3fingers Yes and no ? I used ProcessWire for some projects as freelancer, but never at my "daily" work. I still believe that ProcessWire is a great open source software and I'm maintaining a couple of private projects. But in my opinion, ProcessWire lacks of some important features (testing, config management, migration handling, command line tools, extensible frontend etc.) and also it is not easy to setup if multiple people are working on the same project. Nowadays I am writing Flutter apps and Javascript. But of course I still come back here to give some support and to see how ProcessWire evolves! ? Cheers

With respect, it's replies like these when people post their sites in the showcase that somewhat annoy me and I think would either be better handled through a private message or just left alone. With a site as complex as the one Ryan posted, how could you possibly know what's best? Sites like these take thousands of hours and go through many iterations. There's a lot of group-think with any "best practice" but in my belief and experience, especially with ecommerce sites, visitors usually don't care. Here's 2 examples: A friend of mine started a Shopify website, which is probably the biggest Shopify website in the world (not an exaggeration). For the first 3 years, his website was nothing "special" and could probably be designed by anyone here in their sleep. A basic logo, simple lines, decent pictures of products. Knee-jerk snarky-developer reaction would be "omg, your website sucks lol bye". But, customers don't care. They want a good deal and he provided that and had great timing. Needless to say, he's probably a billionaire at this point. With one of my own ecommerce websites, I'm not using whatever the latest cutting edge web development practices are (React / all that JS stuff / AJAX everywhere / crazy system infrastructure / etc.). Customers don't care (customers in this case being Fortune 100 companies, even Fortune 1 companies... ? ). They are looking for something specific and will find what they need. Snarky developer reaction: lol bro you should be using technology 'x', a read about it in a blog this week. Do the end customers care? No, they are people looking to buy a product on our website, not judging the behind-the-scenes code. It's easy to fall into this trap of taking whatever latest article you read and thinking you must apply it or you are falling behind / going to lose customers / are a bad developer / whatever. I went through years of this until the above to examples opened my eyes a lot. I would recommend focusing on your customers and what's working for you... not what trends are.

I think the carousel implementation is perfectly done. Well designed, and perfect auto scroll speed. As for the whole site, great job people. As for the link you provided @Beluga, I would respectfully disagree. Running 100s of sites, especially ecommerce, carousels contribute to a massive spike in product sales. Dont read what works for others, implement what works for you.

Beluga, I'm not much into carousels either, but also wouldn't claim there's no place for them. There's 1 small carousel on this entire site, and there was also one on the previous iteration of the site—the client has always liked it, and the customers react well to it. I really like this client for a lot of reasons, but one is that they are much more involved than most, know their technology, their product and their audience better than anyone I've worked with. The carousel is not my idea, but I trust and am certain the client knows their customers better than any self proclaimed experts online. I got a kick out of that linked anti-carousel site because it's a bit of a self own by whoever made it—it uses a carousel to make points that we likely would not have bothered to read if they weren't in a carousel. ?

Thank you everyone! All this info is awesome! This feels like the old days. Anyone remember 4guysFromRolla? 1999 ish... I learned so much from that forum, long before the days of Youtube, Apache and PHP were a nightmare to setup and CGI was king.

@snck Maybe you want take my fork for a spin: https://github.com/JanRomero/AdminPageFieldEditLinks I’ve only done rudimentary tests, but those seemed fine. It just adds a span around the locked inputfield’s value that tells the module’s javascript part what to do. edit: the fork is gone since @thetuningspoon was so kind as to merge the changes. please blame me if I broke anything!

Interesting, on my side for every project, it's : TracyDebugger because coding without it it's like masochism AutocompleteModuleClassName super-man backend module BreadcrumbDropdowns super-man backend module VersionControl for versioning page's content Migrations to keep control between dev and prod sites Duplicator for backups and migrations @JeevanisM you should give a try to the last one ???

Hi @SeriousUser OK, the core ship what's needed FormBuilder again FormBuilder SEOMaestro MediaManager RepeaterMatrix ProCache Backup it with Duplicator ? Thanks, you too ??

Can you post your code for rendering the form. I have the js and css in place but I still only see the name email and message field, never shows the website or stars if I enable them

In my version of this module I have changed so many things that it is almost unrecognizable, but I do see that I added: if($user) to the beginning on line 394 which should fix what you are seeing.

Good morning! AdminBar 2.3.0 was just released. Here's the changelog for this version: ## [2.3.0] - 2019-08-29 ### Added - Gravatar image support for the "user" item in Admin Bar. - Support for sorting Admin Bar items manually with the AsmSelect field in module config. - A changelog file. ### Changed - Protect logout link from accidental clicks (script or otherwise) by converting simple link to a logout form. - When modal window is opened, hide children and view tabs with CSS first in order to prevent flashing content. Due to the manual sorting feature mentioned above there was a change in the data structure, so note that if you're already running AdminBar and have modified the visible items in the bar, you'll need to reconfigure those. This was the easiest way I could figure out to achieve free sorting feature: Minor note: currently it's possible to add the same item to both left and right columns. I didn't see a reason to specifically prevent this, so it's kind of a feature – though not sure if that's something you should ever do from a UI/UX perspective ?

Hey folks! Just released AdminBar 2.2.0. Here's what's new: New module config settings for selecting items displayed in the Admin Bar. New items, disabled/hidden by default: "profile" (simple profile edit link) and "user" (basically the same concept as the profile edit dropdown menu in Admin). If "user" is displayed, there's a config setting for items displayed under it as well. New hookable method ___getData(). The returned array is converted to an object and stored as JSON (data-adminbar) on the Admin Bar element. This was mainly added for future JS features, but can be used by themes etc. as well. Hookable methods and their primary purposes are now also documented in the README.md file. Quite a bit of code was rewritten – again. I've been splitting some methods to smaller ones to improve maintainability, fixing small issues, improving accessibility to some degree (still needs a lot of work though), etc. Hopefully didn't cause too many new problems in the process... ? Here's a screenshot with new items enabled, though one probably wouldn't want to enable profile and user (and all the user dropdown items) at the same time – and yes, my user name on this site is "admin", so it looks a bit silly when there's an "admin" link before and below it as well ? --- Thanks! This will be the next item on my list ?

Hi @DV-JF It's not possible to deactivate the default language in PW. You can create custom inputs (checkboxes) to enable/disable specific language for page and then in your template check whether this page is viewable for this language and if not throw 404. In that way, you will rely on custom inputs for languages, so default language checkboxes should be checked for languages. You can use this hook for that $wire->addHookAfter('Pages::added', function($event) { $page = $event->arguments(0); foreach ($this->wire->languages as $lang) $page->set("status$lang", 1); $page->save(); }); One drawback that I'm thinking about is that in your find() methods you have also check if this page viewable for this language. This is not tested but may work. Also, take a look at this module, you may find it useful in some cases

I think currently the only sane way would be to display a warning in the admin, that dependencies are missing, if the needed classes are not loaded. I mean one can still install those manually without using composer. Composer just makes it a heck of a lot easier.

Hey guys, hey @baba_mmx I just released a new version of this module on github. I also got a question, as I am planning to take this project under my wing: Should I make a new thread for it and add it to the modules directory? @baba_mmx would that be ok with you? One problem is that if I put it in the ProcessWire Modules directory it does not install it dependencies, as they are installed via composer. How could I handle this? What has been done in the latest release? v0.9.1 made the register form public so you can alter the markup and classes added Foundation classes for the errors and notices. Have to make this configurable added new function showMessage to echo messages and errors login user after successful registration removed automatic redirect enabled autocompletion for the form show either displayName from OAuth or email address after login added the ability to save the last name, first name and gender from OAuth in the user profile. Just add the fields "lastName", "firstName" and "gender" to the user template in ProcessWire