Leaderboard

We've just launched our new site, rebranded AND become a B Corp. Phew! (only took us 2 years to do all that...) https://humanafterall.studio/ We're a design agency in London working with tech and purpose organisations. We've used PW on many client projects and on all our own previous websites. For this one, we built with: Processwire 3.0.155 ProCache for speeding everything up Custom Inputfield Dependencies for keeping the back-end in check (thanks @Robin S) Markup regions for templates Bulma as a frontend framework PJAX for page loading Service Worker module for adding a service worker ImageOptim (online) for optimisation of all images (using this PW module) KeyCDN for serving static assets Lazysizes for lazyloading of all images/video Lots of what I worked on was optimising for speed — which can be a challenge for an agency that wants a lot of big imagery. (it's also a PWA so you can install it on your desktop in Chrome and add to homescreen on iOS for fullscreen standalone app view) Anyway it's a culmination of working and developing with PW for a long time, hope you enjoy!

I've been using Fathom Analytics for a while now and on a growing number of sites, so thought it was about time there was a PW module for it. WayFathomAnalytics WayFathomAnalytics is a group of modules which will allow you to view your Fathom Analytics dashboard in the PW admin panel and (optionally) automatically add and configure the tracking code on front-end pages. Links GitHub Readme & documentation Download Zip Modules directory Module settings screenshot What is Fathom Analytics? Fathom Analytics is a simple, privacy-focused website analytics tool for bloggers and businesses. Stop scrolling through pages of reports and collecting gobs of personal data about your visitors, both of which you probably don't need. Fathom is a simple and private website analytics platform that lets you focus on what's important: your business. Privacy focused Fast-loading dashboards, all data is on a single screen Easy to get what you need, no training required Unlimited email reports Private or public dashboard sharing Cookie notices not required (it doesn't use cookies or collect personal data) Displays: top content, top referrers, top goals and more

$format = $modules->get("TextformatterMarkdownExtra"); $format->format($str); echo $str;

When I create a new Hanna Code tag I am always creating a PHP tag (I don't think I've ever had a need to create a text or Javascript tag). And I prefer to edit my tag code in my IDE rather than in the code field within the Hanna Code module. Because of this my Hanna codes always consist of... <?php include $config->paths->templates . "hannas/{$hanna->name}.php"; ...which just includes a file named the same as the Hanna tag from a "hannas" folder in /site/templates/ Always on the lookout for efficiencies, I had a go at automating the process of setting up new Hanna tags and come up with the following. Maybe it's useful to someone. In /site/ready.php: // Pre-fill code for new Hanna tags and create file $wire->addHookBefore('ProcessHannaCode::executeEdit', function(HookEvent $event) { $id = (int) $this->input->get('id'); // Include code for later use $file_include_code = '<?php include $config->paths->templates . "hannas/{$hanna->name}.php";'; if(!$id) { // A new Hanna tag is being added // Set type to PHP $this->addHookBefore('InputfieldRadios(name=hc_type)::render', function(HookEvent $event) { $inputfield = $event->object; $inputfield->value = 2; }); // Set code to include file of same name as tag $this->addHookBefore('InputfieldTextarea(name=hc_code)::render', function(HookEvent $event) use ($file_include_code) { $inputfield = $event->object; $inputfield->value = $file_include_code; }); } else { // An existing Hanna tag is being edited (the new tag has been saved) // Get the data for this tag /* @var \PDOStatement $query */ $query = $this->database->prepare("SELECT name, type, code FROM hanna_code WHERE id=:id"); $query->bindValue(':id', $id); $query->execute(); if(!$query->rowCount()) throw new WireException("Unknown ID"); list($name, $type, $code) = $query->fetch(\PDO::FETCH_NUM); // If it's a PHP tag and the tag code matches the include code... if($type == 2 && $code === $file_include_code) { $filename = $this->config->paths->templates . "hannas/{$name}.php"; // Check if there is an existing file and if not... if(!file_exists($filename)) { // Define the contents of the file // Just the namespace and API variables for IDE code-completion // Some of this is PhpStorm-specific so adjust as needed $contents = '<?php namespace ProcessWire; //<editor-fold desc="API variables"> /** * @var Config $config * @var Fieldgroups $fieldgroups * @var Fields $fields * @var Languages $languages * @var Modules $modules * @var Page $page * @var Pages $pages * @var Paths $urls * @var Permissions $permissions * @var ProcessWire $wire * @var Roles $roles * @var Sanitizer $sanitizer * @var Session $session * @var Templates $templates * @var User $user * @var Users $users * @var WireCache $cache * @var WireDatabasePDO $database * @var WireDateTime $datetime * @var WireFileTools $files * @var WireInput $input * @var WireLog $log * @var WireMail $mail * @var \ProCache $procache * @var \FormBuilder $forms * **/ //</editor-fold> '; // Create a file and insert the contents above file_put_contents($filename, $contents); } } } });

This is the thread for the old version of RockMigrations wich is deprecated now and has been renamed to RockMigrations1 Here is the latest version of RockMigrations: -- Old post from 2019 -- https://github.com/baumrock/RockMigrations1 Quickstart First make sure you have backups of your database!! Install RockMigrations Create this ready.php <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->migrate([ 'fields' => [ 'myfield' => ['type' => 'text'], ], 'templates' => [ 'mytemplate' => [], ], ]); Open your PW Backend and you'll see the new field and new template! Now add the new field to the template: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->migrate([ 'fields' => [ 'myfield' => ['type' => 'text'], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'title', 'myfield', ], ], ], ]); Reload your backend and inspect the template: Now let's add a label for our new field and make title+myfield 50% width: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->migrate([ 'fields' => [ 'myfield' => [ 'type' => 'text', 'label' => 'My Field Label', ], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'title' => ['columnWidth' => 50], 'myfield' => ['columnWidth' => 50], ], ], ], ]); That's all the magic! You can easily lookup all necessary properties in Tracy Debugger: Let us add a Textformatter as an example! Add the textformatter via the PW backend (not via RM), save the field and inspect via Tracy: Now add this data to your migration: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->migrate([ 'fields' => [ 'myfield' => [ 'type' => 'text', 'label' => 'My Field Label', 'textformatters' => [ 'TextformatterEntities', ], ], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'title' => ['columnWidth' => 50], 'myfield' => ['columnWidth' => 50], ], ], ], ]); Ok maybe you noticed that migrations are now running on every request which may slow down your site a lot! RM2 will have a feature to automatically detect changes and fire migrations automatically. RM1 does not have this feature, but I've used a technique in all my projects that fires migrations on every modules refresh. Simply wrap the migration in a fireOnRefresh method call: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->fireOnRefresh(function() use($rm) { $rm->migrate([ 'fields' => [ 'myfield' => [ 'type' => 'text', 'label' => 'My Field Label', 'textformatters' => [ 'TextformatterEntities', ], ], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'title' => ['columnWidth' => 50], 'myfield' => ['columnWidth' => 50], ], ], ], ]); }); How to remove things you created before you may ask? Use the declarative syntax: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->fireOnRefresh(function() use($rm) { $rm->deleteField('myfield'); $rm->deleteTemplate('mytemplate'); }); Refresh your backend and everything is as it was before! PS: Make sure you have proper Intellisense support in your IDE to get instant help:

@MarkE, if you prefer to edit your Hanna code in your IDE you might find this useful:

¡Muchas gracias!

Got this working on your codepen: var accordions = $("[uk-accordion]"); accordions.each(function(index, item){ UIkit.util.on(item, "beforeshow" , function(e){ accordions.not(item).each(function(index, item){ var opened = $(item).children('.uk-open'); var openItemIndex; if(opened.length){ openItemIndex = opened.index(); } if(openItemIndex !== undefined){ UIkit.accordion(item).toggle(openItemIndex); } }); }) });

That's a great-looking and fast site! Nice work :)

Thanks @teppo — it should look good on a decent-sized screen. However on small laptop (768px - 1214px ish) we need to adjust text sizing as at the moment everything feels too big. The play/pause button was my stipulation if I was going to allow an autoplay slideshow ?

So far only seen the site on mobile, but at least from that point of view it looks and feels really good. Especially enjoyed the typography. Great job! Can't wait to get a closer look on desktop ? (The pause/play button on the home page carousel is a nice touch, by the way.)

Isn't that the default behaviour of the accordions? That's what it would seem like from the examples on the page, the component has a "multiple" option that is set by default on false. Maybe you need to update UIkit? EDIT: Just re-read, that it's ANOTHER accordion. I'd try something like this, just wrote it on the fly so there are probably errors, but the idea is to close any other accordions with the component's API, rather than adding/removing classes. var accordions = $('.uk-accordion'); accordions.each(function(index, item){ UIkit.util.on(item, "show" , function(){ accordions.not(item).each(function(index, item){ var opened = $(item).children('.uk-open').index(); UIkit.accordion(item).toggle(index); }) }) })

Very nice module! I've been using it for a few days now and I'm getting more and more excited every day. Once you know how to use everything, working with it is really fun, especially when you create an update for a larger project.

Nice one, thanks! When I saw the post title, being in Tuts, I was expecting one of your long posts ?. This works fine though; simple and to the point!

After forgetting the class name of the wonderful AdminPageFieldEditLinks module for what feels like the 100th time I decided I needed to give my failing memory a helping hand... Autocomplete Module Class Name Provides class name autocomplete suggestions for the "Add Module From Directory" and "Add Module From URL" fields at Modules > New. Requires ProcessWire >= v3.0.16. Screencast Installation Install the Autocomplete Module Class Name module. Configuration Add Module From Directory Choose the type of autocomplete suggestions list: "Module class names from directory" or "Custom list of module class names". The latter could be useful if you regularly install some modules and would prefer a shorter list of autocomplete suggestions. The list of class names in the modules directory is generated when the Autocomplete Module Class Name module is installed. It doesn't update automatically (because the retrieval of the class names is quite slow), but you can use the button underneath when you want to retrieve an updated list of class names from the directory. Add Module From URL If you want to see autocomplete suggestions for the "Add Module From URL" field then enter them in the following format: [autocomplete suggestion] > [module ZIP url] Example: RepeaterImages > https://github.com/Toutouwai/RepeaterImages/archive/master.zip Awesomplete options The "fuzzy search" option uses custom filter and item functions for Awesomplete so that the characters you type just have to exist in the autocomplete suggestion item and occur after preceding matches but do not need to be contiguous. Uncheck this option if you prefer the standard Awesomplete matching. Custom settings for Awesomplete can be entered in the "Awesomplete options" field if needed. See the Awesomplete documentation for more information. https://github.com/Toutouwai/AutocompleteModuleClassName https://modules.processwire.com/modules/autocomplete-module-class-name/

Ok, I'll admit it, even I have a hard time remembering the name of AdminPageFieldEditLinks ? I'm glad it could at least serve as inspiration for this nice enhancement!

I've added support for an "integer" inputfield type in v0.3.3. Technically it was already supported via a HannaCodeDialog::buildForm hook which is the approach I would generally recommend to power users. Once you start going beyond the basics I think it's easier and more powerful to build your dialog forms via that hook.

Hi huseyin, 1. Use the appropriate Sanitizer methods to test user input from post and get. Depending on the circumstance, you'll either want to validate (reject it completely if there's something wrong with it), or filter/sanitize it (accept it but strip out unwanted characters). If doing both filter and validate, do your validation AFTER your filtering. 2. Even more important than step #1 is to use escaping on your output. This means using htmlspecialchars() or htmlentities() or $sanitizer->entities() when you output any field from the database or user input to the page (if you have htmlentities setup on your field's output formatting, then you can skip this step for those fields). Even if you mess up on the filter/validation from #1, as long as you've escaped all of the html, you should be ok. 3. When using user input (get or post variables) inside ProcessWire selector strings, use the Sanitizer::selectorValue() method on the value first. Even better, just use Selector Arrays since selectorValue can sometimes strip out characters (quotes and commas) that you actually want to search for. 4. If you're using any SQL directly, you must use prepared statements to bind any user input, which automatically escapes the input for SQL. 5. For protection against Cross Site Request Forgery (CSRF), use ProcessWire's SessionCSRF class when building custom forms. See https://processwire.com/api/ref/session-c-s-r-f/ for details on how to use this. 6. Don't use GET for secret data (passwords, security codes, etc). That data can get picked up by browser extensions or appear in server logs that might get compromised. 7. Use SSL/https on your whole site.

The thing is, it's a risk that's carried by the site developer rather than the module developer. If an autoload module adds scripts and styles to $config->scripts and $config->styles it's your site that's at risk of breaking, not the module. Personally I'd never want to take that risk. The simple solution is to create your own custom FilenameArray in $config that is reserved for front-end usage. This old post from @Soma explains how:

@Macrura My two cents on this: I feel like it's the other way around — $config as a data store is (for the most part) internal to ProcessWire's backend. The $config->scripts and $config->styles arrays are wired up in a way that makes sense for the admin panel to work properly. Using them for the frontend is surely convenient (I've done that myself on a lot of sites) but probably not meant to be used that way and prone to breaking. I've personally stopped using the internal file arrays for that reason and created namespaced versions for the frontend.

Goodbye jQuery, Hello Slideshow! UIkit 3 Beta 31 released !