ProcessWire 2.3 features

[ryan]

Selector problem in dev branch, this works in master but throws an exception in dev:

This should now be fixed on dev.

[Martijn Geerts]

Looks like: Children are sorted by <select><option>Manual drag'n'drop</option></select> is broken in 2.2.10 & 2.2.11.

The manual drag'n'drop setting won't be saved in the DB. Setting sort directly to the table pages_sortfields (<option value="sort">Manual drag-n-drop</option>) in the DB doesn't work eighter.

It occurs on the Page edit and on the template settings.

[DaveP]

<slightly off topic>Gmail rendered the select in my notification email!</slightly off topic>

[ryan]

"Manual drag-n-drop" is the unselected state, meaning it's the one state that wouldn't store anything in the DB. I've tried to duplicate, but not sure I understand. I've tried changing between Manual and other sort fields, changing back to manual, and drag-sorting pages, but all seems to work. Is there anything else I need to do to duplicate?

[Martijn Geerts]

Must be some issue on a the local install of ProcessWire on my Laptop. Tried to duplicate it on my work machine and see no problems over here. Will check again & reinstall the dev branche on my local machine.

I'll let you know if it's just me or there's some issue.

[ryan]

I'm really not sure what to think about the PHP 5.4 error message.

Finally figured this one out. Apparently PHP 5.4 comes with a class name "SessionHandler" that is the same as ProcessWire's. So I just renamed ours to be WireSessionHandler and now all seems good with PHP 5.4. But this is yet more motivation to move everything to namespaces sooner rather than later. Now thinking this has to be done in ProcessWire 2.4.

[Martijn Geerts]

See a lot of changes already in 2.3. I'll love it. So far, I don't see issues. Sites i'm building now start with the 2.3 branche, cause I have lots of trust in all the work you've done. And I thank Soma, Nik, Teppo and all the others who contribute to make such a great product.

Hope there's wil be a list of all changes there are when 2.3 is final.

[encho]

See a lot of changes already in 2.3. I'll love it. So far, I don't see issues. Sites i'm building now start with the 2.3 branche, cause I have lots of trust in all the work you've done. And I thank Soma, Nik, Teppo and all the others who contribute to make such a great product.

Hope there's wil be a list of all changes there are when 2.3 is final.

Can you let me know how that works for you. I have few websites I'm working on and don't want to use the old base if the new one is just around the corner

[Pete]

To be honest it's not like other systems where there are massive changes - everything from 2.2 will work in 2.3 so it's up to you.

Upgrading is just overwriting the /wire folder too so no hassle.

[ryan]

If you upgrade to 2.3 now, you'll just want to test everything in your site out to make sure it still works how you expect.  There have been some core changes and optimizations that should not change any behaviors, but sometimes small things don't become apparent until it's in broader usage. So just test thoroughly. Also note that once you've got 2.3, you shouldn't go back to 2.2. It does make some minor DB schema changes in some cases, which 2.2 wouldn't know about. It also uses a different hashing mechanism for passwords that 2.2 doesn't support. 

[mindplay.dk]

For those that wanted field/template categorization, I've got them implemented for fields and now development the same for templates.

Note that you can already "tag" templates using fields - I think you will find quite often that templates with certain tags are also going to have certain fields, so watch out for those cases and avoid using tags in those, since you may be duplicating semantics.

For example, you can already select all pages that have the great_big_headline field, so you don't need a tag for templates that have a "great big headline".

Edit: one case where I could see template tags being really useful, is to output the tag-names (probably with a prefix or suffix) in the class-attribute of the body-tag - something my HTML/CSS guy asks for all the time.

[ryan]

ProcessWire now implements ALL of the jQuery traversal functions in the Page API. Existing ProcessWire versions already implemented most of them, but once we started updating parent() and parents() to support selectors, I figured we might as well be fully complete and consistent with the jQuery equivalents. Now we are. The following functions were added or updated:

• $page->parents([$selector]) -- Now you can specify a $selector and it will return parents that match your selector. 
• $page->parent([$selector]) -- Now you can specify a $selector and it will return the closest matching parent. 
• $page->closest($selector) -- Same as parent($selector) except that it considers the current page in addition to the parents.
• $page->parentsUntil($selector, [$filter]) -- Return all parents from current till the one matched by $selector, optionally filtering them afterwards by $filter (a selector string). Note that $selector may be a selector string, a Page, a path, or an ID. 
• $page->next([$selector]) -- Now you can specify a $selector and it will return the closest matching next sibling. 
• $page->nextAll([$selector]) -- Returns all siblings that come after this $page, optionally filtered by a $selector. 
• $page->nextUntil($selector, [$filter]) -- Return all sibling pages after this one until matching the one specified. Optionally filters the results by $filter, which is a selector string. Note that $selector (the first argument) may be a selector string, a Page, a path, or an ID.
• $page->prev([$selector]) -- Now you can specify a $selector and it will return the closest matching previous sibling. 
• $page->prevAll([$selector]) -- Returns all siblings that come before this $page, optionally filtered by a $selector. 
• $page->prevUntil($selector, [$filter]) -- Return all sibling pages before this one until matching the one specified. Optionally filters the results by $filter, which is a selector string. Note that $selector (the first argument) may be a selector string, a Page, a path, or an ID.

Arguments in [brackets] are optional. 

These functions duplicate the arguments and behavior of their jQuery counterparts. The exceptions are that parent(), next(), and prev() have a slightly different behavior: they will traverse to find the closest match (which I thought was a lot more useful in our context). In jQuery, they don't traverse beyond the direct parent/next/previous item in the DOM. 

As before, all the next and prev functions should be used cautiously when $page has a large amount of siblings. All these functions require loading all the pages they interact with, as comparisons are done in memory and not via SQL queries. All of them accept an optional last $siblings argument, which is a PageArray of siblings you want it to analyze (which is presumably a more limited set), and this is what you'd use if you need to scale to thousands of pages when using these functions. But if you aren't dealing with huge amounts of pages, then you don't need to consider this.  

[diogo]

amazing!

[Soma]

Awesome! Thanks Ryan for the description. Some work for the cheatsheet...

[Wanze]

This is great!! Need to get some sleep now

[Soma]

Was wondering if this is the start of using PW tree as a html dom tree?

[teppo]

Awesome stuff, Ryan!

The exceptions are that parent(), next(), and prev() have a slightly different behavior: they will traverse to find the closest match (which I thought was a lot more useful in our context). In jQuery, they don't traverse beyond the direct parent/next/previous item in the DOM. 

Interestingly that's something I've always found annoying in jQuery - never understood why traversing only one level would be desirable. I guess it does have it's use cases, but I'm quite happy that you decided to alter their behavior for ProcessWire..

[ryan]

Someday I hope to have these functions more scalable so that they don't require being in-memory to perform their jobs. It's a tricky balance, having a large group of pages that can be sorted by anything, and then finding the current page's place within it, without being in memory. But we will get there. 

[raydale]

Just catching up with all things ProcessWire lately and am excited by what I see being put into 2.3.

The new traversal functions and LinkMonitor module and comments monitor look good. I also really like the concept of having $config->prependTemplateFile and $config->appendTemplateFile to reduce the need to call includes in template files.

[Pete]

I also really like the concept of having $config->prependTemplateFile and $config->appendTemplateFile to reduce the need to call includes in template files.

I hadn't noticed that - in case others missed it, you can read about it here: http://processwire.com/talk/topic/2491-skyscrapers-profile/

I quite like the idea as you can really keep things tidy this way.

[raydale]

I quite like the idea as you can really keep things tidy this way.

I guess it's similar to the optional functions.php file used in WordPress theming, except that you can call them before and after the template files are called, plus, you are able to name the files whatever you wish - nice and flexible. This should help those who are familiar with WP theming to become more comfortable using ProcessWire.

[ryan]

The new traversal functions and LinkMonitor module and comments monitor look good.

LinkMonitor won't be included in 2.3. It'll remain a separate module. I've not yet released it because I think there's a better way do accomplish what it is doing... just haven't figured it all out yet. 

[raydale]

LinkMonitor won't be included in 2.3. It'll remain a separate module. I've not yet released it because I think there's a better way do accomplish what it is doing... just haven't figured it all out yet. 

Thanks for the info Ryan. I look forward to seeing any alternative you come up with.

[stefan]

Hey Guys, 

http://processwire.com/talk/topic/3093-install-23-blowfish-zendserver-exception-unable-to-generate-password-hash/

maybe also related to this topics.

http://processwire.com/talk/topic/1492-processwire-23-features/?p=22064

[ryan]

A little bit of new fun stuff on the 2.3 dev branch: 

Anonymous functions and hooks

You can now use PHP 5.3+ anonymous functions when attaching hooks. All the syntax below will work either from your template files, modules, or any Wire derived class. If using outside of template files or Wire-derived classes, then replace $this with wire(). Though anywhere that you can use $this you can also use wire(), so syntax is also a matter of preference. 

Example: 

Add a "hello()" function to all pages that returns "Hello World!":

$this->addHook('Page::hello', function($event) {
  $event->return = "Hello World!";
}); 

Result:

echo $anyPage->hello(); // outputs: Hello World!

Example:

Add a 'hi' property to all Users that contains the value "Hi [their name]!". 

$this->addHookProperty('User::hi', function($event) {
  $user = $event->object; 
  $event->return = "Hi $user->name!";
});  

Result:

echo $user->hi; // outputs: Hi Ryan!

Example:

Add a grandparent() function to all pages. 

$this->addHook('Page::grandparent', function($event) {
  $page = $event->object;
  $event->return = $page->parent->parent; 
}); 

Result:

$myPage = $pages->get('/about/news/categories/sports/'); 
echo $myPage->grandparent()->url; // outputs: /about/news/

Example:

Save a message to a log file for each new page that is added. 

$pages->addHookAfter('added', function($event) {
  $page = $event->arguments(0); 
  $this->message("Added new page: $page->path", true); 
});  

Result:

The message is added to log file /site/assets/logs/messages.txt when a new page is added. 

Example:

Add a 'createdString' property to all Page objects that is the same as $page->created except that it outputs in a human readable format rather than a unix timestamp: 

$this->addHookProperty('Page::createdString', function($event) {
  $page = $event->object;
  $event->return = date('Y-m-d H:i:s', $page->created); 
}); 

Result:

echo $page->createdString; // outputs 2013-04-30 03:05:00 

This just touches on the possibilities with some overly simple examples. But you can use these anywhere you'd use any other hooks: from within modules, templates, or anywhere in ProcessWire. I think that the anonymous function syntax is particularly convenient within templates, when you can define your own helper functions in your head.inc or init.php or whatever file you have starting your templates. Don't forget you can add stuff in /site/templates/admin.php too in order to hook into things that happen during administration. 

Error and message logs

ProcessWire has always maintained logs, but I'm guessing that most don't know how to write to them. So I setup a simpler syntax for you to save things to PW's system log files: 

$this->message("This text will be saved to /site/assets/logs/messages.txt", true); 
$this->error("This text will be saved to /site/assets/logs/errors.txt", true); 

This is the same as these functions worked before, except for the second "true" argument, which tells it to write to the log file. From the admin side, it'll still display these messages interactively. If you only want it to log and not display the messages in the admin, then replace the "true" with "Notice::logOnly". Though if you are doing this from templates, then you don't need to consider that since templates (other than the admin template) don't typically output ProcessWire's notices. 

---

Edit: I changed the wire() syntax in the examples to $this. Though either works from template files and modules, but I think $this syntax is more familiar to most.