ProcessWire Dev Branch

[Manfred62]

@ryan

is it possible to get the translation problem (in LanguageTranslator.php) fixed? More details in this thread.

If possible, best will be also change this in the 2.4 stable version to avoid any confusion for newbies testing PW with translations on Windows environment.

[adrian]

Hey Ryan,

Just a quick note about the new 1 step page adding. It seems to have some weird effects if you create the page via the API.

Doing this:

$p = new Page();
$p->template = "basic-page";
$p->parent = $pages->get("/about/");
$p->save();

resulted in two new pages which is weird:

• untitled
• untitled-4

and even weirder, this was on a fresh install so for one not sure why it jumped to 4 for the second one.

The other problem is that because you need to save the page to create it at all via the API, the name is actually populated with "untitled" already, which means that if someone then goes to edit the title, it won't automatically set the name to match.

If I add $p->status = 2561; to the above code then the new page is created with the new temporary status setting which is great - the name is not populated so things work as expected. The only problem now, is that there are still two new pages created.

I know this feature was not really designed for API adding of pages, but I can still see people using it that way, unintentionally or maybe even intentionally.

Another more important side effect I just discovered - if you create the page with no status setting, but with just a title (no name), like this:

$p = new Page();
$p->template = "basic-page";
$p->parent = $pages->get("/about/");
$p->title = 'TestMe';
$p->save();

then two pages are still created. The titles are correct, but the names are: untitled-n. I think this could be quite problematic for some existing modules and chunks of template code that rely on automatic name generation from the title.

If you set the name as well, then all is good again - one page created with everything named correctly.

EDIT: OK, I am going to crawl back in my hole now - I was running these tests with Hanna Code's test functionality - I have been using it for a while now as an easy way to test code snippets. Turns out the double issue was all because of Hanna. I re-ran these tests using my Code Tester module (which I used to use all the time) and everything seems to work as expected. The $p->status = 2561; was still obviously key to making things work as expected though.

Feel free to unlike this post now

EDIT2: Actually, I think there is still one potential issue - I still seem to be having the issue that a newly created page that is assigned a title but not a name ends up with "untitled" as the name. Does anyone else see this?

Edited March 27, 2014 by adrian

[Marty Walker]

Yay! This 1-step adding of pages makes complete sense to me and it's a nice addition. I've been given a few confused looks from clients when I show them the "two-step". In 99.9% of cases when my lot add a page the URL is going to match the title.

[ryan]

A few new/minor additions on the dev branch:

You can now paginate with "limit=1" selectors. Previously ProcessWire didn't build the pagination information when a limit of 1 was specified. Now it does. 

ProcessWire now preloads pages that it knows it's going to need on every request. This speeds up everything slightly, as what was previously done in 6-7 queries is now done in one shot. Should you want to, you can also specify additional preloaded pages, though I don't think many (any?) would need to. 

Several optimizations to the PageFinder engine which improves the speed of certain types of queries. One of them is a $pages->count("selector") query, which is now even faster than before. 

Selector Grouping

Added support for selector grouping to change the behavior of how they match. This is best explained by example. Lets say we're building a big news site, and we have a template called news-item that represents each news article. Each news-item page has a field called cats that is a multi-page reference to one or more category pages. This is a pretty common scenario in ProcessWire. The site has a lot of categories, so want to designate some categories as featured so that we can display featured categories on the homepage and elsewhere, with accompanying news items. Rather than just adding a featured checkbox, we add two fields to represent the date range that we want them featured: featured_from and featured_to. On our homepage, we want to display articles from all the current featured categories, so we build a selector like this:

$items = $pages->find("cats.featured_from<today, cats.featured_to>=today, sort=-date");

...but we end up with more news-items than we expect, including some that have categories that aren't actually featured right now. Why? Because each news-item can have multiple categories, and that selector above is saying this:

Find all news-item pages that have at least one category with a featured_from date before today, and at least one category with a featured_to date that is sometime in the future. 

The keywords there are "at least one", as "categories.featured_from" and "categories.featured_to" may not be referring to the same category. The only way to solve it was this:

$categories = $pages->find("template=category, featured_from<today, featured_to>=today"); 
$items = $pages->find("categories=$categories, sort=-date"); 

That's easy enough... but now you can also do it like this, by prepending an @ to identify a group:

$items = $pages->find("@cats.featured_from<today, @cats.featured_to>=today, sort=-date"); 

The "@" symbol at the beginning of "cats" is telling ProcessWire those are grouped together and "these must match the same exact page". 

This was added because there are situations where you need to perform your query with 1 selector rather than breaking it up. An example would be when used with the new InputfieldSelector module and Lister, among others. We will likely be adding more ways to perform complex matching scenarios with a single selector as well. Currently this "@" grouping applies only to multi-page reference fields, as I'm not sure yet where else it might be useful. It is only supported by selectors that hit the database at present (though will be completing it for in memory selectors as well). 

While you are on a roll, any thought about having an option to generate the name and the title from more than one other field. 

Not planning to extend it into that area at this time, but good ideas to think about for the future or for modules. 

is it possible to get the translation problem (in LanguageTranslator.php) fixed?

It should already be fixed. If we're talking about the same thing, someone recently posted this to the GitHub issues list and I added their fix on dev. 

EDIT2: Actually, I think there is still one potential issue - I still seem to be having the issue that a newly created page that is assigned a title but not a name ends up with "untitled" as the name. Does anyone else see this?

Adrian already knows this because we've been chatting in the GitHub issues queue, but for anyone else reading this, it has also been fixed.

[kongondo]

Thanks Ryan! The grouping feature is really cool!

[SiNNuT]

Great stuff Ryan!

[ryan]

Continuing from my previous post in this thread about some selector enhancements available on the dev branch, we've got a couple more advanced options for use in selectors in case anyone is interested: 

OR-groups

These let you specify multiple expressions and only one of them has to match in order for the selector to match. It's a way of saying "either this has to match OR that has to match". This is useful because selectors always assumed AND – meaning everything has to match. While you have always been able to use the pipe "|" to specify ORs for fields or values or both, the scope of it was just that field=value statement only. Now we have something new called OR-groups. These let you create multiple selector groups and only one of them has to match. You can specify OR-groups by surrounding selectors in parenthesis. An example demonstrates it best. Lets say that we wanted to find all "product" pages that were in stock, and either in a featured date range, or had a highlighted checkbox checked. Previously we would do like this with two separate find operations:

$items = $pages->find("template=product, stock>0, featured_from<=today, featured_to>=today"); 
$items->add($pages->find("template=product, stock>0, highlighted=1")); 

Now we can do it in one find operation: 

$items = $pages->find("template=product, stock>0, (featured_from<=today, featured_to>=today), (highlighted=1)"); 

Above are two selectors surrounded in parenthesis. Only one of them has to match. You can specify as many of them as you want. This type of OR expression is something you couldn't previously do with selectors. Think of the parenthesis as a way of saying "this is optional". But of course, at least one of your parenthesized selectors has to match in order for the full selector to match. 

I'm guessing the above usage probably covers 99% of the situations where you might need it. But lets say that you want to have different combinations of OR expressions. You can create named groups that OR with each-other by specifying: 

foo=(selector1), bar=(selector2), foo=(selector3), bar=(selector4)

In the above you'd replace "foo" and "bar" with names of your choice. And you'd replace the "selector" with any selector strings. Those foo/bar names aren't referring to fields, instead they are just named groups that you can name however you want. In that selector, at least one of the "foo" named selectors would have to match, and at least one of the "bar" named selectors would have to match. If you didn't use the foo/bar named groups here (but still used the parenthesis), then only one of the 4 selectors would be required to match. 

Sub-selectors

Some of you are already familiar with these because it was committed to the dev branch a couple weeks ago (and I think may have been outlined elsewhere in the forums). Sub-selectors let you put a selector within a selector, enabling you to perform more complex matches that used to require you to use separate API calls. These can be used on the 'id' property of any field that maps to a page. The 'id' property is assumed when referring to a page reference or a parent, so it's not necessary to specify it unless you want to, i.e. "field" and "field.id" mean the same thing in this case.

Sub-selectors are specified between [square brackets]. For example, lets say we are matching products and our product template has a "company" page field. Each company also has it's own page field where all the company locations are identified. Lets say we want to find all products that are made by a company that has more than 5 locations and at least one of those locations has "Finland" in the title. Previously we would have had to do it like this:

$companies = $pages->find("template=company, locations>5, locations.title%=Finland"); 
$items = $pages->find("template=product, company=$companies"); 

That's easy enough. But now it's even simpler, as you can do it in one operation: 

$items = $pages->find("template=product, company=[locations>5, locations.title%=Finland]");

When you've got a "field=[value]" selector, any properties you refer to in "[value]" assume the "field", so "locations" above is referring to a property of the "company" field. 

[owzim]

There are no words, really.

[cstevensjr]

As I normally say about the enhancements, Wow!

[MadeMyDay]

Getting wet a little. Again. Awesome.

[Pete]

Loving these additions ryan.

One question though - is it more efficient the old way (separate selectors) or the new way? Do these new options make a more efficient DB query (as in one with some joins instead of two in the case of sub selectors) or is there not much in it?

[ryan]

One question though - is it more efficient the old way (separate selectors) or the new way? Do these new options make a more efficient DB query (as in one with some joins instead of two in the case of sub selectors) or is there not much in it? 

It's more efficient to do it in one find() operation, using the new options available. When using two separate find operations, all the pages from the first find() operation have to be loaded. When you do it in one find(), then those pages don't have to be loaded. So it can actually be a whole lot more efficient, especially if dealing with larger scales. There is still some room for optimization so I'll be working on that, but regardless they should be a lot more efficient than multiple find operations. 

Another good reason to use OR-groups (and sub-selectors, depending on the case) would be for pagination. You really can't achieve paginated results very easily if splitting into multiple finds. 

[nik]

Ryan's on fire! There's nothing too big missing from the selector engine after this update anymore. But it seems like someone should start a whole new project on testing PW. My old project (on selectors mainly) has fallen way behind and I'm not sure it's a good basis for any broader testing. There's a lot of new stuff in place already and I'm sure there will be much more in the future, along with fixes and optimizations.

Regarding selector grouping from a while back:

Currently this "@" grouping applies only to multi-page reference fields, as I'm not sure yet where else it might be useful.

What about repeaters - if I'm not mistaken their not supported? This thread has an example of a situation where grouping would have made things a whole lot easier. And didn't try it out at all but I guess PageTable isn't supported either. I'm happy to ditch the rest of my repeaters if only PageTables would be supported in the future. 

[Manfred62]

a question to the last update (2.4.3):

the new option 'Disable multi-language descriptions' in the module InputfieldFile is only used for image fields. Correct?

[adrian]

a question to the last update (2.4.3):

the new option 'Disable multi-language descriptions' in the module InputfieldFile is only used for image fields. Correct?

I think so - check out this discussion:

https://github.com/ryancramerdesign/ProcessWire/issues/496

[apeisa]

Nik - PageTable supports @ convention.

[ryan]

My old project (on selectors mainly) has fallen way behind and I'm not sure it's a good basis for any broader testing. There's a lot of new stuff in place already and I'm sure there will be much more in the future, along with fixes and optimizations.

I still use your testing library every single day that I code PW. It covers all the most important scenarios, so isn't out of date at all. But I will plan to update the tests for the new selector options. 

What about repeaters - if I'm not mistaken their not supported? This thread has an example of a situation where grouping would have made things a whole lot easier. And didn't try it out at all but I guess PageTable isn't supported either. I'm happy to ditch the rest of my repeaters if only PageTables would be supported in the future. 

It is feasible to support with repeaters, and if there's demand for it I'll add it. PageTable supports them already just because PageTable delegates huge amounts of its functionality to FieldtypePage, including the implementation where the @ grouping option is supported. 

a question to the last update (2.4.3):

the new option 'Disable multi-language descriptions' in the module InputfieldFile is only used for image fields. Correct?

File or Image fields. File fields can have descriptions just like image fields can. 

[einsteinsboi]

WOW! Awesome.

[Manfred62]

anybody made the last update to dev 2.4.4? What do you think about the big icons?

[Martijn Geerts]

Font-awesome icons are build for 14px or a multiple of it, if you make them 18px or 20px they will be less sharp.  

Love the changes in 2.4.4 ! Thanks, Ryan.

[Manfred62]

@ryan

please take a look in this thread. There's something broken in dev 2.4.5 since last update.

• translation files will be renamed at upload
• also the headings in setup and access page are no more translated

[Manfred62]

PW dev 2.4.7:

in InputfieldSelector.module in line 657 missing _x(...

'adjust' => $this->_x('Adjustments', 'optgroup-label'),

also when using not actual version of DynamicRoles module, I got a 500 error after update. I removed the module manually. Then I could reach the site. Afterwards installed the newest version of DynamicRoles module. Now it's ok.

[Manfred62]

@ryan

while doing translations I found some small "gaps". Maybe you can close them?

under 'access/user/name-of-user' the folllowing heading and phrase is not translatable (found this phrase in /wire/core/install.sql, line 194)

Roles

User will inherit the permissions assigned to each role. You may assign multiple roles to a user. When accessing a page, the user will only inherit permissions from the roles that are also assigned to the page's template.

under 'access/roles/name-of-user' the heading "Permissions" is not translatable

===========================

under settings/templates we have a column for the "date of change". Maybe it's possible to make the translation strings more flexible?

These can be found in wire/core/Functions.php.

Example:

en --> 2 days ago

de --> 2 Tagen vor

es --> 2 dias hace

must be other word order:

de --> vor 2 Tagen

es --> hace 2 dias

[Manfred62]

made the update to 2.4.11.

Under "modules/new" there are now the fieldnames visible. Site and Core are not affected.

Also all modules are shown under new (because of the update of PW)?

See screenshot:

[apeisa]

Yep, that's good. I often forget to change module name (if I take boilerplate module or edit some existing one), so that will help finding the new module.