adrian

Firstly, if var_dump($page->verein_datum); returns int(1397253600) then the field is not blank - it is set to: Fri, 11 Apr 2014 22:00:00 GMT If it is actually empty, it is as simple as: if(!$page->verein_datum) { //date field is empty } but if you want, you could also do: if(empty($page->verein_datum)) { //date field is empty } or if($page->verein_datum === '') { //date field is empty }

Looks like Ryan is already onto this - maybe you should hold off for a day or two: https://github.com/ryancramerdesign/ProcessWire/commit/bd16deaf8f9e690fc47e91766e479550042eea5d Maybe also keep an eye on CSV import module (http://modules.processwire.com/modules/import-pages-csv/) to see when that gets updated, or maybe it will work already with those core mods in that recent commit - not sure!

I didn't have to do much - I really just fixed those issues you were having with the Edit Imported Content option when removing the images field. Also a little code to not rewrite the image tags and links in the RTE field if the images are not actually migrated across (because the images field wasn't included). You have already contributed significantly by adding comments support for MigratorWordpress! General PW ideas can be posted in the Wishlist board - I think this is likely the best place for module ideas too, but maybe also in the "Module/Plugin Development" sub-board?

The - vs _ is coming from the fact that the module makes use of $sanitizer->fieldName to convert the entered Label for the template into its name. fieldName doesn't allow dashes. I have committed a fix that should solve the mistake. Please let me know how it works for you now. As for the custom templates - it is really situation dependent, but I like it so that I can restrict the creation of new child pages to just one template so the site editors never have to choose the appropriate template when creating a new child page option.

That last update to Migrator that we have been discussing handles your desire to NOT migrate images, but rather point to the original source. If you need to do this until you can upgrade the server and then migrate the images, I am sure it wouldn't be too hard to steal some of the code from Migrator (in the idImagePath() function) to iterate through all the pages, download the images, and edit the links in the RTE fields. Let me know if you need any help with that when the time comes.

It shouldn't be possible - is one basic-page and the other basic_page ? Generally it is safer (although not always necessary) to have dedicated templates for the page tree of a pagefield. If the module is in fact creating duplicate templates, then that is something I need to fix for sure.

Here's another version that deals with the pagination issue you were getting. The problem is that it requires making a core method hookable that currently isn't. Obviously modifying the core is not a good idea and I am not sure that Ryan will want to make numChildren hookable - seems like a weird thing to want to change. I feel like there is a better option to achieve this, but as a proof of concept, this does work. If it works as expected for you, maybe I'll see if we can get Ryan's thoughts on this. So the first thing you need to do is go to wire/core/Page.php and make the numChildren function hookable by adding three underscores at the start, like: public function ___numChildren($selector = null) { Then use this module code: <?php /** * * * ProcessWire 2.x * Copyright (C) 2010 by Ryan Cramer * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://www.processwire.com * http://www.ryancramer.com * */ class HideOtherUserPages extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'HideOtherUserPages', 'author' => 'Adrian Jones', 'version' => 1, 'singular' => true, 'autoload' => true ); } public function init() { // only add hook only if the render parameter is set // (as used by ProcessPageList) // or if superuser, also exit //if(!isset($_GET['render']) || $this->user->isSuperuser()) return; if(!isset($_GET['render'])) return; $this->addHookAfter('ProcessPageList::find', $this, 'pageListHiddenPages'); $this->addHookAfter('Page::numChildren', $this, 'pageListCountPages'); } public function pageListCountPages(HookEvent $event){ $page = $event->object; $i = 0; foreach($page->children() as $p) { if($page->name != 'visitenkarte') continue; if($p->name != $this->user->name) $i++; } $event->return = $event->return - $i; } public function pageListHiddenPages(HookEvent $event){ $pages = $event->return; // make sure it's an ajax request if($this->config->ajax){ // manipulate the json returned and remove any pages found from array foreach($pages as $p) { if($p->parent->name != 'visitenkarte') continue; if($p->name != $this->user->name) $pages->remove($p); } $event->return = $pages; } } }

If the parent template settings are allowing pages with the parent template to have children with the child template and the child template settings are allowing creation of new pages under a parent page with the parent template, then it should all work fine. Sorry, that is a confusing sentence Regardless, it shouldn't matter whether all these pages and templates with created manually or with Page Field Select Creator. Any chance this site is live somewhere that I could log in and take a look for you? Otherwise, perhaps you could export the two templates for me so I can replicate things. You could do this via the built in Export functionality on the main templates page, or using Migrator (https://github.com/adrianbj/ProcessMigrator).

Hi there - I am having trouble following exactly, but Page Field Select Creator sets up the templates for the pages it creates with a setting the "Can this template be used for new pages?" set to "No". This is intentional because I like the trees of pages used for my page fields to have unique parent and child templates. The other settings that are automatically set are to limit the children of the parent page template to just those of the created children. This enables the "Allow new pages to be created from field?" setting to work. I also don't usually allow more than one child template for a parent template as I think it can confuse site editors, but others may not agree here. Sorry, I am answering this in a hurry, but if you change the "Can this template be used for new pages?" to Yes, I think it should solve what you are looking for, although I am not convinced I have got the issue exactly right, despite you detailed explanation Just to clarify - you are using this module for create page fields, rather than general page trees? If you just want to create/edit page trees, check out Batch Child Editor.

Just wanted to thank Sephiroth for helping out here. I am PM'ing with Manlio now and we'll get the template error sorted out, which should take care of everything else I think. Let's continue the rest of this conversation in the Migrator thread.

@manlio - sorry for the rough first experience with Migrator - any chance you could PM me the zip package you are trying to import? @Septhiroth - good catch, and yes, PR's are always very welcome - thanks

Ryan doesn't increase the point version number with every commit, so your best option is to subscribe to the dev RSS feed: https://github.com/ryancramerdesign/ProcessWire/commits/dev.atom

Welcome to PW!! You pretty much had it $matches = $pages->find("somefield*={$page->title}"); $page is always the current page. You can't have spaces within each part of the selector, so I remove the spaces around: *= Remember that if you are "find"ing you will end up with an array of results, not just one, so you need to decide how to handle these. The usual approach is to foreach through them. So you would then: foreach($matches at $match){ echo "<li>{$match->title}</li>"; } or something along those lines.

I know this thread is old, but with the new Log viewer that Ryan just set up, I have started putting the following just before the body close tag (in main.inc or foot.inc or wherever needed so it is on all pages): if($user->isSuperuser()) echo '<iframe width="100%" height="200px" src="'.$config->urls->admin.'/setup/logs/view/debug/?modal=1"></iframe>'; Then whenever I need to log a variable or output of a function etc, I use the following in my template file: $log->save('debug', $problem_variable); If you need to output an array, json_encode is quite a nice solution: $log->save('debug', json_encode($array)); This will give you (as superuser) a panel showing the "debug" log output (which shows latest entries at the top) at the bottom of your site - very handy

I didn't think about the pagination issue. I am not sure there is an easy fix for that with the current options for hooking into ProcessPageList Just out of interest though, here is a new version that uses ProcessPageList::find as the hook - it simplifies some things quite a lot, but still doesn't fix the pagination issue <?php /** * * * ProcessWire 2.x * Copyright (C) 2010 by Ryan Cramer * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://www.processwire.com * http://www.ryancramer.com * */ class HideOtherUserPages extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'HideOtherUserPages', 'author' => 'Adrian Jones', 'version' => 1, 'singular' => true, 'autoload' => true ); } public function init() { // only add hook only if the render parameter is set // (as used by ProcessPageList) // or if superuser, also exit if(!isset($_GET['render']) || $this->user->isSuperuser()) return; $this->addHookAfter('ProcessPageList::find', $this, 'pageListHiddenPages'); } public function pageListHiddenPages(HookEvent $event){ $pages = $event->return; // make sure it's an ajax request if($this->config->ajax){ // manipulate the json returned and remove any pages found from array foreach($pages as $p) { if($p->parent->name != 'visitenkarte') continue; if($p->name != $this->user->name) $pages->remove($p); } $event->return = $pages; } } }

Glad it works as you want! If you remove that line, then you will hide all pages on your site, because there won't be any direct children of Home that match the name of the current user. One other useful variation you might want to experiment with would be to replace: if($c->name != $this->user->name) unset($json['children'][$key]); with: if($c->createdUser != $this->user) unset($json['children'][$key]); which would hide pages that weren't created by the current logged in user.

How about this: https://gist.github.com/adrianbj/6fd1b770d9ce7a7252b6 It hides pages that don't match the user's name unless you are logged in as a superuser. It is currently hardcoded to only check pages with parent named: visitenkarte Does that work for you?

Sorry about the "front-end viewing" text - that is a leftover from my Page Protector module, which this new module is based off. This module definitely only hides the page and its branch from the tree. Try it out. Keep in mind though that with this module it doesn't have anything to do with whether a user has permission to edit a page or not - it is a manual way to determine the pages that aren't visible for a user role. Did you take a look at the module at this gist: https://gist.github.com/adrianbj/e391e2e343c5620d0720 This should mostly do what you want in terms of hiding pages that aren't editable. I just haven't dealt with the issues of a page tree with many levels. It should work perfectly if there are only two levels below home.

It's all fixed in the latest PW dev version. Martijn worked out one fix, but I think in the end Ryan solved the problem in a different way: https://github.com/ryancramerdesign/ProcessWire/commit/5575ef62bb1695d98162bc3278b8d39bb66433b2#diff-995c5c9ce48d4bff459f52363c6e190eR401

I love this idea the ability to drag all fields into any template all on one screen. Also great

That would be great Peter - I think post them here - see if we can get input from everyone.

Here is a very very rough start on the idea of batch template confguration: https://processwire.com/talk/topic/8406-set-multiple-templates-role-access/?p=81711 There is a lot of thought that needs to go into doing this properly - at some point (if no-one beats me to it) I would like to build a really comprehensive tool, but not sure when I will get to it!

Sorry to hear - hope you get it sorted quickly! Correct - at the moment the new functionality is for creating new fields from the template config. As we discussed above - not sure how useful it would be to have the ability to assign fields to templates from the field config - if you want to assign to multiple templates at once, how would you order the field in all those new templates. Maybe it would be possible if you were adding the field to just one template - a modal could maybe handle this. Any thoughts on how to practically achieve what you are looking for from a UI perspective?

Ask and you shall receive! Check out today's dev commits https://github.com/ryancramerdesign/ProcessWire/commits/dev "Add Adrian's ProcessTemplateFieldCreator for quick access to create new fields in ProcessTemplate."

You can do this though: echo '<strong>"Project Managers":</strong>' . my_function($page->projects_managers) . "\r"; In words - you can mix single and double quotes in the same statement. In my theoretical example above I wanted "Project Managers" to be echoed in double quotes, then run a function on $page->project_managers, hence the concatenation, and then use an escaped "\r", which is why I switched from single quotes to double quotes in the same echo statement. EDIT: Of course you could always use double quotes and escape as needed like below, but I like the above version better: echo "<strong>\"Project Managers\":</strong>" . my_function($page->projects_managers) . "\r";