Soma

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)

Is this using FormBuilder?

And soon here too http://cheatsheet.processwire.com/pagearray-wirearray/setting-and-modifying-items/replace-itema-itemb/

Yep here http://cheatsheet.processwire.com/?filter=replace&advanced and here https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/WireArray.php#L247

I don't think all those module should be Process modules, only the ProcessDiagnostics. But I found many choose Process for every module they make. IMO they're server a purpose and should be used for custom admin pages. Also I'm not sure what the module diagnostics does and what is useful for and if it really belongs here. ModulesManager and core modules are dedicated for that task and this way we scatter it in multiple places instead of having it in one place.

Just pulled in latest dev and suddenly some details meets my eye on module screen. Hurray!

Great one. I was thinking about having this is PW just a couple days ago... and if you wait long enough someone else will do it I think this would be a must have in Core.

This can be a tricky task if you want to do it right. Depending on the structure of the data/pages there's a lot to be considered and there's many parts playing together HML CSS JS PHP. The concept is easy and in the rawest form is simple to achive. I can make a link #&?id and when clicked load some content into a div. Everybody can do it. But there's more if you want to make sure the tracks are also indexed and albums have a hard url, what was it again with those hashes and histories? Best practices tells us that you have a completely static version first, with a page showing the tracks of a album, meaning the real url to the a album should work without javascript to get it. So search engines or other non javascript devices can also see it. Only then progressively enhance that with javascript, without changing or breaking the static version of course, to load that parts via javascript from the album listing and update history with either url hashes or history API. Then also check for history or hash changes in the browser and have a first request routine to load the tracks based on the url or direct request. Also dont' forget to update HTML title and active albums etc. The javascript part is what can be tricky, even more if you consider usability and accessibility. That if those slide, fade, jump, bounce or wiggle in with forward or backward spline double quad or quint easing in or out is almost irrelevant.

I don't know of how PW would auto include stuff that don't belong to PW. Since your error is class not found PagePermissions is that module there? wire/modules/ Yeah modules screen does scan modules on refresh, or for the installed modules, new template does scan templates.

Edit: maybe even simpler since you don't need to concatenate the string is just write $discuss_image_logo = "..."; and not $discuss_image_logo .= "...";

Not a very ideal way to deal with it. Thing is the variable isn't defined before you start to concat it... enable debug mode and you'll see Notice the first loop like: Notice: Undefined variable: discuss_image_logo The thing with unset() is that the variable isn't there anymore. So, even worse you'll get a PHP Notice on every loop. So simply do it like this. foreach($discussions as $item) { $discuss_image_logo = ''; $discuss_image_logo .= "<image ...>"; .... } And everything is fine. We should start a new Forum with PHP Programming Support, cause this has nothing to do with ProcessWire not template nor API.

$discuss_image_logo .= your're concatenating on and on through the foreach. Add a cleaner somewhere before those $discuss_image_logo = '';

tag or tags?

Yes $log->save("mylog", "my text"); // create and write mylog.txt file if not exists

Works fine, can you tell a little more how you setup things and what version of module and ProcessWire. Have you set the image field to only 1 image max? A page with no template file can't be browsed on front-end, if that's what you mean. Or what is gallery page?

I use symlinks for core and modules.