Soma

The get() in InputfieldWrapper is assuming to get a field by name and is not using a selector like a find. /** * By default, calls to get() are finding a child Inputfield based on the name attribute * */ public function get($key) { if($inputfield = $this->getChildByName($key)) return $inputfield; if($this->fuel($key)) return $this->fuel($key); if($key == 'children') return $this->children; if(($value = parent::get($key)) !== null) return $value; return null; } You could also do $form->find("type=submit")->first->name;

The endless link appending is because of the dot ./kontakt/ ... remove the dot and save a query.

I love the spice girls!

I was trying with my 160k testinstall Diogo's code doesn't work really as it has no correct start value and that would be something like the page's position in the result - 2 or something. So I tried with diogos approach and came up with adding a url segment to each article link in the list like /articleurl/1 to be able to get the position on the article page. //That would generate the list $session->list_selector = "template=news-entry, summary*=europa, sort=-date"; $limit = 10; $list = $pages->find( $session->list_selector . ", limit=$limit"); $start = $input->pageNum ? $limit * ($input->pageNum - 1) : 1; // $input->pageNum is the page from pagination foreach ($list as $key => $p) { $pos = $start + $key + 1; echo "<li><a href='$p->url{$pos}'>$p->title</a></li>"; // add position to the url } echo $list->renderPager(); And on the article page if($session->list_selector && $input->urlSegment1) { $pos = (int) $input->urlSegment1; if(!$pos) return; $limit = 3; $start = $pos == 1 ? 0 : $pos - 2; $selector = "{$session->list_selector}, start={$start}, limit={$limit}"; $array = $pages->find( $selector ); $prev = $page->prev($array); $next = $page->next($array); if($prev->id) echo "<a href='" . $prev->url . ($pos-1) . "'>Prev</a> "; if($next->id) echo "<a href='" . $next->url . ($pos+1) . "'>Next</a> "; } Works fine with a search with about (7) thousands of results in about 0.1 - 0.2 sec. This would be cacheable if you even construct the url using the category (if that's what you filter for only) and have those even cached results (hence own url). Another approach would be to cache a text file with the result (to not store big amount of data in session) and save and load that depending on the filter. A delimited list of ID's and use it to search to get the prev and next item in the list. Not sure this would complicate things but then the DB don't need to query each time (if that's at all a problem.)

Or what about? $navigation = $page->siblings; or $navigation = $page->parent->children; Your both codes are the same if {$page->parent->name} returns "browse"

IS that the real path or jus one segment. What if you try to get it with pages->get('/name/') to test instead of find.

No PW isn't smart enough. But you. If that a on front end you just save the field and done. It's in your hand to page->save(field).

Pager only works for single queries and not for arrays in memory or modified ones l. If you manipulate the arrangements after the find it doesn't work. You could set start limit and totals manually but then you'd have to load all first in a find without a limit. Works fine for smaller amounts.

Your first post code works with if you remove the start=11.

Have you enabled Page Numbers on template?

Ah sorry, a form object is a InputfieldWrapper which is a special Inputfield, but it has Inputfields that are part of the InputfieldArray (defined at top of /wire/core/InputfieldWrapper). That's why replace(a,b) is not there for a form object. No you don't have to set it, just modify the field object and done, it's an instance and not a copy. Just as a hint. When doing all this form manipulation, just keep in mind that fields could be nested in case of fieldsets containing fields. There's also $form->get("fieldset_details")->children() etc... But you could also get a flat presentation of the inputfields with $inputfieldsArray = $form->getAll(); though not positive it's useful in your case. That should work fine.

Output formatting is off because we are in the back-end. Pages loaded in any a module have it off, it's only on in front-end context. All normal, and no problem turning it on if needed.

Yah as you speak $form->get('field') or find.. Basically it's a WireArray. Rings a bell?

Cache field is for text only.

I don't know what "dynamic behavior" you have there, but then you need some way to execute the same find query as on the listing page.

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.