adrian

Just wondering about the output from $file->filesizeStr I have only used it once so far, but was surprised to see it return 10,375kB. I would rather have seen 10.4mB Not sure what others think, but I have always used this function and been happy with the output. Thanks for any feedback. function human_file_size($size) { if($size == 0) { return("0 Bytes"); } $filesizename = array(" Bytes", " KB", " MB", " GB", " TB", " PB", " EB", " ZB", " YB"); return round($size/pow(1024, ($i = floor(log($size, 1024)))), 1) . $filesizename[$i]; }

No problem - glad it turned out to be an easy fix !

I believe it was the Autocomplete field type. I expect you might have trouble changing it back to that, so you might have to create a new field from scratch with this type. I think you might also have to install the Autocomplete module to be able to create this field type. Hope that is of some help until you get a definitive answer from someone who knows for sure!

Sorry, I did what I always accuse other people of doing - not reading Thanks for the great explanation!

Hey Joss, Can you explain the page_select from this line that appears in the wiki article you posted. I can't see this selector mentioned anywhere else. $posts = $pages->find("page_select=$category");

You rock Soma - that's just what I wanted

Here's another one - show the name of a field in parentheses after the field label when editing a page in the admin. Maybe I am missing something, but I often have to go back to the fields view to find the actual name in those cases when the label is quite different from the name.

Ok, I have something that works. I am not sure how portable it is yet (I haven't really done any testing), but it seems to work well for my scenario. This is my entire search.php template file. Basically what it does is: Find all pages with the search term (as the standard search.php does) Iterate through all the fields within those returned pages to see if any pages within the $pages array have a name which matches any of the field names If there is a match, build the link using the name of the matching page in the path Add viewable() check to the standard pages found to prevent display of the People > links The key thing (if it's not obvious), is that you must name the field (in my case a checkbox for each of staff, affiliates, contractors to match the name of the page that displays them (the fake url).I know this won't work at all in many scenarios, and I have some ideas for making it more portable and be able to handle situations where you want to use an ASM to choose the categories, but in a rush, so this will do for now <?php $content = ''; $resultText = ''; $count = 0; if($q = $sanitizer->selectorValue($input->get->q)) { // Send our sanitized query 'q' variable to the whitelist where it will be // picked up and $content .=ed in the search box by the head.inc file. $input->whitelist('q', $q); // Search the title, body and sidebar fields for our query text. // Limit the results to 50 pages. // Exclude results that use the 'admin' template. $matches = $pages->find("title|body|summary%=$q, limit=50"); if(count($matches)) { foreach($matches as $m) { $pm = ''; foreach($m->fields as $field) { $corrected_fieldname = str_replace('_','-',$field->name); //To match page name $pagematches = $pages->find("name={$corrected_fieldname}"); $pagescount = count($pagematches); if($pagescount>0){ foreach($pagematches as $pm){ if($m->$field!=0){ $count++; $content .= "<li><p><a href='{$pm->url}{$m->name}/'>". (($pm->title!='') ? $pm->title . " > " : "") . $m->title . "</a><br />{$m->summary}</p></li>"; } } } } if($m->viewable()){ $content .= "<li><p><a href='{$m->url}'>". (($pm && $pm->title!='') ? $pm->title . " > " : "") . $m->title . "</a><br />{$m->summary}</p></li>"; $count++; } } $content .= "</ul>"; $resultText .= "<h2>Found $count pages matching your query:</h2>" . "<ul class='nav'>"; } else { $content .= "<h2>Sorry, no results were found.</h2>"; } } else { $content .= "<h2>Please enter a search term in the search box (upper right corner)</h2>"; } $content = $resultText . $content; include("./main.inc");

Thanks Macrura - very interested to see what you come up with. Conceptually I can't figure out the best way to go from the returned results, which actually 404 in my case because there is no template file for the actual page in the tree, to the working fake URL. I could set up custom replacements for these before returning the search results. This really should be trivial, but I guess I am looking for a more generic and portable solution. Part of the issue is that it would need to return more than one result - eg it would need to return links to: About > Staff > Partners > Affiliates > Partners > Contractors > even though the actual result returned from the $pages->find would simply be People > person. This could also be achieved for this case, but I have a couple of other completely separate taxonomy issues like this as well. Just starting to seem ugly. Without going the module route, I am wondering about maybe a field for the relevant templates that allows specifying the actual working (fake) URLs and building the search page to check these fields before returning results and return all the possible paths as results. Not sure how well I described that, but I think I have a working idea at least. I'll tackle this tomorrow and post when I have a working solution.

Just thinking out loud here. The idea for this comes from the inevitable page title changes that clients want as site development comes together. For this situation, I'd love to see the page name automatically change to match any changes to the page title while the site is still in dev mode. Here's another potential option that could be overridden: http://processwire.com/talk/topic/2694-cant-change-field-to-certain-types/ I am sure there are several other things that could also be tied into a dev mode setting. Anyone have any other ideas for different behavior that would be appropriate for this setting?

Right - I knew there was a reason

Thanks Nico - but how do we populate the $results array? How can any $pages->find selector actually find these "pages". Thinking bigger here, I wonder if it might be possible to create an 'alias' module. Using my example above, there would be a new template setting, so I would go to this setting for the staff, affiliates and contractors templates and define that they are aliases for the people template. Then any $pages->find would also search these and consider them as part of the standard page hierarchy. I wonder if the alternative template setting under advanced tab (requires $config->advanced true) could be of any use here? Not sure if my logic really holds up, but I think the concept could be great.

I have read through several posts on fake URLs (for want of a better term) and UrlSegments, but I didn't find anything talking about search results - maybe I just missed the key post! I have a database of people stored simply like this: People (template = people) --Joe Blogs (template = person) --Jane Doe (template = person) Within the 'person' template fields there is an ASM field that allows selection of several categories eg: staff, affiliate, contractor etc. All simple enough - I want to display these people under different menu items / taxonomy, eg: About > Staff > Partners > Affiliates > Partners > Contractors > Which is easy enough to handle with UrlSegments. But the main obstacle I am having is setting up the search template to return fake URL. I think I can probably make something work, but I feel like there should be an easier way to achieve what I want. The key thing of course is that certain people will appear in more than one fake URL, which is why I am going down this path in the first place, rather than simply storing them under their correct page hierarchy. Thanks for any thoughts

Hi Ryan, I am not sure whether this is easily possible within PW or not - perhaps someone else will chime in on that front. However, and maybe I am telling you something you already know, and maybe you have a specific scenario and a good reason for wanting this, but dashes in SEO friendly URLs are important as they are treated as a word separator. The other alternative that is usually used is an underscore, but it seems the general consensus is that dashes/hyphens are better. http://themetaq.com/articles/seo-under-scrutiny-are-hyphens-or-underscores-better-word-separators Sorry if this is all terribly obvious to you already

Not sure if this is a bug of sorts, or a misunderstanding on my part. For a template, if under the Family Tab I set: May pages using this template have children? = No If I go to the Access tab, there is still an active checkbox for "Add Children". It seems to me that the Family option should make the Access option not possible. It doesn't have any impact either way - the family setting overrides it as it should, but I think it perhaps the "Add Children" checkbox should be greyed out in this case. Maybe there is another scenario that I don't understand that means it should be active ?

Hey Soma - thank you - I looked at the advanced mode a few weeks ago when I first started with PW but the extra options seemed overwhelming at the time. Anyway, that worked a treat - but better than an extra, unneeded template php file as well as the ability to avoid needing to maintain changes to the fields for two separate templates. Anyway, great answer - thanks again!

Ok, bit of a hiatus on this issue, but I think I finally know what was going on - maybe! Because I was having to manually redefine $user (session not transferring), things were not properly in place for automatic saving of created_users_id when the page was saved - it was saving as the guest user. I haven't tested this yet, but I just stumbled across this setting "Allow the 'created user' to be changed on pages?" which apparently needs to be checked to ".... enable the $page->createdUser or $page->created_users_id fields to be saved via the API". I think that would then allow this to work: $page->created_users_id = $user_id; Since that project is now finished and the manual SQL approach worked, I probably won't bother to check, but thought it might help someone else. BTW, that setting is only available with $config->advanced set to true.

I am sure I am missing something (nothing new there ), but I have several very basic content pages which have one level of children. For these page I am using the basic-page template for the parent and the child. I want to make sure a user can't create grandchild, but I can't seem to figure out how. I have other pages on the site that use templates like 'news' with the child having 'news-item'. It is easy in this case because I can allow creation of children for the news, but not for the news-item template. Obviously I could change the 'basic-page' template to 'basic-page-parent' and then assign 'basic-page-child' to the children and set it up so that users can't create children on pages with the 'basic-page-child' template, but I feel like there should be an easier way. On the "What roles can access pages using this template (and those inheriting from it)?" page I'd expect to see an additional checkbox at the end: ROLE VIEW PAGES EDIT PAGES CREATE PAGES ADD CHILDREN ADD GRANDCHILDREN Is there currently some other way to control this without assigning a different template to the first child level? It's not a big deal, but seems like a little bit of an unnecessary complication. If I do I guess I can assign basic-page.php to both the parent and child versions of the template in the "Alternate Template Filename" field. Does that all make sense?

Yeah - it is a great module and great docs - for some reason, my brain just didn't think of that approach in this situation. I am actually using a combined template!= and max_levels set of options to achieve what I need.

That's actually a really great idea - I hadn't really noticed that option before. I think in my situation it will work perfectly. So many options, so little time

In the end I think it suited the purpose better to check against templates like this: "selector"=>"template!=person" because I don't want the children of certain pages to show in the menu - things like a staff directory for instance where each child page is a person and has the template 'person'.

Thanks Luis - also good options, but I was trying to doing it just through a PW selector so I could use the selector option that Soma built into the SimpleNav module. Turns out the '=0' in a selector works great, but I still actually ended up going with a different approach just because it made more sense in the current situation

kongondo - thanks! I couldn't use the approach you suggested, because I needed to use a PW selector within the nav module. But, even though I was sure I had tried it, I just tested a '=0' selector and it does indeed return all pages without that field checked. It returns all pages, whether they have the field in their template or not, you need to add an additional selector to limit results to a parent page, or perhaps a template. But it does work - not sure how I missed it before - tired brain I guess! As for '=' vs '==' - if you're using a PW selector it needs to be '='. If you are doing something in regular php it needs to be '==' or '===' depending on what you are comparing

Just a quick followup - I have decided to take a different approach to the problem, so I don't really need any specific help, but I'd still be curious to know if it's possible to use a selector to find all pages with unchecked instances of a checkbox.

Hi guys, I want a simple selector to test if a checkbox field is empty. hide_from_top_menu=1 works as expected and finds those that are checked, but hide_from_top_menu!=1 does not work - it returns nothing. Now I understand that there is no entry in the hide_from_top_menu field for a page until the checkbox is checked and I guess that is the problem. I am using this with MarkupSimpleNavigation. Obviously I can easily hack the code of the module to add in a check something like this: if($child->hide_from_top_menu != '1'){ but I feel like I should be able to achieve this more cleanly. Obviously I could also turn this field around to be "show_in_top_menu", but since there is no way to set default values for fields, I'd rather avoid having users have to check this for each new added page. Maybe not a big deal, but thought this might be an issue at a more general level Thanks!