LostKobrakai

I think the easiest would be to separate the admin page (process module) from the data importer, this way the importer would be independent from admin page views.

$p = $pages->get(1001); would be the $current_menu_page of my example. If you want to change the class of the corresponding <li> element you would need to declare this variable before you echo this line: "echo "<li class='has-dropdown'>";"

@NorbertH If I understand you right, you don't like all those markup-string concatination, which gets stored in variables, like this: foreach(){ $out .= "markup"; } I don't like it as well. At least for more advanced snippets of more than 2 or 3 lines. Your prefered way of php templating does output text directly which isn't great either for a deligated approach. That's why I'm using the TemplateFile class of ProcessWire. It let's you define a html-template in your prefered way, while most of the logic can stay in the processwire-page-template files. // tpl/tmp_article.php <div class="article"> <h2><?php echo $title; ?></h2> <?php echo $text; ?> </div> // articles.php <? $content = ""; foreach($pages->children as $article){ $t = new TemplateFile($config->paths->templates . "tmp/tmp_{$page->template}.php"); $t->set( "title", $article->title ); $t->set( "text", $article->body ); $content .= $t->render(); } As the template files are normal php files as well you can still do what you want to. The $t->render() method just returns everything that gets outputted by the template file.

The 403 error is to prevent misbehavior. The .htaccess file lets all requests to existing files on the disk directly though without bothering php / processwire with it. So if you could name a page "site" (child of home) you would mimic the path of the real folder structure and with bad luck you would expose some of the files there. Also if that happens, it's most likely not the content you would want there, as it's just the file, not the page you would like to see, as the request doesn't even get to be parsed by php.

Something like this: $search_in_parents = $page->parents->get($current_menu_page); if( !$search_in_parents->id ) echo "<li>…</li>"; // Not found else echo "<li class='highlight'></li>"; // Found in Parents If your childpages are only direct descendants you may use this to check for the one direct parent: if( $page->parent == $current_menu_page ) echo "It's the first Parent!";

I don't know something about the error you get, but my setup is German and English. I just labeled the default language "German" and imported the translation pack. Then added English as second language. The default tab / language is German.

@Nico I think the boxes could be a good addition to a default / first run install. It helps some people and all the others hit "X" and deinstall, maybe this could even remove the files, or most of them. The tooltips on the other hand could be in a second module, if someone really wishes a guided tour. Adding the module via the new module installer on their own shouldn't be a problem, can be explained, and they even learn how to install a module on the way. Think of it as a advanced tutorial. But I'm not sure how much people would actually use such a module.

@diogo I like you're example. I think ProcessWire in itself is already damn easy. The only thing we can really improve regarding the learning curve by now is by helping users to find answers to their questions. For beginners the ProcessWire API Docs at http://processwire.com/apigen/ are way overkill while I just discovered there, that a Fieldgroup extends WireArray and I can use most of the methods I use with pages. Otherwise Ryan's new tutorial on templating or Joss one on installing a css framework are really viable explanations for beginners. I also often use the explanations here: http://processwire.com/api/variables/ because they are a little more, than just a table of available functions. What's maybe missing is some kind of "this stuff helps you to dive in as beginner", "this stuff is improtant for module developement", because there is already lots of documentation, but it's a little bit scattered around the site / forums. Kinda like a book, where capters are mixed up. Content creation is quite simple in ProcessWire. Create the needed fields, than combine them to templates. Create a page and fill in the content. This doesn't need much of explanation. The more unusual part is the templating. But to be honest, I don't know how you would create templates in any cms without previously looking at the docs or at least some other form of tutorial.

It's been long since I last tried Drupal (version 6 / 7), but I can't remember those types being better introduces than templates and fields are in ProcessWire: A small explanation text somewhere in the navigation. Secondly, external documentation is, after the first few moments, key, as you don't want to have guidance all the time as developer, but you still sometimes need to see code examples. If I'm presented with a siteprofile, which installs extra stuff, I don't use it, because I only want to use stuff I really need. Wordpress is not successful because of it's good admin interface, which helps the developers/users. In fact it's mostly a pain to see all those plugin interfaces stiched together. It's mostly the sense of already available solutions which drive the success.

I think he is moving pages in the backend, so that articles are featured on the homepage. But the moved page is not sorted to the top, but somewhere a few pages below.

Zorro Masks? Havn't seem them.

Thanks. I think I'll use this quite often from now

If you're talking about the PageTree links, is there any chance to get the code?

I've browser autocomplete disabled, because it's just stupid and I use 1Password for passwords anyway.

Nope, I would like to have this field extended with autocomplete.

The default siteprofile of version 2.5 does exactly what you want. Each template calls it's own template.php file. With prependTemplateFile the _init.php is called before the template.php to have global variables, sidebars and stuff, from there you can include a _func.php with global functions, too. After that the template.php fills the template specific variables and they are all echo'd in the _main.php, which is either included at the end of the template.php or with appendTemplateFile.

This may be a simple addition, but with the usage of quite a few templates (memberarea / shoparea / magazinearea) it would be nice not to remember all the exact wording for the different tags I use, but to have a autocomplete for existing ones. I would try to make one by myself, but I've not touched autocomplete by myself by now.

Bitnami Stacks are quite shitty to customize from what I remember. There are settings scattered all over the place and it's real pain to search for the right file to alter behavior.

Maybe take a look here: http://boagworld.com/mobile-web/mobile-app-vs-mobile-website-design/ and at the video linked at the end of the article. Apps can be great but most of the time a simple website is the better option. I sometimes wonder what some companies think that people would happily download.

You can save the first lines by using this. $timestamp = $page->getUnformatted("week_begin");

I'm happy if I can contribute to some sort of snippet library and I like the two kind strategy because it fits the "hey I found a cool piece of code" mentality and also the stuff that just needs a little more explanation.

I use it as standart format and getUnformatted() if I need to get another format.

Ok, so I'll stick to getUnformatted(). It's saver to get the right timestamp, as long as both formats can be chosen in a datefield.

Just out of curiosity, how does strtotime() devide between "d/m/Y" and "m/d/Y"? Both are posibilities for a pw date field and I don't really trust php here.

@Philipp It's only a timestamp if you choose no output-formatting in the datefield settings, otherwise it's a formatted string. That's why I always use getUnformatted(). It always works and I can use the standart formating set in the settings.