adrian

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!

Just wanted to say thinks for this - another nice little time saver and works great direct from templates - check if a field already has content and if it's empty use the lorem text instead of the field. Just one thing - the classname is incorrect in the modules directory: MarkupLorenIpsum That probably explains why I get this error when trying to install from the modules manager: TemplateFile: Could not open zip file Manual installation worked great

Soma - sorry, been absolutely swamped. I reinstalled with the ModulesManager. Weird thing is that this is the second time it has happened, on the same server. It is the only module that has caused me any installation problems. Next time I go to install it I'll be sure to do some debugging. The server is one I manage myself and I think it is configured ok

Not sure whether it is something related to my system, but the last two sites I have tried to install this on (using the modules manager), it has failed and prevented the site from loading at all. All I have to do to fix it is delete the module folder from the server, reload the PW admin and then install it again and everything is fine. Sorry I don't have any useful debugging info, but if someone else has this problem as well, it might be worth investigating.

Thanks Joss, What I have actually ended up doing is using the example.html file from KS as a starting point and using that as my main.inc and everything is working beautifully I guess Ryan's example was before some significant KS changes.

Has anyone used Ryan's converted example.html (http://processwire.com/talk/topic/2731-how-can-i-integrate-html-kickstarter-with-processwire/?p=26612)? I thought I'd give kickstart a go for a new project, but none of the new responsive goodness works properly. I'll have a play and sort it out, but thought if someone else might have already sorted this out

Good reminder, thanks! I am so used to sanitizing in pure PHP, but sometimes I forget with PW - I tend to assume it takes care of absolutely everything for you And yes, also good to use "get" so it's not emulating "request"

Beautiful diogo - I should have delved into the structure of the tags field to figure that out. Thanks! Also Macrura73, thanks for making the point about sorting the array at the end! On a more general level though I assume there is no way to use separate operators on different fields within a selector? I guess this is where you have to follow the approach of combining the results of two queries?

Thanks, that does the job just fine! I would like to know if there is an option for doing it in one find statement though, just for simplicity's sake, although perhaps it really isn't that important in the end!

Hi everyone, Hopefully a quick question. I am trying to search through all pages by a keyword that is in any of the following fields: title, summary, tags The first two on their own are easy, as is the last on its own, but I am having a problem combining things to search through all fields because of the nature of the tags field I can't figure out quite how. $images = $pages->get("/visuals/")->find("summary|title~={$input->q}, tags={$input->q}, sort=title"); That code forces the keyword to be in both summary|title and tags. Thanks for any ideas!

n0sleeves, The reason the link from the logo always goes to the current page is because the href is blank. Have a look at the HTML source of rendered pages. This is what appears in your source code. <a href=""><div id="logo" class="center"><img src="/site/assets/images/logo2.png"></div></a> So firstly you have the href inside the div tags - this is not valid HTML as it is. Something like this should do what you want. <div id="logo" class="center"><a href="<?php echo $config->urls->root; ?>"><img src="/site/assets/images/logo2.png"></a></div> Or you could quite easily just go with: <div id="logo" class="center"><a href="/"><img src="/site/assets/images/logo2.png"></a></div> since it is to the root. Using $config->urls->root is useful as a starting point to build onto when making a URL to a lower level, but for root I think it is probably superfluous. Hope that helps.

Hi Peter - a quick answer from a relative PW newbie - I would go with the github version to ensure you get 2.3. I am using it in production, as I think are many folks. It has lots of great new features. Agreed it does seem a little confusing as to which is the current stable version.

Samuel, The field is automatically part of every page. You can simply echo $page->created_users_id There is also a $page->modified_users_id