ProcessWire 2.3 features

[ryan]

We'll use this thread to discuss PW 2.3 features as they are being worked on. I've just added one of the first components. This is the "Page Path History" module. It's now in the PW core as a beta module (uninstalled by default). If you are interested in helping to test, just install the module from Admin > Modules > Page > Page Path History (after doing 'Check for new Modules').

The Page Path History module keeps track of the previous URLs for any pages that have been moved or renamed. It then sets up automatic redirects (301, permanent) to ensure the old URLs redirect to the new ones. This is best demonstrated by a few examples:

• Lets say you had the page /about/contact/ and you moved it to /contact/. With the Page Path History module installed, anyone accessing /about/contact/ will get redirected to /contact/.
  

• You had a page called /our-products/ and you renamed it to be /products/. Any accesses to /our-products/ will now get redirected to /products/.
  

Those are simple examples, but this module can handle more complex situations too:

• Lets say you had the page /our-products/furniture/whoopie-cushion/ and you did like in the previous example and renamed /our-products/ to be /products/. The /our-products/furniture/whoopie-cushion/ URL will now redirect to /products/furniture/whoopie-cushion/
  

• Later on you decide to rename /products/ to just /inventory/. All the /our-products/ and /products/ URLs will continue to work with redirects.
  

• You decide that whoopie-cushion really belongs in /services/ rather than /inventory/, so you drag it to /services/whoopie-cushion/. It's old URL in /inventory/furniture/whoopie-cushion/ redirects to it's new URL.
  

TL;DR (am I doing this right) -- you can move or rename any pages and all the old URLs will redirect to the new, automated behind the scenes, without any thinking on your part.

[Pete]

Sounds useful - im guessing if a page's path changes twice the first path will be automatically redirected to the latest path, and not through any paths in between?

[diogo]

This is nice

What happens if you create a new page with the same name of the one that was changed? It stops redirecting, I hope...

[WillyC]

soumd problamatic to.me 888 what.wil be if put page.in trash,change.name n tamplate whilst.in trash then un-trash to new pare

T? what.abt the recersive gramdchildrens?

[ryan]

@pete: it stores the target as the page ID rather than a URL so always going to redirect to whatever is the

Latest ver of the page. (ie no extra redirects)

@diogo: it doesn't look for redirects unless a 404 has already been triggered. So if the requested path matches a page in the system, a 404 never gets triggered and this module would not come into play.

@WillyC: please try that out and report back what you find?,

[tsdtsdtsd]

Awesome feature!

I hope it's a 301, not a 302

Does this happen while dispatching or do you modify the .htaccess on runtime?

[apeisa]

Clever module and I love the simplicity of the implementation: https://github.com/r...hHistory.module

tsd: it doesn't touch .htaccess at all. If processwire throws 404 it then checks if there has been page in that path. If has, then it checks if that page is still live somewhere and is viewable by current user. If it is, then it does 301 redirect there.

[ceberlin]

I like the idea to redirect external links to the new locations.

But what is with internal links (coming from html text fields, for example). Wouldn't re-linking be much better than re-directing?

Some thoughts:

There could be some sort of internal-links list as a field where the user finds and sets all internal links he is intending to use on the page.

And within the WYSIWYG editor the user would somehow be able to use a link-id instead of the real link, which is replaced by the real link on page output. Those links would be some kept up-to-date. Another benefit is that such an inventory could use a search for finding the right pages easily and fast (Drupal has such a module).

A benefit of this would be that you could use that link-inventory to show an editor on the target page, which internal pages link to it.

Or maybe a search & (optional !!) replace for links within the internal database. (Kind of mimicking Dreamweaver's behavior of keeping internal links within sites intact.)

Or did I overlook a feature that is already existing in CW? - I am desperately missing some manual.

[Soma]

PW has also such a module that does what you're saying. http://processwire.c...ink-abstractor/ it's listed here http://processwire.com/download/modules/

[ceberlin]

just found it! Thank you very much. I had simply overlooked it.

[ryan]

I've actually got a lot of updates coming for the PageLinkAbstractor module that I was working on in the last couple weeks. Beyond what it was doing before, it now also keeps track of links to deleted pages and deleted images or files. When it detects a broken link, it logs it and optionally emails you about it. It also keeps an alert at the top of the admin screen telling you about it with a link where you can go review it. Once you fix the broken links, it detects they've been fixed and clears the log of fixed errors.

Here's a couple of scenarios that it covers:

1. Page /about/ links to /products/widget/ in the bodycopy (TinyMCE) field. The /products/widget/ page gets moved to the trash or deleted. Since /products/widget/ is gone (or at least, not accessible to anyone) the link is broken.

2. Page /about/ has a photo embedded in the bodycopy (TinyMCE) from the /events/bbq-fest/ page. That photo gets deleted from the /events/bbq-fest/ page, which causes a broken image to appear on the /about/ page.

Both of those errors would be automatically detected, logged, and emailed to you, so that you can fix them. It's keeping track of this stuff so that internal broken links don't ever get to persist.

With these additions, the module is also being renamed to LinkMonitor, LinkNotifier or LinkPolice (still deciding), as I think PageLinkAbstractor is just a bit too technical sounding.

[nikola]

Ryan, that's a welcome update to PageLinkAbstractor module. It saves me a great amount of time so I don't have to track down missing or broken links, so these new features are really nice, specially error e-mailing.

[Pete]

LinkMonitor sounds great to me. Love the added features

[slkwrm]

+1 for LinkMonitor. Great additions!

[Nico Knoll]

Sounds nice

I'm really curious about the other features!

[ryan]

Some recent additions for 2.3 that are now in the dev branch (I could use help testing if anyone has time):

Added "required" support to all fields

I've enabled required field support for all fields in ProcessWire (no need for advanced mode either). Now you get a "required" checkbox on the "input" tab of any field in Setup > Fields > [field].

If you are dealing with a published page and save it, you'll get an error if any required fields are blank. The page will still be saved. So it's more of something to annoy you into completing the required field. But if you are dealing with an unpublished page, it won't let you publish it (in the page editor) until you complete all required fields.

While seemingly a small thing, the scope is more broad than it sounds as it applies to a lot of different Inputfields. I could use help testing this one out to make sure I haven't missed anything or introduced any new side effects or issues anywhere in ProcessWire.

Other additions

• Fieldsets can now take advantage of column widths, enabling you to have multiple fields in a column.
  
• Fixed some bugs that occurred with fieldsets in tabs and fields getting brought into fieldsets they weren't supposed to.
  
• Add Interrobang's PHPdoc comments.
  
• Add ability to disable PW from throwing an exception when you call an unknown method (for porl's Twig module and other future ones like it).
  
• Clean up and optimize the /wire/templates-admin/styles/inputfields.css - it had some redundancy before. Also added a style to call out required fields. Other admin themes may want to do something similar (see the InputfieldStateRequired style in that file).
  
• Some other small things in the commit log (Apr 07-Apr 12)
  

[MarionRaven]

Proposal: Combining css-files and js-files to one file each would be a nice option.

The number of files reduces by means of the cache. So it is a minor problem.

Anyway I'm asking for it, cause it may not be a big task for you.

I got far more blocking (and waiting) time than transfer time, if I request a backend page for the first time.

[yellowled]

Proposal: Combining css-files and js-files to one file each would be a nice option.

Pete's http://modules.processwire.com/modules/minify/ does just that (with a little manual work in the template required).

[ryan]

I understand the benefits of combining CSS/JS files on a site. There are many places where they can be a real benefit, and fewer places where they may not. ProcessWire admin is one place where it wouldn't be a benefit. The issue with combining CSS or JS files with the PW admin is that the files are rarely the same between requests. It all depends on what process, inputfield and other modules are requested by the action. There could potentially be dozens, hundreds or thousands of different combinations (depending on your site). So combining these would be adding overhead rather than reducing it, as we'd be losing much of benefit of browser caching. Compare that to what we're doing now, where the browser can retrieve these files once, cache them and then use them in any combination without having to re-retrieve them every time the combination changes. ProcessWire loads things on-demand, so the selection of CSS/JS files in any request can change a lot. We want the browser to cache them individually so that they can continue to be used on every request without reloading.

[MarionRaven]

@ryan;

I just made a post concerning a similar topic

Working on it I got aware of the heterogeneous collection of Javascripts. So I instantly decided that the task is not something I can do.

I hoped, you are able to collect them to at least to chunks. But I agree it is not a critical issue at all.

Thank you for the long explanation.

[ryan]

For CSS files, there are 3 loaded on every admin request, but the load order is important, so only 2 of them could be potentially chunked (and the end of the load order): inputfields.css and ui.css. The same goes for JS files, where JqueryCore.js and JqueryUI.js could be chunked (at the top), and inputfields.js and main.js could be another chunk (at the bottom). Though I'm not sure there is enough to make it worthwhile, but definitely some room for experimentation.

[MarionRaven]

For CSS files, there are 3 loaded on every admin request, but the load order is important, so only 2 of them could be potentially chunked (and the end of the load order): inputfields.css and ui.css. The same goes for JS files, where JqueryCore.js and JqueryUI.js could be chunked (at the top), and inputfields.js and main.js could be another chunk (at the bottom). Though I'm not sure there is enough to make it worthwhile, but definitely some room for experimentation.

I had this picture in mind.

I thought, this will bite you (me), if you ever disable your cache.

Luckily this is not regular done by anyone.

With your knowledge, I wouldn't have suggested the small reduction which is achievable.

[MarionRaven]

[Pete]

The inputfield and process ones are specific to those modules so it makes sense that they're separate, even if they're core modules.

That said, minifying them would save a few seconds on each admin page load - the question is how easy that would be to do (I'd use the PHP minify project personally, but doubt that can be distributed with PW?).

It might make things a bit snappier where larger numbers of different fields are concerned, but even with that it's not exactly sluggish (though my live site list of files that's simialar to yours above is only 4.6 seconds max and that's not even localhost!).

[ryan]

I guess I don't totally understand the issue here, as I've never had to wait for anything in real use. And I'm using a run-of-the-mill consumer grade internet connection. I recognize we've got a lot of small files to load (the modularity is intended), but I've never personally felt any load time drawbacks. And once loaded, of course they are then waiting in the cache, not needing to be loaded again. Perhaps it's more a matter of connection speed, but this is a web application not a front-end facing site where thousands of people might hit it at once. I'd consider it a best practice to minimize the quantity and size of loaded files on the front-end, but might consider it the opposite in an admin application like this, where modularity is far more important. If load time is an issue for anyone, I think we might do better to find ways to optimize the browser cache. For instance, can we send some cache control headers to reduce the 304 requests (or perhaps something like that). Though I'm also not against automated combining/minifying, if there are good opportunities to do it without side effects, and there is a tangible (not just tiny measurable) performance benefit to be found.