Leaderboard

This week we've got a great guest post from Alex Capes. Alex recently worked with design agency Human After All to build a website for Canongate, a leading independent book publisher. This post discusses the highlights, challenges and successes in building this impressive ProcessWire-powered site. I was really impressed with this site, and I think you'll like reading about it. https://processwire.com/blog/posts/building-canongate/ Next week I'm going to be out of town for much of the week so likely won't have a blog post next Friday. If anyone is interested or has ideas for another guest post, please drop me an email. Thanks.

In general I'd say build classes as independent as possible from processwire and to integrate it in PW just add a module as wrapper around your class, which does tie any processwire specifics (hook / module config / process interface / …) into what your class does on it's own.

This feature is amazing. Just installed it and our clients were amazed! I didn't even expect anyone to notice. Thanks a million.

Hi @webaff multilingual about 400 files at launch, scalable up to 10000 files files are typically PDF but can be of other files types front end user login with forgot password function https://modules.processwire.com/modules/frontend-user/ or custom solution nice to have: front end user registration https://modules.processwire.com/modules/frontend-user/ or custom solution 3-5 user roles for access control on page level (each file can be accessible for users of all roles or just for users of certain roles) login history https://modules.processwire.com/modules/process-login-history/ or a custom hook probably for ___loginSuccess files must not be accessible by direct link, of course. Would be nice to store them outside the http-root. https://modules.processwire.com/modules/fieldtype-secure-file/

For that kind of system I'd probably go with laravel spark.

I would prefer module because it's more PW way. It worth to mention that there is WireMail module that handles sending of email in PW. Also, there is WireMail SMTP that extends mentioned class. You can go with a similar approach: create a module that will extend WireMail class by hooks where you can specify some specific things from your custom mail class.

The Paginator module is very nice solution. Another approach would be to add a "featured" checkbox to the article template. Then you use a Pages::saveReady() hook to keep the checkbox and the Page Reference field in sync - if an article is added to the Page Reference field you set the checkbox to 1 and vice versa. You could set the checkbox inputfield to hidden if you only want to use the Page Reference field to select featured articles. Then your articles selector would be "template=article, sort=featured,-post_date"

To create a sitemap.xml you can use Pete's Sitemap XML module, or you can create a template file and page to do it for you. This post explains how to create a template to do it for you. The benefit here is that you may find it simpler to tweak a template file than a module, though either is a good solution. Here is how to do it with a template file and a page: sitemap-xml.php <?php namespace ProcessWire; /** * ProcessWire Template to power a sitemap.xml * * 1. Copy this file to /site/templates/sitemap-xml.php * 2. Add the new template from the admin. * Under the "URLs" section, set it to NOT use trailing slashes. * 3. Create a new page at the root level, use your sitemap-xml template * and name the page "sitemap.xml". * * Note: hidden pages (and their children) are excluded from the sitemap. * If you have hidden pages that you want to be included, you can do so * by specifying the ID or path to them in an array sent to the * renderSiteMapXML() method at the bottom of this file. For instance: * * echo renderSiteMapXML(array('/hidden/page/', '/another/hidden/page/')); * */ function renderSitemapPage(Page $page) { return "\n<url>" . "\n\t<loc>" . $page->httpUrl . "</loc>" . "\n\t<lastmod>" . date("Y-m-d", $page->modified) . "</lastmod>" . "\n</url>"; } function renderSitemapChildren(Page $page) { $out = ''; $newParents = new PageArray(); $children = $page->children; foreach($children as $child) { $out .= renderSitemapPage($child); if($child->numChildren) $newParents->add($child); else wire('pages')->uncache($child); } foreach($newParents as $newParent) { $out .= renderSitemapChildren($newParent); wire('pages')->uncache($newParent); } return $out; } function renderSitemapXML(array $paths = array()) { $out = '<?xml version="1.0" encoding="UTF-8"?>' . "\n" . '<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">'; array_unshift($paths, '/'); // prepend homepage foreach($paths as $path) { $page = wire('pages')->get($path); if(!$page->id) continue; $out .= renderSitemapPage($page); if($page->numChildren) $out .= renderSitemapChildren($page); } $out .= "\n</urlset>"; return $out; } header("Content-Type: text/xml"); echo renderSitemapXML(); // If you want to include other hidden pages: // echo renderSitemapXML(array('/path/to/hidden/page/'));

Client-side image resizing has been on our roadmap for awhile, and this week we've got it ready on the dev branch in version 3.0.63. People expressed interest in this feature in the comments to last week's post, and I promised to give it a closer look sooner rather than later. After getting that closer look, and doing some research, I realized we could get in this week's version. After using it now for a couple of days this week, I think people are really going to like this feature, and it works a lot better than I had originally guessed it could. https://processwire.com/blog/posts/processwire-3.0.63-adds-client-side-image-resizing/

Note: this functionality is now built into AdminOnSteroids. I'd hate to know how much accumulated time I have spent and how much eye-strain I have experienced over the last couple of years, hunting through the 675 icons in the "all icons" view for the one I want. Today I finally got around to doing something about it. IconsFilter Allows the "all icons" view in InputfieldIcon to be filtered by name. Usage Install the IconsFilter module. When viewing "all icons" in InputfieldIcon (Advanced tab of field/template settings) you can filter the icons by name using the filter input at top right. https://github.com/Toutouwai/IconsFilter @tpr, something that could be merged into AdminOnSteroids?

Hello, today I need this and try adrian and Soma solutions but with partial success (PW 3.0.42). Finally solved with this: wire()->addHookBefore('Pages::saveReady', function(HookEvent $event) { $page = $event->arguments('page'); if($page->template != "your_specific_template_name") return; if($page->isChanged('your_target_field_name')){ // your code $this->message('Your message about changes...'); } }); Main difference is "changes" argument, or $page->isChanged('some_field_name') Regards.

Hi, I would consider taking a closer look at this one: Product variations are challenging to implement properly.

Hello, it´s an iOS thing. https://wouterdeschuyter.be/blog/how-to-disable-viewport-scaling-in-ios-10-you-dont-941140811 You should configure your safari

Thanks Ivan. The budget on this is "$0". It's all sweat equity and even then it might not be adopted. Either way it'll be a great learning experience if I tackle it and quite possibly reusable for other projects. You've definitely given me some things to think about.

@modifiedcontent From /wire/config.php file, to change it you add the config option to /site/config.php /** * Use session fingerprint? * * Should login sessions be tied to IP and user agent? * IP fingerprinting may be problematic on dynamic IPs. * Below are the possible values: * * 0 or false: Fingerprint off * 1 or true: Fingerprint on with default/recommended setting (currently 10). * 2: Fingerprint only the remote IP * 4: Fingerprint only the forwarded/client IP (can be spoofed) * 8: Fingerprint only the useragent * 10: Fingerprint the remote IP and useragent (default) * 12: Fingerprint the forwarded/client IP and useragent * 14: Fingerprint the remote IP, forwarded/client IP and useragent (all). * * If using fingerprint in an environment where the user’s * IP address may change during the session, you should * fingerprint only the useragent, or disable fingerprinting. * * If using fingerprint with an AWS load balancer, you should * use one of the options that uses the “client IP” rather than * the “remote IP”, fingerprint only the useragent, or disable * fingerprinting. * * @var int * */ $config->sessionFingerprint = 1; Session Handler Database, in your PW admin go to modules, install tab and there it is.

No it isn't. This was already in the template. Gradually I will make changes for the better. This one is on the list...

Stripe (https://stripe.com/de for your needs) is very easy to use and integrate.

Hi, the blog works by using page()->children... etc. (see blog.php). When switching the template, the children will be the pages under Home which are not pages of blog-post templates, so there are no comments (among other things) to display. You need at least to look for the selector(s) being used by templates, and change them accordingly.

You can change the default option. Admin > Setup > Fields > Edit Field: images Input (tab) Disable multi-language descriptions? By default, descriptions are multi-language when you have Language Support installed. If you want to disable multi-language descriptions, check this box. Disable multi-language descriptions?

Hello, A friend posted a question about how obtain the markdown code for a image when you are using the markdown editor. Here I created a module just for that. You can download it here. https://github.com/NinjasCL/InputfieldImageMarkdownCodeAdditionalFields cheers.

Hi @Juergen, Thanks for this. I have moved your topic to Dev Talk as I don't think it meets the criteria for a ProcessWire Tutorial.

Why do u use big letter in url? No good.

That's not possible as you can only sort by values in a single column (in the db). You might try to use this: https://github.com/LostKobrakai/Paginator

I can certainly vouch for client side image resizing working very well - I was looking for this functionality for an intranet site I'm currently working on and Ryan's implementation is very good indeed. It even works with front end editing, with a bit of experimenting as to which method you use and how much output code you enclose. As far as the upgrade process goes, what the guys have said above pretty much covers it. There aren't any major gotchas other than what has already been mentioned, but you might try backing up one site and running it locally on a dev server just to test the process.

userAuthSalt: " it is forever tied to the passwords as a secondary salt." But if you use the very same database and files normally you should only need to update $config->httpHosts as @Sérgio Jardim pointed it out above.

If it is a new install, then the user salt (site/config.php) will be different, which affects the passwords.

I am sure there are idiosyncrasies with certain hosting environments, but I have not run across anything outside what the general upgrade instructions dictate. There is also a profile export module with instructions in this thread that I found very helpful.

https://github.com/processwire/processwire#upgrading-processwire I think this is the most complete guide. Upgrading from 2.x to 3.x must be carefully done as you can read. Most of the time, I haven't had troubles with the core, most likely a third party module. I have yet to see ProcessWire break with an update. There's also the upgrade module. which also makes a db backup before upgrading and renames the previous files with a dot at the beginning.

You don't need to change anything in the database. The only change needed in this case is the httpHosts array: $config->httpHosts = array('testing.com'); in the config.php file.

http://fontawesome.io/icons/ have this using the Argolia search engine.. maybe we can have something similar using this https://jets.js.org/ .. is very easy to use with html/data tags and really fast

This is great, thanks! May I have a suggestion too? Searching by name is one thing, but what if we could search by "tags"? I mean lots of icons can be used in different contexts, and most of the time I cannot even guess the name. For example I use "Car" for the article excerpt/ledes (in a "leading the way" sense). More examples I use: Trophy => bagde, Fire => effects, Compass => sku, etc... These associations could be (hard?) wired into the module, so that you can make search possible this way too. I would be happy to contribute, or even better, you could somehow make it possible for everyone to contribute.

This is very likely the reason! I've gone through this types of errors a lot! Images with AdobeRGB or sth alike.

I think this is because as soon as you click "Add New" in a repeater inputfield a new as-yet-unpublished page is added to the repeater. So when you get the "old" page after saveReady this unpublished repeater item already exists and is included in count(). Try this: wire()->addHookAfter('Pages::saveReady', function($event) { $page = $event->arguments[0]; if($page->isChanged('repeater')) { $old_repeater_value = $this->pages->getById($page->id, array( 'cache' => false, 'getFromCache' => false, 'getOne' => true, ))->repeater->not('published=0'); // exclude as-yet-unpublished items bd($page->repeater->count, 'new count'); bd($old_repeater_value->count, 'old count'); } });

$fields->get('image')->getInputfield($page)->maxWidth;

https://github.com/processwire/processwire/blob/50f2834a0ae2a9f9f2ac53439184ebdc04db2f54/wire/core/PagesTrash.php#L53 So there is id, parent id and sort position of trashed page in that name.

It looks to me like there is a typo in the core code that means the Wire::changed method is never called. See here... if(($hooks && $hooks->isHooked('changed')) || !$hooks) { But the phpDoc comments for WireHooks::isHooked say... * If checking for a hooked method, it should be in the form `Class::method()` or `method()` (with parenthesis). So it should have been... if(($hooks && $hooks->isHooked('changed()')) || !$hooks) { ...and if you change to that then the hook starts firing. @gebeer, will you open a GitHub issue for this?

There is limited (and undocumented) AJAX 'dependent selects' support built into Page Reference fields. You must use the 'Custom find' or 'Selector string' option for defining selectable pages, and reference the source Page Reference field (that exists on the same page) using syntax like this: parent=page.page_reference_field_name Based on testing I have found: It only works for Select, Select Multiple or AsmSelect inputfields It does not work inside a repeater item

A Followup This was an interesting conversation by all parties. What I didn't get was what actual syntax that was put in the /site/config.php file. While this may not matter to more experienced users, it makes a difference to others. My sites don't use Multi-Language and I was still confronted with the error that @EyeDentify noted in the original post when updating an existing site to ProcessWire 3.0.55 This is what I put in the /site/config.php file to make error go away /** * Installer: SetLocale Setting * * This is now needed since ProcessWire 3.0.53 to set local information * */ setlocale(LC_ALL, "en_US.utf8"); As @matjazp stated, it doesn't really matter where in the file this goes. What was confusing to me is that most other settings in the /site/config.php file started with $config and it wasn't clear whether this setting needed to follow that style. As I said, it may not be important to experienced PHP users, but knowing what to put when confronted with this warning is helpful. As an aside, it would also be helpful to know the exact syntax that is needed if using the init or ready files. Maybe I have missed something in reading all this that should have been clear to me and excuse me if I have. If what I have used is incorrect, I ask that someone provide the correct format (styling). Thanks.

You can just use two different find calls and just join them: $top = $pages->find(…); $bottom = $pages->find(…); $all = $top->import($bottom); And if you need pagination use this: https://github.com/LostKobrakai/Paginator

Thought I'd mention this here too. Both VersionControl.module and ProcessVersionControl.module have been updated to version 1.1.0: VersionControl 1.1.0 includes new public method getHistory($page) for fetching the full history of a specific page as an array (supports pagination and filters, arguments can be checked from the code). The primary goal here was to separate the core logic of the module from display stuff. ProcessVersionControl 1.1.0 greatly improves the diff output for Page fields. Instead of IDs and string diff it will now use actual labels and custom diff logic. This not only looks better, but also makes more sense than comparing a list of numbers and displaying the smallest possible change set between them The Page field update was thanks to this pull request, though it ended up being a bit more complicated than that: https://github.com/teppokoivula/VersionControl/pull/2.

I found this the other day http://www.vagrantup.com/ and it's awesome to make a virtual machine with just one command vagrant up and have all you need to code with processwire.

Thanks for your thoughts valan. I can certainly see where you're coming from as I'm working on a similarly scoped project, even if it doesn't currently have anywhere that number of users. I think your first point is quite a thing to get to with processwire and it's philosophy of not deleting / overwriting content without explicitly being told to do it (hitting the save button). Introducing functionality like you're describing would certainly need some kind of core field versioning (maybe even event based). This would also need to be deeply considered with the database performance/choice. Event drive admin sounds fun, but it's also a new hurdle for new comers. With a core js api on the roadmap it might become more easily to implement any custom framework into the admin on your own. If there will be a admin js framework to be introduced I'd rather root for vuejs, which from my perspective does have the greater community and drive behind it. But that's to be determined if it comes to that point. Deeply nested selectors would certainly be a great addition.

Maybe a check to see if the checkbox has changed? $changed = $page->isChanged("mycheckbox"); Or there's a ___saved() hook ___saved(Page $page, array $changes = array(), $values = array()) Untested example wire()->addHookAfter('Pages::saved', function(HookEvent $event) { $page = $event->arguments("page"); if($page->template != "mytemplate") return; $changes = $event->arguments("changes"); // array of changed fields if(in_array("myfield", $changes){ // do stuff } });

PW doesn't store the date/time a field is changed. I think the easiest approach might be to add a hidden field called date_terminated. Then add a hook on page save that sets the date if the checkbox field has been checked. Place this is your admin.php file. wire()->addHookAfter('Pages::saveReady', function(HookEvent $event) { $page = $event->arguments("page"); if($page->user_terminated == 1 && $page->date_terminated == '') { $page->date_terminated = time(); } }); That is a little rough but will hopefully get you started. You should add an if statement to limit this to just the relevant template so it is not run on all pages. I am sure other improvements could also be made. PS Apparently I was writing this while LostKobrakai was responding

HTTP hosts, sessions, cookies don't come into play with passwords. Some other factor must be at play during that migration. Of course, a change in hostname will kill active sessions, since the session is tied to the HTTP host. But that's no different than if you just logged out. What can affect passwords is the PHP version and what capabilities it has with regards to encryption support. If you are running PHP 5.3.8 or newer (our current minimum requirement) then it won't be a factor unless you are moving to a PHP installation where the administrator has disabled some of PHP's encryption functions (which would be unusual and rather bad from a security standpoint). I kind of doubt that any of the above are it. What is more likely is a change to the $config->userAuthSalt (which appears at the bottom of your /site/config.php file). That particular value is generated randomly when you first install ProcessWire. It is forever tied to the passwords as a secondary salt. It's not technically necessary to have it, and passwords are already blowfish'd, but I've always felt better having one part of the salt disconnected from the database itself. If that salt changes or is lost, then all the passwords are forever broken. Is it possible you changed out the /site/config.php or even accidentally modified the value of userAuthSalt?

Create a role called "top-level-editor" (or whatever you prefer). Give that role edit permission, but not delete permission. If you want the role to be able to sort children of these top level pages, then you'll want to assign page-sort permission to the role as well. Assign that role to the template used by your top level page(s). Create another role. We'll just call it "editor". Give that role edit, delete, move and sort permission. Assign that role to the templates indicated, but not the templates where you assigned top-level-editor. Don't forget to assign both of these roles "top-level-editor" and "editor" to your user(s) that you want to have this access. I think this was the part WillyC was trying to communicate.