ProcessWire Dev Branch

[maba]

@ryan in \wire\core\Functions.php

if(!wireChmod($dir->getPathname(), true, $chmod)) $numFails++;

should be 

if(!wireChmod($file->getPathname(), true, $chmod)) $numFails++;

when install e new module I got dir undefined warning with PW 2.3.11.

EDIT: issue on GitHub already fixed.

[Pete]

Oh now this looks super-useful: https://github.com/ryancramerdesign/ProcessWire/commit/e5847d667aa200d050815acf73abaeeb30c96493

[Martijn Geerts]

Oh now you're lookin super-clean Pete

[Soma]

Found this also today. Yiiipi. Lots to explain

[Mats]

Unable to toggle fields visibility in admin with the latest dev version.

Browser restart fixed it.

Edited January 22, 2014 by Mats

[Soma]

You may want to consider file an issue on github, as that is reather seen by Ryan and easier to manage:

https://github.com/ryancramerdesign/ProcessWire/issues?direction=desc&sort=created&state=open

[Mats]

Done.

Closed @ github..

Edited January 22, 2014 by Mats

[Manfred62]

some (translatable) strings in modules to fix (PW dev 2.3.13)

\wire\modules\Inputfield\InputfieldPageName\InputfieldPageName.module

line 206-210
$field->label = __("Character replacements");
		$field->description =
			__("Enter the replacements that will occur when a user is entering characters into a page name field. ") . 
			__("Enter one replacement per line in key=value format. ") . 
			__("Meaning, on each new line, enter the character(s) you want to replace followed by an equals sign '=' and the ascii character(s) you want to replace with.");

line 212
	$field->notes = __("The replacement value for each must be one or more of: a-z, 0-9, dash, underscore or period.");

\wire\modules\Fieldtype\FieldtypePage.module

line 739-740
	$inputfield->label = __('Find and clean orphaned page references'); 
	$inputfield->description = __('This cleans up for an issue in older versions of ProcessWire that could leave orphaned page references for deleted pages. If you are getting inaccurate results from page finding operations (especially with selectors using pageref.count), then you may want to run this.');

line 743
	$inputfield->notes = __('Warning: To be safe you should back-up your database before running this.');

\wire\modules\PageRender.module

line 391-392
	$f->label = __("Clear the Page Render Disk Cache?"); 
	$f->description = __("There are currently $numPages pages cached in $path");

EDIT:

\wire\modules\PageRender.module

line 392 is not translatable? Changing text in the translation doesn't show the new translated phrase in the module setting. It stays english.

\wire\modules\Process\ProcessPageSearch\ProcessPageSearch.module

starting at line 838 - 863

$inputfield->label = __("Default fields to search");
		$description = __("Enter the names for one or more text-based fields that you want to search, separating each by a space. ");
		$inputfield->description = $description; 
		$inputfields->append($inputfield);
		
		$inputfield = Wire::getFuel('modules')->get("InputfieldText");
		$inputfield->attr('name', 'searchFields2');
		if(!isset($data['searchFields2'])) $data['searchFields2'] = 'title';
		if(is_array($data['searchFields2'])) $data['searchFields2'] = implode(' ', $data['searchFields2']);
		$inputfield->attr('value', $data['searchFields2']);
		$inputfield->label = __("Field(s) to search in admin search (ajax) mode");
		$inputfield->description = $description;
		$inputfield->notes = __("We recommend limiting this to 1 or 2 fields at the most since results populate a live autocomplete field. Typically you would just search the 'title'.");
		$inputfields->append($inputfield);

		$inputfield = Wire::getFuel('modules')->get("InputfieldText");
		$inputfield->attr('name', 'displayField');
		$inputfield->attr('value', isset($data['displayField']) ? $data['displayField'] : 'name');
		$inputfield->label = __("Default field name(s) to display in search results");
		$inputfield->description = __("If specifying more than one field, separate each with a space.");
		$inputfields->append($inputfield);

		$inputfield = Wire::getFuel('modules')->get("InputfieldSelect");
		$inputfield->attr('name', 'operator');
		$inputfield->attr('value', isset($data['operator']) ? $data['operator'] : self::defaultOperator);
		$inputfield->label = __("Default search operator");

[ryan]

Thanks Manfred62, I have added these and will post them in the next batch of commits. I don't know why the PageRender.module one wouldn't be translatable--it should be. The variables needed to be abstracted out of the string with sprintf, which I have done. That may be what the issue was. 

[Manfred62]

beside the fact, the (above mentioned) strings aren't in the new 2.3.14 until now I tried something with the PageRender.module.

When using single quotes, the string is translated, but the variables dont work.

So I tried this concatenation

line 392
		$f->description = __("There are currently") . " " . $numPages . " " .
			          __("pages cached in") . " " . $path;

in this case I get 2 strings to translate, but it's functional.

[landitus]

I've just upgraded a new site I'm building and I'm pleased to say it all went smoothly. All modules worked perfectly and I'm still testing it with joy!

I'm loving the improvements on the new default Theme. I'm a designer myself so I'm hard to please. I haven't been following the new theme discussion lately but I wish to point out some things I came across.

Notifications

I found the notices/notifications very annoying as they push the page down depending on the quantity of such notifications. ProcessWire is quite verbose and the new design reminded me more of it. Kind of made it a little bit more annoying as well. Even more with intensive editing/usage.

I wonder if it could be a way to have like 2 levels of "verbosity": one more suitable for an editor and one for and admin. Maybe the editor just wants to see 1 notification for "page saved" or one with the errors in case they are any. The admin would see "field x saved, field x saved..." just like it today. I can see this setting an improvement to the UI and to the UX of content editors as wells. Also, the phrasing could be more user-friendly to editors/not techie people, just by removing the word "Session:" or using the fields titles instead of the names. Maybe it can be configured and haven't noticed it.  

Edited:

As WillyC pointed out, this only happens with debug mode on so it's not a problem for the client. My critique should focus on the UI pattern and not the notification system, then. 

Also, it could be possible to condense all notifications in one phrase and make it collapsible (like the Debug mode tools) with an arrow or gears icon that let's admins/anyone see all the notifications (fields saved, etc) related to the event (either saved-green/error-red). This would solve the annoying push down of the page when saving 10 images for example (this is a worst case scenario which I can see has been addressed already). But modifying 10 field gives you 10/11 green bands which is the same effect. Other solutions might be to place notifications where they were.

I guess there is a reason for this new change, but wanted to simply express my opinion on it. I found a client of mine panicking when seeing 10 green notifications over the screen. It almost seemed like an error, even though they were all successful notifications. I guess that the top notification/pushing down the page pattern is better suited for just for one line of text. Having a collapsible icon seems like a good solution to accommodate and further extend this UI pattern.

Let me know what you guys think!

Otherwise, everything looks sharp, fresher and more user-friendly so I'm very happy about it!! Congrats to everyone involved!

Edited

I made some quick concepts to see what it would look like. Certainly this is easier said than done (what isn't?). It looks simple but I maybe there are some situations/notifications I'm not considering. The idea, in fact is to simplify it to two possible messages (Success/Error) and make less intrusive. Each message can be expanded to see what has changed or which fields have errors. When having an error notification, one can simply scroll/scan the form to see which fields have errors anyway, so it's not necessary to expand the notification banner. 

This is just an idea and maybe it can be built upon it.

Edited February 1, 2014 by landitus

[landitus]

Just made a quick mockup to what I was referring! Maybe this issue is a little bit off-topic here. I'm sorry about that.

[WillyC]

dear land ,,

and u.needs to turner off debug modee

[landitus]

dear land ,,

and u.needs to turner off debug modee

WillyC,  that's great!!!!! I didn't realize that cause I'm in the DEV environment all the time. Perfect! At least for the client it won't be a problem as it's on the server with debug off. This is a relief. 

Notifications still annoys me while developing. The new debug tools ui is such a good example I'm keen on replicating the collapsible UI this for notifications. But guess is not such a priority as the client won't be flooded with messages. Either way, I stand by the notion the notifications UI is better as one line of text as it pushes the page down. It would a better UI IMHO  

[Wanze]

@Manfred62

in this case I get 2 strings to translate, but it's functional.

You can use php's sprintf function, so you only need one translation string:

$translationStr = __("There are currently %d pages cached in %s");
$f->description = sprintf($translationStr, $numberOfPages, $path);

[Manfred62]

@Manfred62

You can use php's sprintf function, so you only need one translation string:

$translationStr = __("There are currently %d pages cached in %s");
$f->description = sprintf($translationStr, $numberOfPages, $path);

thanks, good to know. But Ryan has already reworked this.

[ceberlin]

CONGRATULATIONS TO 2.4 !

An opportunity to thank Ryan and all contributors again for this wonderful software! 

[ryan]

Thanks ceberlin! This is just a soft launch of 2.4, as I've still got some items to cover before telling everyone about it. However, I was feeling that 2.4 is already a lot better and more stable than 2.3, and that there's just no reason to have people download 2.3 anymore. So 2.4 is now the stable version, but it will still be getting some minor incremental updates for a little while. For those upgrading, be sure to read the upgrade instructions and additional upgrade notes. 

[adrian]

Firstly wanted to say amazing job Ryan - PW just keeps getting more capable and powerful and it's a real pleasure being part of this community. I have never experienced anything else like it - so incredibly friendly and supportive. A far cry from so many others. Obviously a result of the tone and standards you set here.

Just a quick request - I am sure it is on your list, but it would be helpful to have 2.4 checkbox option in the modules directory sooner than later.

Thanks again for everything!

[ryan]

Good point Adrian. I've added 2.4, and also updated all the modules that are compatible with 2.3 to also indicate compatibility with 2.4. I think this is reasonably safe to assume (I haven't yet found any modules that aren't compatible with 2.4). I made a little bootstrapped script to do it for me… these are always fun ways to feel like you got some work done in 5 mins.

include('./index.php'); 
$v24 = wire('pages')->get('/versions/2.4/');
foreach(wire('pages')->find("pw_versions=/versions/2.3/") as $item) {
  $item->pw_versions->add($v24);
  $item->save('pw_versions', array('quiet' => true));
  echo $item->title . "<br>";
}

If anyone comes across any modules that they find not to be compatible with 2.4, please let me know so that I can update the directory. 

[ceberlin]

Just a tiny note:

The htaccess file could say "@version 2.4" in the title comment area now as well - that would avoid maybe questions from updaters...

[ryan]

I've added a feature on the 2.4 dev branch that several people have asked for in the past: 1-step adding of pages. 

To enable it: edit the template used by the parent where you want to support 1-step adding of children. In the 'Family' tab, in Allowed template(s) for Children choose the single template you want to be used for children. Once you do that, you'll see a new box appear below it, titled Name format for children. You can enter any text that you want here, and the page names will use it. If the name causes a collision with another page, then an incrementing number will be appended. You can also enter just the word title if you want it to base your page name on the title field (when you later populate it), or you can enter a PHP date format to base the page name on the current date and/or time. More details

This screenshot explains it all. Look at the "Allowed template(s) for children" field and the "Name format for children" field. 

There are drawbacks to 1-step adding of pages, which is the main reason we've not supported this in the past. The biggest drawback is that you can end up with a unused pages due to accidental clicks on an add page button. To reduce this problem ProcessWire assigns a temporary status to pages created this way (Page::statusTemp) that gets removed as soon as you save it the first time. Pages that remain statusTemp will be automatically moved to the trash after having that status for 1+ days. Of course, pages created this way also have Unpublished status, so they aren't going to be showing up on the front-end of your site until you publish them (like any other page you create). The second drawback is that you are skipping over the page naming step, so pages have to be named automatically (which is what the Name Format you specified is for). Of course, you can easily change the name to whatever you'd like from the 'Settings' tab of any page.  I've removed that drawback by adding the "title" option. When used, it populates your page with a temporary name and then re-populates it with your page title when you save.

For most situations, you'll probably still want to stick with the 2-step page adding process. But for situations where you'd find it worthwhile to have 1-step, you now have the option.

[Pete]

This sounds great and means I can do away with a custom module I use for this.

[ryan]

After writing it all up for that forum post, I wasn't satisfied with having to make edits to two templates in order to enable the feature. So I've gone back and re-done this feature. The instructions and screenshot have been updated (see my post above). Now you only have to edit one template, and all settings related to it are in the 'Family' tab. 

I've also added a "title" option, where it will auto-generate your page name from the title, just like you are probably used to. Because the title isn't yet known when the page is created, it assigns a temporary name to the page, then overwrites it once you give your page a title. 

[adrian]

This is sounding even cooler now 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. Like being able to concatenate first_name and last_name fields. I am thinking it would be great to be able to set the title to locked (visible but not editable) for the specific template. And once the page is saved, it (name and title) will be populated from the first_name and last_name fields.

Would that be much more work?