Leaderboard

Here’s a brief update on what’s new in the core since last week. Next week I’m going to compile a more complete overview of everything that’s in 3.0.154 (and more) and put it in a blog post. I wanted to do that today, but my kids have needed a lot of help with various things today (and this whole week actually) with all of this online school stuff and I’ve run out of time. We're a few weeks in and school is cancelled for the rest of the year due to the coronavirus (likely the same around the world). I'm still learning how to adapt to kids around all day and needing attention, but overall it's nice to have the family around more even if it is sometimes hard to get work done. So I’ll keep this sort of brief, and get into more details next week. Several updates were made to the core/LanguageFunctions.php (language functions) file, with biggest being the option to programmatically replace translation text (whether multi-language support is installed or not), useful for very easily updating core/module output to say exactly what you want, and without needing to install multi-language modules. No longer do you need to use various hooks to change text in one module or another. Also moved the __('text') configuration options to dedicated functions which makes it more clear to use, as well as much better for documentation purposes: wireLangEntityEncode(), wireLangTranslations(), wireLangReplacements(). You'll see these new functions in our docs by next week. More details and examples of these in action in next week’s blog post. The CKEditor version has been upgraded from 4.12.1 to 4.14.0. To see what’s changed, see the release notes for CKEditor 4.13.0, 4.13.1 and 4.14.0 here. There’s actually quite a lot here in terms of additions and fixes. Note especially the two security related fixes in 4.14.0 (though I think only the first may be applicable to us). While it looks like a rather unlikely combination of factors needs to come together, and with just the right person, it’s good to be aware of nevertheless. Of note is that these particular cases are entirely client side, before PW ever gets to see or filter the content, so this is something that only a CKEditor upgrade can fix. Updated the core Debug class to use PHP 7.3’s recommended hrtime (high resolution time) for debug timers, rather than microtome. This is only available in PHP 7.3 and newer. As far as I can tell it produces identical results to microtome (as far is our timers go) but the PHP documentation page indicates hrtime is what we should now be using, so that’s what we’re going with. I also did a little refactoring and minor improvements in the Debug class as well. Updated ProcessWire’s Inputfield rendering system so that you can customize markup by matching a field by name, and without hooks. This essentially takes part the Inputfield customization system developed for LoginRegisterPro and brings it into the core. This opens up a lot more customizability for those that want it. Various resolutions of GitHub issue reports, with more on the way. The above are just updates from the last week, but there’s plenty more in 3.0.154 as well. See ProcessWire Weekly #309 for details on Image and file field updates, new $database->columnExists() method and new Selectors::getOperators() method, and more. There are also the new expanded file and image properties, as discussed in #308 and the last blog post. Thanks for reading and I hope you all have a great weekend!

I think custom database tables and SQL queries would be the way to go. This is a good read on working with hierarchies in MySQL: http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql/

How to add a new method with a hook. So if you take your that code from Pagefiles->findTag(): /** * Return all Pagefile objects that do NOT have the given tag(s). * * Given tag may be any of the following: * * - `foo` (single tag): Will return all Pagefile objects not having the specified tag. * - `foo|bar|baz` (multiple OR tags): Will return Pagefile objects having not having ANY of the tags listed. * - `foo,bar,baz` (multiple AND tags): Will return Pagefile objects having NONE of the tags listed. * - `['foo','bar','baz']` (multiple AND tags array): Same as above but can be specified as an array. * * @param string|array $tag * @return Pagefiles New Pagefiles array with items that didn't match the given tag(s). * @see Pagefiles::getTag(), Pagefile::hasTag(), Pagefile::tags() * */ wire()->addHook('Pagefiles::excludeTag', function (HookEvent $event) { $pagefiles = $event->object; //the Pagefiles object. For every instance of $this from the original code we will use $pagefiles instead. $tag = $event->arguments(0); //the argument passed to the method. so it will be e.g. $images->excludeTag($tag) $items = $pagefiles->makeNew(); foreach($pagefiles as $pagefile) { if(!$pagefile->hasTag($tag)) //the only real change is introducing this exclamation mark to negate the condition $items->add($pagefile); } $event->return = $items; }); Now because we just negate the result of $pagefile->hasTag(), we need to be aware of the inverted logic. If you pass multiple tags it should act the way I described in the comment above, which is just Ryan's comment inverted. So if you pass 'foo,bar,baz', you may still get images tagged as 'foo'. (i haven't tested any of this. i may have done it completely wrong.) Edit: Apologies, I did indeed do it wrong. Fixed the code above. @Andi

@kixe, I feel that the settings "Maximum number of backups" and "Remove backups older than" should only apply to backups created by CronjobDatabaseBackup. If the user has made manual backups, or backups have been made by a different module, then CronjobDatabaseBackup should never delete those backups. What do you think?

If I got this right, you could sort of achieve the Admin view part of this with Listers and some custom code, or perhaps ListerPro out of the box, though that would mean that such content is no longer managed in any sort of tree structure (yet, at the same time, it would still actually exist in the tree). The latter part could then be half resolved by hiding the page from the tree with a hook that hides such pages from the tree, but it still wouldn't change the fact that in ProcessWire pages always exist in a singular tree. If I understand you both correctly this is what I'm doing with RockFinder2 + RockGrid / RockTabulator. It's far from perfect yet, but it's built for managing content in a non-hierarchical way which is a very common need IMHO. I don't like listers for that purpose at all. They are limited, they are ugly (*personal opinion!* taking too much space etc), they are hard to customize (like colorizations etc), they are not reacting fast to user input. Of course, there are good reasons why they work as they work: Scalability, access control, multilanguage. These are all points that are challenges for my modules. But in all my projects the benefits of having structured grids of data that are nicely designed, compact and "reactive" (like when filtering columns etc.) outweigh the cons. Not saying my modules are the way to go or better than what you describe. Just wanted to share what is already there and how I'm using it.

Modules Manager 2 provides an easy to use interface to download, update, install, uninstall and configure modules. It is meant to provide an optimized alternative to the core ProcessModule dashboard. Maybe @ryan agrees to merge it to the core at some point when it is finished and polished. Features: Seamlessly download, update, install, uninstall or delete modules Live-Search (aka find as you type) for module names Live-Search (aka find as you type) for categories Browse new and unkown modules from the modules directory on modules.processwire.com Choose your favorite layout (cards, reduced cards, table) Modern UIKit design (therefore only works with AdminThemeUikit) Caches the module list from modules.processwire.com directory locally. What is Modules Manager 2? Why a new module manager? Some people including myself think that the actual module installation in ProcessWire could be improved in some places. Make it easy for ProcessWire beginners and power users Offer better discoverbility to find the right module Make it easier and faster for powerusers to manage modules A manager that list all official modules is a feature, that many other frameworks/CMS's like ModX, WordPress or PrestaShop have by default. What are the disadvantages of the actual core module interface? Installation of a module is not very user-friendly: You have to be aware where to get new modules, search for a module, copy or remember the module name or URL, go back to your ProcessWire installation, paste the module name(URL, click on "get module info" and finally install the module It only displays installed modules, not the ones that are available in the modules directory Uninstalling a module requires you to go to the module detail page, click a checkbox and then submit the change. After that you have to go back to the module overview page. It only displays installed modules, not the ones that are available in the modules directory, so it makes discovering modules hard BETA software Use this module at your own risk. I am not responsible for any damage or unexpected behaviour. Some things might not work fully, please see the TODO list for details. I need your feedback and help This module is still in development and I am happy to discuss with you and get some feedback. What do you like? What is missing? What could make the process even easier? Ask, suggest or provide pull requests. You can download the module at https://modules.processwire.com/modules/modules-manager2/ or from Github: https://github.com/jmartsch/processwire-modules-manager2

Hey folks! I'm happy to finally introduce a project I've been working on for quite a while now: it's called Wireframe, and it is an output framework for ProcessWire. Note that I'm posting this in the module development area, maily because this project is still in rather early stage. I've built a couple of sites with it myself, and parts of the codebase have been powering some pretty big and complex sites for many years now, but this should still be considered a soft launch ? -- Long story short, Wireframe is a module that provides the "backbone" for building sites (and apps) with ProcessWire using an MVC (or perhaps MVVM... one of those three or four letter acronyms anyway) inspired methodology. You could say that it's an output strategy, but I prefer the term "output framework", since in my mind the word "strategy" means something less tangible. A way of doing things, rather than a tool that actually does things. Wireframe (the module) provides a basic implementation for some familiar MVC concepts, such as Controllers and a View layer – the latter of which consists of layouts, partials, and template-specific views. There's no "model" layer, since in this context ProcessWire is the model. As a module Wireframe is actually quite simple – not even nearly the biggest one I've built – but there's still quite a bit of stuff to "get", so I've put together a demo & documentation site for it at https://wireframe-framework.com/. In addition to the core module, I'm also working on a couple of site profiles based on it. My current idea is actually to keep the module very light-weight, and implement most of the "opinionated" stuff in site profiles and/or companion modules. For an example MarkupMenu (which I released a while ago) was developed as one of those "companion modules" when I needed a menu module to use on the site profiles. Currently there are two public site profiles based on Wireframe: site-wireframe-docs is the demo&docs site mentioned above, just with placeholder content replaced with placeholder content. It's not a particularly complex site, but I believe it's still a pretty nice way to dig into the Wireframe module. site-wireframe-boilerplate is a boilerplate (or starter) site profile based on the docs site. This is still very much a work in progress, but essentially I'm trying to build a flexible yet full-featured starter profile you can just grab and start building upon. There will be a proper build process for resources, it will include most of the basic features one tends to need from site to site, etc. -- Requirements and getting started: Wireframe can be installed just like any ProcessWire module. Just clone or download it to your site/modules/ directory and install. It doesn't, though, do a whole lot of stuff on itself – please check out the documentation site for a step-by-step guide on setting up the directory structure, adding the "bootstrap file", etc. You may find it easier to install one of the site profiles mentioned above, but note that this process involves the use of Composer. In the case of the site profiles you can install ProcessWire as usual and download or clone the site profile directory into your setup, but after that you should run "composer install" to get all the dependencies – including the Wireframe module – in place. Hard requirements for Wireframe are ProcessWire 3.0.112 and PHP 7.1+. The codebase is authored with current PHP versions in mind, and while running it on 7.0 may be possible, anything below that definitely won't work. A feature I added just today to the Wireframe module is that in case ProcessWire has write access to your site/templates/ directory, you can use the module settings screen to create the expected directories automatically. Currently that's all, and the module won't – for an example – create Controllers or layouts for you, so you should check out the site profiles for examples on these. (I'm probably going to include some additional helper features in the near future.) -- This project is loosely based on an earlier project called pw-mvc, i.e. the main concepts (such as Controllers and the View layer) are very similar. That being said, Wireframe is a major upgrade in terms of both functionality and architecture: namespaces and autoloader support are now baked in, the codebase requires PHP 7, Controllers are classes extending \Wireframe\Controller (instead of regular "flat" PHP files), implementation based on a module instead of a collection of drop-in files, etc. While Wireframe is indeed still in a relatively early stage (0.3.0 was launched today, in case version numbers matter) for the most part I'm happy with the way it works, and likely won't change it too drastically anytime soon – so feel free to give it a try, and if you do, please let me know how it went. I will continue building upon this project, and I am also constantly working on various side projects, such as the site profiles and a few unannounced helper modules. I should probably add that while Wireframe is not hard to use, it is more geared towards those interested in "software development" type methodology. With future updates to the module, the site profiles, and the docs I hope to lower the learning curve, but certain level of "developer focus" will remain. Although of course the optimal outcome would be if I could use this project to lure more folks towards that end of the spectrum... ? -- Please let me know what you think – and thanks in advance!

It took me weeks to adapt mentally. I'm not sure why, I work from home and my wife looks after the kids at the moment so I'm in a better position than many, but the whole situation in the wider world made me lose my work mojo for a while. Definitely got it back this past week though - back on track finally with projects ? Hope everyone here is as well as they can be in the circumstances.

Yes @adrian that did the trick ? everything back to normal ?

@EyeDentify - please make sure you have the latest version - this was fixed yesterday, or at least it was fixed at my end. It was a new bug the was a result of storing to the filesystem which was added a few days ago.

There‘s the Same question here ?

Hey again, following @bernhard's suggestion of making stuff a little more readable, and after some refactoring, here's the result: In templates/admin.php // user custom theme warning in backend $this->addHookAfter('Process::execute', function($event) { // make stuff more readable $user = $this->wire('user'); // early exit if user is not logged in if(!$user->isLoggedin()) return; // array of themes that will be excluded $x = array('', 'default'); // early exit if current user theme is in excluded array if(in_array($user->custom_theme->value, $x)) return; // set up message $u = $user->name; $t = $user->custom_theme->title; // set up path for profile link $p = $this->wire('config')->urls->admin . "profile"; // send message $this->wire->warning("Frontend wird für Benutzer \"$u\" aktuell mit dem Theme \"$t\" ausgegeben. <small>Einstellung \"Frontend Theme\"im <a href=\"$p\">Benutzer-Profil</a></small>", Notice::allowMarkup); }); Also added an array of values to be excluded to make this more reusable in the future. Looking neat, working as expected. Thanks again and servus from Bavaria!

Yes, I'm well aware that it is completely valid to have inputs and such outside of a form element and with email address EMO breaks the markup but I thought this was not the issue in your case since there was already previous post from creativejay about problems with FormBuilder and you also mentioned that EMO shoudn't touch values of form elements but you were literally talking about inputs and such, not the form element itself. Sorry about that. There are also another technically valid situations where EMO fails e.g. like having an email inside data attribute. Generally it is kind of compicated topic to automatically replace email address by new node in every possible case without breaking things. Anyway, current state where EMO skips whole content inside form element is not ideal since there are many cases where you can have email addresses inside form where they should get obfuscated but currenly are not. Like the one in my previous form example where email inside p element should be touched but it's not. That said maybe we should remove the form element completely from ignored elements and concentrate only at form elements (what you suggested actually) like input, option and textarea where most likely touching email addresses will give us headaches. I'll look into it.

Edit the page 'admin' and give it a new 'name' (in the page's Settings tab). Note that immediately you save you will get a 404 since the URL will still point to /processwire/. Just change that to the new name you gave admin and you are good to go.

Yep ? Or get one.com to fix it, or change to a decent host ?

This is interesting! Full disclosure: on a few occasions I've considered adding a separate model layer to Wireframe, but I've never found a proper reason, i.e. I couldn't think of anything I can't do without it — or even anything it would make notably easier or more effective or more organised — and I'm trying not to add features just because they'd be fun to implement. That being said, I'm always on the lookout for interesting new stuff to add, as long as it adds real value to the framework ? I think when you say "model" you probably mean something a little different than what it means to me personally. In my mind models are tied to data structure, have very little to do with routing, and so on. In fact from what I could gather from your examples it looks like such models would indeed be a lot like custom post types in WordPress in that they'd be located in a single "bucket" and define a per-model route that's separate from the regular page tree structure. If that's the case, wouldn't one variation of that just require creating a parent page on the root level and then subpages below that? Or, for more complex routes, you could make the parent page render its subpages based on URL segments. All the building blocks are already there, though obviously this one needs quite a bit more work — you have to define the routes programmatically, for one. Any chance you could flesh your idea out a little more: What would you use this sort of thing for? How would you envision defining the routes? How would this be different from existing options, such as placing a parent page under root and then subpages using specific template under that, or using URL segments — i.e. would the biggest benefit be some abstract method of defining routes? WordPress templates are a bit different in that they're about representing data, while ProcessWire templates are obviously all about structuring data. Wireframe, for an example, has concepts called "layout" and "view", which are largely in line with WordPress' templates: each template can have multiple views, and each of those views can then be used to render pages in different ways, and/or for different purposes (JSON, RSS, HTML, etc.) Long story short: I'm intrigued, but not entirely sure of all aspects that this concept would bring to the table. Definitely interested in hearing more though!

@bernhard Do you sleep sometimes?

I have started to familiarize myself with the codebase and later on I will take a closer look at all the issues mentioned here and at GitHub. I am not planning to update nor fork the module in any way though, I am thinking of refactoring it completely, and in the end release it under a new name. The first version of this "new" module should be "compatible" with MarkupActivityLog, meaing it is going to rely on the very same database table in the very same manner. However, this first version should tackle the most important issues and it will be PW 3+ and PHP 7.1+ only. Also, being refactored, it is going to use more up-to-date PW features under the hood. In short, I will be working on a successor module to MarkupActivityLog. Note: there is no time-frame for this project at the moment ?

I have kind of the same website like you about turtles. https://chrysemys.nl I have a mix of parent/child pages and page references. Alle depending on the specific needs. If a fish could change owner or change aquarium, I would use page reference. User can change this themselves, otherwise you would need to give them too much permissions. I have the taxonomy for turtles. order -> sub order -> family -> species. This is a parent/child tree as these a vast routes that are always the same for a turtle. The same goes for the country or origin: region -> country. Page reference can also be bidirectional. This is very usefull! If you have books on your site you can reference to the fish in that book. In the admin you will see on the fish page all books and on the book page all fish. If you add a new book and select a few fish, that book is also added to those fish in the admin fish page. That way you can make an amazing flexible website To be honest it took me a while to figure it all out. I used to have all page references but later changes some part to parent/child. This because it would make it less possible to make mistakes. For example, I added some countries to a turtle but also referenced the wrong region. Therefor that turtle would appear on wrong pages. Using the parent/child for this made it more dummy proof

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f Just saying.

Seems like a great idea -- I just now added it in the latest commit. Now it should support the "sort=template".

For a field that can contain multiple images, the value of that field is always going to be a type of array. So you'd have to either check to see if there are any items in the array, or try to retrieve the first time like Soma did. Here's how I usually check if there are any images: if(count($page->images)) { // images here } else { // no images } When it comes to a single image field, you are dealing with just one item that is either set or it isn't (rather than an array). You only need to check if it has a value: if($page->image) { // image here } else { // no image } When you use $pages->find(), $pages->get(), $page->children(), etc., you can also find pages that have a given amount of images. So if you wanted to find pages that don't have any images, you could do this: $pages->find("images.count=0"); ...or pages that have one or more images: $pages->find("images.count>0");