Soma

If you specify what templates you search you don't need to logout. And its faster being specific.

If you don't have include=all in your selector, there's no need for has_parent!=2. If a visitor (guest) user searches it won't return those in admin anyway, only for superusers. It's generally a good approach to specify templates you actually want to search only. Also you can only have one "has_parent!=2" in the selector, so you couldn't use it for if you need it to restrict a search to a branch. I don't think there's one simple answer to building a search like this. I'm not sure about what exactly are the details here, and what is important to be able to search. It really comes down to what field you search and how. Relevance, as far as I know only works with a single find(), using full text search on a single text field using * or ~ , this will return the results sorted by relevance already, everything else won't give you relevance. By the glimpse at your code there's would be a lot of overhead and using this approach won't ever give you a relevance search results. Of topic: if (count($word)>3){ you can't count string only arrays if(!$matches) This doesn't work. A PageArray if empty doesn't return false, you'd check with if(!count($matches)) So what to do? I don't know an answer to what you should do. In general you seem too have a lot of fields, that seems unnecessary and could be simplified and reused, instead of having 3 "xname_description" fields, you could have one "description" field and use it everywhere. This will help reduce the fields to search for at least. Building search once you enter a complex setup with lots of fields and pages and want ot have relevance you might be best up to create indexes, like the cache field to combine text fields to one (hidden) cache field, that you would then search with a single query.

No need to store something here ... $pa = $pages->find("template=basic-page"); $content .= $pa->render(); $content .= "<a href='{$page->prev($pa)->url}'>prev</a> "; $content .= "<a href='{$page->next($pa)->url}'>next</a> "; This is the same on all those pages, as they use the same template. Works fine.

User pages are not allowed outside users folder.

Use pagefield->removeAll() first then add them back.

Sorry adrian, forgot about it, but hear you. Good thinking, just no time ATM. Maybe also add it on github.

https://www.google.ch/search?q=processwire.com%20active%20language%20api&rct=j First result

https://processwire.com/talk/topic/4383-how-to-set-language-active-via-api/

Thanks you both for the great effort keeping with the enormous pace! I just dropped the pack on a 2.5 installation I'm working ATM and looks good so far, will try to report if I find something.

You'll never see onboard instructions on a Formel1 car.

Such calls should never been put in the init.php (well you have to be careful). If you use render inside your template to render partials for example the init will get called each time. Anyway you should add your hook in a autoload module. See HelloWorld.module.

You can't I guess. PW needs those helper classes. After all it's never intended to be used for front-end. So expect some compromises.

You can also search repeater direct and get the page they're on. Look how the repeater template is named and use that $selector = "template=repeater-chalet, ..."; then on the result $chaletpage = $repeaterpage->getForPage();

Something like when you click on "more" on the cheatsheet items -> ie. http://cheatsheet.processwire.com/pages/built-in-methods-reference/pages-find-selector/ ?

OT: Then you don't think my PW cheatsheet filter is good and right? BT: I don't know what the problem with sorting should be here is (or maybe I don't understand your words). Ohhh you can do all sort of crazy thing. $pages->find("template=basic-page")->find("title*=solala")->find("featured=1"); $pages->find("template=basic-page")->filter("title*=solala"); $arr = $pages->find("template=basic-page"); $arr2 = $pages->find("template=user"); $arr->add($arr2); $res = $arr->find("title*=blabla"); $res->sort("-field");

I'm not sure what that should be for solving the problem. Anyway before it gets out of hand. $templates is a template system variable, you empty it on first line... If then you could do such a task like: $tpls = $templates->find("name=basic-page|sitemap"); foreach($tpls as $t){ $t->fields->add("myfield"); ... } You can also do this $t = $templates->get("basic-page"); $t->fields->insertBefore( $fields->myfield1, $t->fields->images ); $t->fields->insertAfter( $fields->myfield2, $t->fields->images ); $t->fields->save();

I find it strange that a CMS has no link (or link list) feature. After all it's about links. I also would be many times in need for a repeater style slick link field. Thing is it can get really tricky really fast to build such a module especially if you need to be able to either enter url, select a internal page, have attributes like open in new window etc. Then maybe need something to enter linktext (also multilanguage), and then maybe even the urls should be different for each language. I solved it with either - repeater - just have them make the list in wysywg - markdown textarea (kinda hard for clients) If I'm lucky and there's only one link required, I solved it using a text language field, a page reference, and a url field. And handle it on template output. Maybe we can sponsor a link (list) tool.

How about http://modules.processwire.com/modules/page-references-tab/ If you reference one page with another (with a page field) why do you need to reference back? You can easily use the reference in both directions.

url is a method and not a property. You'd need to hook Page:path to change url.

Just to add to the confusion. - You can make the title field not required in template context. - You can set a template to not include global fields (advanced settings) So you could remove title for that template but still have title global.

I have no idea to be honest. Works fine here. But I'm not using InputfieldImage but InputfieldFile.

You can easily make the module your own and add or change things. This would be totally the way to go here I think. I think Ryan don't really have plans to go on with the module and was more an simple example how to build a simple form using a template. --- With hooks if interested read on (little tricky to get it done) --- Removed code. Screw it , it won't work cause how the module is built. It won't allow to easily hook the form processing that happens in the ___render(). It's better after all to either change the module to your needs or add honeypot support and do a pull request maybe.

@lostkobrakai, you many read this thread again as this has come up multiple times (not only in this thread) from around here https://processwire.com/talk/topic/2089-create-simple-forms-using-api/page-5 or just scan the whole thread as it's full of this. There's also some gist examples https://gist.github.com/somatonic/5236008