Soma

Hmm, I see. Now it's a little clearer. But how do you know all the values those fields can have? This is a critical point. If not known, you theres one option to loop all those pages and collect field -> values, while the nested array with the same values as the key will get incremented instead of added. I think the fields (their names) at least is something to be known. $someFields = array("title", "headline"); $somePages = $pages->find("template=basic-page, category=phones"); // just something $resultArray = array(); foreach($somePages as $p) foreach($someFields as $field) if(isset($resultArray[$field][$p->$field])) $resultArray[$field][$p->$field]++; else $resultArray[$field][$p->$field] = 1; print_r($resultArray); foreach($resultArray as $field => $values) foreach($values as $value => $count) echo "<p>$field - $value: $count</p>"; The amount of field values is the one of unique ones, while their values is the count found. There's no PW distinct selector for fields unfortunately to count pages like that without knowing all the values, though there would be ways to do it with raw sql query for sure. But then you'd have to account for a couple things like is the page published and such. This of course can be a a heavy method once you need to loop thousands of pages on every page request. So always good to be careful and try to find way to minimize the load. There's also ways to cache snippets and store things to pages to load from and update them frequently using cronjob or hooks.

Looks good to me to uncacheAll pages to make sure you get newly fetched page. But I'm surprised this is needed at all here. But then I think I maybe don't really understand all context and what uncacheAll() does really. Are pages cached across other processes/requests and scripts?

If you have the LanguageSupportPageNames module (looks like) installed, you can configure the /en/ part on the root page name for each language.

Use parents() or closest(). If those color pages have a own template use that in the selector for closest() or parents(). Or parents()->eq(n) where n is the level of color pages.

Even after reading your posts multiple times I don't understand a single thing. I doubt you'll find someone understanding what you want to do. Too abstract and not a comprehent case. After all it may help to understand if you actually tell the guys here what you need to achieve, rather than I need count field01 => valueX. It could be that you go completely wrong about doing something.

I'm also in with a little inspection and think there might be solider ways to do it. But this is now sponsored?

Nope there isn't. These days we don't use captcha's since a long time. What is there already in InputfieldForm is a CSRF token validation. For spam prevention we use a honeypot or a reverse honeypot.

$user->isLoggedin() shouldn't be necessary here as $page->editable() already checks for various permission etc. So maybe do you have the guest role given page edit access? What happens if you click the link? Well I'm waiting for a facepalm here cause it's not possible.

$field->attr("disabled", "disabled");

Nope. No idea. Is it cached? Although it wouldn't get cached when logged in. Any third party modules modifying Page::editable?

@choppingblock You surely don't want to modify anything in there. I'm not sure where the subdomain is coming from. Do you have a $config->httpHosts with the subdomain in your config.php? Also not sure what you want to modify? It's all there [domain - Edit Page : pagetitle]

What diogo said. If you really need a fieldtype to do ajax internally you best create a hidden admin page with a process module to handle all that. Not overkill but a well streamlined approach, and makes it solid and easy, also the admin URL that way is sure to be unique throughout the system. Gives an interface that is well defined. Process pages are meant for that and PW uses it also in some places like Page tree and fieldtypes. If you will you can of course always catch and bypass the requested url in a module init. Something like public function init() { $adminUrl = ltrim($this->config->urls->admin, "/"); if($this->input->get->it == $adminUrl . "testmodule/load"){ echo $this->executeLoad(); exit; } } protected function executeLoad(){ $id = $this->input->get->id; return $this->pages->get((int)$id)->title; } And a js ajax request might look like $(function(){ $.ajax({ type: 'get', url: "/processwire/testmodule/load", data: "id=1001", success: function(data){ alert(data); } }); }); But I don't know if that's really a good idea at all. Just because you can doesn't mean it's good.

You would use a after Page::deleteReady hook to fetch the page that's going to be deleted. This hook is called when page is deletable and actually WILL get deleted right after. $this->addHook("Class:method", $this, "someMethod"); is to add a new method to a class with a hook. You would give it addHookAfter or addHookBefore.

has_parent isn't supported for runtime filtering with a path, not("selector") is filtering the results from the returned WireArray, there "has_parent" isn't supported in the same way as in a find selector. There's a path is converted to the ID before running the query. Regarding performance and such your second example is the way to go.

CSV import doesn't require a csv file, you can simply use the manual textfield ... enter title like by line... I found to be the fastest way to create pages.

You may better use Import CSV to pages module by Ryan then.

No need to post in two threads the same question. It has an effect but only for backend and in backend only user language defined in profile is used. The locale is set in LanguageSupport.module init(), and Front-end language is determined in LanguageSupportPageNames.module in ready() which is way later than the locale. I'm not sure it's possible to change that easily as language in backend and it's locale needs to be set early that various parts are translated (at least I think). Language support on front-end works different and is an "after thought" in that it's build with hooks. But maybe some locale setting there in LanguageSupportPageNames would fix it but then we'd have redundant settings. Also setting the locale in the backend has or had various issues with floats and date's as php date strtotime can't handle localized date strings, and floats , or . php also has problems. So I found it's easier and more convenient to set the locale as you did in the template, I use that too. I find it to cumbersome to set locale in a file somewhere hidden.

The level isn't supported as a placeholder, but you could add a hook to it and since "interation" is a updated property in the module you can use that to get the level without adding more overhead. // module load $nav = $modules->MarkupSimpleNavigation; // add hook to before parsing of the "inner_tpl" opening tag $nav->addHookBefore("getInnerStringOpen", null, function($event){ // get the current level $level = $event->object->iteration; // "<ul class='level-{level}'>" $tpl = $event->arguments("tpl"); // replace {level} with number and send tpl back to the argument $event->setArgument("tpl", str_replace("{level}", $level, $tpl)); }); // render navigation output echo $nav->render(array( 'max_levels' => 3, 'outer_tpl' => "<ul class='level-1'>||</ul>", 'inner_tpl' => "<ul class='level-{level}'>||</ul>", )); Since the opening tpl doesn't support parsing but only is used once, you can add the level-1 fixed. Also wanted to point out that these classes are something not really needed as you can do it via CSS ul { (level1) } ul ul { (level2) } ul ul ul { (level3) }

Just read again, and what you say is already like this. ProcessPageList is a module used by other like InputfieldPageListSelect. You could also used it in your module. But as you see even in other places it just works even if never was intentional to be used on front-end. Parent can be set also using $config->js Edit: Corrected my example above, as the $config->js(...) part isn't needed to configure. That's what the module does, I just had some order wrong. First call execute, then output the $config->js. Or like kongondo demonstrated for in modules.

I'm here. Too much distraction

Every module is sort of standalone more or less. But I don't see the PageTree being very useful for front-end as it's built for the backend usage. It's geared a lot towards PW admin usage and not meant as a tree like other plugins out there jQueryJSTree. Though as with most in PW it's fairly easy get a admin page tree working in your templates. After all the backend also is just a website. PageTree need the css, js and a js config to work. So it would work like this but on only show pages when logged in of course. Admin processes aren't accessible for not logged in users and PageTree uses ajax. <?php /** * Page template * */ // load page list module $tree = $modules->ProcessPageList; $tree->id = 1001; $output = $tree->execute(); include("./head.inc"); // output the container markup, the rest does the js echo $ouput; And head.inc would need this to autoload assets and write the config js. <script type="text/javascript"> <?php $jsConfig = $config->js(); $jsConfig['debug'] = $config->debug; $jsConfig['urls'] = array( 'root' => $config->urls->root ); ?> var config = <?php echo json_encode($jsConfig); ?>; </script> <?php foreach($config->styles->unique() as $file) echo "\n\t<link type='text/css' href='$file' rel='stylesheet' />"; ?> <?php foreach($config->scripts->unique() as $file) echo "\n\t<script type='text/javascript' src='$file'></script>"; ?> Edited for simpler version.

Yeah I was speaking about things only visible to devs, but it would feel odd and there's no clear line or hard to see/know, so as said the modules title makes sense to me not to translate. This wouldn't be too bad as everyone would be speaking of "ModulesManager" and not "ErweiterungsVerwalter".

I find it very confusing to have everything in the backend translated. The modules especially or at least the titles shouldn't be translated, it makes it vey hard to communicate and will split devs by language. Once we discussed about translations in admin when it was newly introduced, and wanted to at least translated everything an editor would use and haven't put focus on admin parts. I was about to write a lengthy post about dev's should at least know some english... but screwed it, and don't know what to think of it and thought ok I still can set my admin user language to english! Hah! Well doesn't work cause my project has default german and there's no english only french and italian. Now I can't get the english back and am constantly looking for modules. I need some way to turn it off or something. If only would now how. Edit: To go further there's no translated version of those module on the internet, the repo is english only. (including core ones)