Leaderboard

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.

I don't think it matters much here. The object===object is probably about the same thing as an id==id integer comparison, when it gets down into the low level code that it's written in. That's because object===object is comparing that two objects are the same instance, which translates to: do they occupy the same place in memory? (1234567==1234567) But there is a good reason to use the id==id over object===object in ProcessWire: $about1 = $pages->get('/about/'); $about2 = $pages->get('/about/'); echo $about1 === $about2 ? "Same Instance " : "Different Instance "; This should output "Same Instance". But then try this: $about1 = $pages->get('/about/'); $about1->set('title', 'About Test')->save(); // can be any page that is changed then saved $about2 = $pages->get('/about/'); echo $about1 === $about2 ? "Same Instance " : "Different Instance "; This should output "Difference Instance". Why? The entire memory cache is cleared when you save a page where one or more fields changed, or if you delete a page. It doesn't matter if it was $about1, or some other page, the memory cache is wiped. Since the code above kept it's own copy of the /about/ page before it was saved, there are now two copies of /about/ in memory: your copy and ProcessWire's copy. For this reason, you may prefer to compare the 'id' property if the code you are working with is manipulating any pages or interacting with modules that do. But for most front-end situations, it doesn't matter.

That's not far off from what I'd been working on with versioning, which was to store page versions in flat JSON encoded strings in a DB table (though could just as easily be stored as text files). Any ProcessWire page can be reduced to a PHP array of basic types (strings, integers, floats, arrays), which means it can be reduced to a JSON string really easily. This lends itself well to version storage, except for assets where only references are encoded (like files and page references). But I have to admit that the more I think about Antti's proposal to store this at the field-level, the more Iike it. I would create another interface that could optionally be added to a Fieldtype's implements section in the class definition (FieldtypeWithVersions or something like that), and give the individual fieldtypes responsibility for if, how and where they store their versions. That would enable us to get up and running with versions quickly (for text fields at least). It would also seem to provide a nicer level of control to the user, as you don't have to keep track of what is changing in multiple fields at once. And, it would let you to enable versions on fields that you want it, omitting on field where you don't, making things more efficient. Lastly, it would leave the page-structure out of versions completely (where the page lives in the tree), which struck me as a potentially dangerous problem with versions. It could work something roughly like this: You hover over the revisions label and get a summary of recent revisions. You click on one, it could pop up a modal showing you the revision (maybe with a compare tool) and a button to revert to it or cancel. It just seems like a really easy-to-use solution for the user.

Ok, I have implemented a language domains option you can now enable in the module settings. I did some testing on my local install and so far everything works as it should. I just commited the update and it's ready to use. urlSegments , pager, page links in language text fields still work and I didn't notice any problems. However it's not sure any other side-effects pop up I may missed, apart from the ones already there. From readme: This module now supports language domains. So you can have each language mapped to its own domain. To make this work you need to have the different domains point to the default domain and PW install. Then enable this option in the module settings and enter your domains in the textarea, each domain on its own line. The format is [domain:langcode] i.e.: domain.com:en domain.de:de domain.fr:fr You could also use subdomains: en.domain.com:en de.domain.com:de fr.domain.com:fr Result: Now you can access the different languages simply through the different domains. For example the "/about/" page would be available like this: domain.com/about/ domain.de/ueber/ domain.fr/au-sujet-de/

There's no field access yet, but I've heard rumors that it will come sooner or later. However you can create a simple module that does hide/show fields on a condition, whether a custom permission, role or user. Following is a simple autoload module that hooks the Inputfields and returns empty string, if condition aren't met. Actually very straight forward and powerful. There could be added some module configuration, to simply add fields via a textfield you want to hide for other users. Possibilities are endless. Save the code as FieldHelper.module and put it in /site/modules/ Configure it to your needs and install it. <?php class FieldHelper extends WireData implements Module { /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * * @return array * */ public static function getModuleInfo() { return array( 'title' => 'FieldHelper', 'version' => 100, 'summary' => 'Hide fields depending on permission, role, or user.', 'singular' => true, 'autoload' => true ); } public function init() { // add after-hook to the inputfield render method $this->addHookAfter("Inputfield::render", $this, "renderField"); } /** * Hide fields depending on permission or possibly role, user * */ public function renderField(HookEvent $event) { // get the current field $field = $event->object; // example 1permission if($field->name == "pre_content") { if(!$this->user->hasPermission("admin-fields")){ $event->return = ''; } } // example 2 role if($field->name == "after_content") { if(!$this->user->hasRole('superuser')){ $event->return = ''; } } // example 3 user if($field->name == "page_scripts") { if(!$this->user->name('admin')){ $event->return = ''; } } } } I created a gist for this example here: https://gist.github.com/3122191

Hi, Michal. I'm not sure you need to delete "core" permissions for they provide Processwire's essential functionality and, btw, you can't delete them from back-end. For example, you add a permission, grant it to one of your roles and then write code to check against this permission in your template: if ($user->hasPermission("touch-this")) { echo "The world is yours!"; } else { echo "Can't touch this!"; } So $user->hasPermission() will return true if a user has a role to which this permission is granted, otherwise it will return false. The only exception are users with superuser role as it has all permissions granted by default. For this users $user->hasPermission() will always return true even if superuser role doesn't have a permission granted (checked in back-end). Deleting a permission is like taking it away from a role and respectively from all users with this role. So after you deleted a permission, $user->hasPermission() will return false when checking against this deleted permission for all users except ones with a superuser role. This is based on my limited experience, I'm sure there's more to say on this topic. Edit: corrected "front-end" to "back-end".

One of the ways you can show support for ProcessWire is to help get the word out by including a small "Powered by ProcessWire CMS" tagline (ideally linking to processwire.com) in the footer of sites that you develop. This is a big help to the ProcessWire project. But I know there are many cases where it just doesn't work to do that because the client thinks of it as gratuitous. I think it's important to communicate to your client that it's not gratuitous at all. It is doing the right thing by showing appreciation and support for a software that is running their site at no cost. Even so, it's not always as simple as that, and I completely understand. We have no requirement or expectation that sites developed in ProcessWire do this. We just encourage and appreciate it when you can. Let your client decide One thing I've been doing lately is to put the control into my clients hands. They really appreciate that I've given them control over it… more so than if I'd left out mention of ProcessWire completely. It also makes them feel good as they are the one showing support, not just their site developer. Here's how to do it in 1 minute: 1. Create a new "checkbox" field in Setup > Fields called "toggle_powered" (or whatever you want to call it), and enter the following for label and description: 2. Add the "toggle_powered" field to your homepage template. 3. Edit the homepage and check the box (if possible in your situation). 4. Edit the template file or include file that contains the site footer and paste in the following: <?php if($pages->get('/')->toggle_powered): ?> <p> <a id='processwire' target='_blank' href='http://processwire.com'>Powered by ProcessWire Open Source CMS/CMF</a> </p> <?php endif; ?> The code above is an example, so adjust the markup, size, wording and placement to suit the site.

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.

Just spotted (via Google Webmaster Tools) that I had the same problem on one of my sites that had been migrated from Joomla. I had put 301 redirects in the .htaccess file, and must have tested them at the time, but they were having the '?it' parameter added as well. To be honest, I have no idea why I didn't use Antti's excellent plugin in the first place, but I have now and of course everything now works as it should.

Thanks for this thread. I also just discovered ProcessWire and am considering a permanent move away from ExpressionEngine.

I'm accessing PW at present and must say I'm really impressed with what I''ve seen so far. +1 for field level access. I use this facility in modx for virtually every client-editable site (using modx plugins). Perhaps I'm stuck in a certain mode of thinking from using modx for so long, and there's more than one way to skin a cat, but I love in modx that I can have a field from which I can easily issue instructions to a template on a per page basis, which must not be visable/editable to the client. It allows me be reuse the same template for quite different pages. For example, in my modx sites I have "content", "preContent" and "postContent" fields. Only the content field is available to the client, the pre and post content fields simply allow me to add instructions to output something specific on a page directly before or after the clients content. Sure, there are other ways to do this (how do you guys achieve this in PW?) but I love this method as it's so simple and easy to edit. BTW, PW looks like an incredibly good piece of kit and the forums seem super-friendly - I love modx and it's been good to me but it doesn't quite feel right sometimes, whereas PW seems to have a nice clean feel to it. So far I think PW has covered all the bases for my needs, except for a form processor for simple validating and re-populating forms. It's possibly a little beyond my coding level but I might just have to have a dig at writing one. Well done PW team, beautiful work.

Just wanted to say that the memory consumption issue I mentioned in my previous post most probably was about having debug mode on (as I usually do on a development site). So that part seems to be ok as well. And thanks go to Ryan once again - just read about this from a tweet by @processwire .

Ryan, Great, it seems to me you nailed it! My own tests now execute as they should, not slowing down anymore as there are more pages. And the new code in Pages.php makes more sense to me as well. So at least no obvious flaws there I can find. Creating pages with repeaters does take more time than creating pages without them, but as you said that's expected behaviour. This has a huge impact on the project I've been working on. Actually, I had to drop repeaters from first version because of this performance issue. I think I didn't mention it in the beginning, but on top of being unbearably slow, memory consumption was not at an acceptable level either when handling large amount of pages. I haven't tested this part yet, but I'll sure be telling you if this didn't get fixed as well (wouldn't be that surprising if it actually did). Anyway, now I'm able to return to my original plan and utilize repeaters the way they deserve to be utilized. I also ran your test package successfully. One comment on the script though. The very first get()-call trusts the data has been populated in right order: If "do.php repeater-populate" is run before "do.php populate", this will return country-97 under /countries-repeater/ and fail at the second move (Chosen parent '/countries/' already has a page named 'country-97'). So has_parent=/countries/ or something else needs to be added there - or of course one can populate everything in the right order.. I have to say I really like the work you're doing with ProcessWire - keep it up. Once I managed to get the issue out in the public, it got instantly taken care of. So, thanks! More posts to come from here now that I've started . I'm glad to be of help wherever I can.

The page history module may yet make it into 2.3, but not as a full blown versioning system. However, it may be able to do some of what you mentioned with text fields. But the point of the page history module is more about seeing what changed, when, and by whom. Though tracking this info crosses over into the territory of versioning in many respects. I guess I think of full blown versioning as including all page data (files, repeaters, etc.), but it's a difficult prospect without actually making clones of the pages themselves (like Rob mentioned). Maybe I should stop trying to think about these things and focus on the stuff that can be versioned efficiently. Your idea of a field history is compelling, I need to give some more thought to it.

I think it would be great to have some basic versioning, even just for textfields would be very beneficial. I know it goes greatly more complicated with files and repeaters, but most (or at least big) benefit comes from just text versions. Page history module is also first item on roadmap, so many people might have high hopes for it: http://processwire.com/about/roadmap/ (if it's not coming for 2.3 then maybe to strike from list and move to 2.4+ part of that list). Also - would it make any sense to have field history instead of page history? Would it be any simpler to implement that way?

I totally agree with this. I even think we should take this as concept for PW. I really like the way things are happening here. Most modules are discussed in the forum, and each module gets lots of input from the community before it's finished. I know that it isn't easy to keep it like this, as the number of users and developers grow, but would be great if it would be possible to keep a truly useful official modules repository (not too big, and without repeated functionality). This could be done via the forum, and via a small number of administrators who would filter, and propose the merging of modules with the same functionality.