Soma

Uncaught ReferenceError: IPS_extra_plugins is not defined /talk/public/js/3rd_party/ckeditor/ips_config.js?t=C6HH5UF:71 There's only a white area where the editor should be. Chrome OSX.

I can't see the editor anymore after deleting cache and also there's an error in the console with processwire theme 2. I had to switch to mobile to post this. Otherwise great update!

Sorry I was on mobile and didn't read carefully... I think Nik is right. And I think you have "advanced" diabled on cheatsheet, that's why you don't see it

Next is shown on cheatsheet aswell. So next gives you the next page in the tree or array and if you echo it it gives you the id only, so you have to add the field you need , in your case ->name.

$page->next->url is what you are looking for.

@Nicole. The code Ryan provided are examples that archive what my code does, but using direct SQL queries with $db var. $result = $db->query("SELECT COUNT(*) FROM field_comments WHERE status=0"); list($numPending) = $result->fetch_row(); echo "<p>There are $numPending comments waiting approval</p>"; This does the same as my code example. It's just much more efficient to do it this way with direct SQL query. "field_comments" would be the "comments" field. Each field you create has a table with it's name in the database. Ryan just gave those examples because there's no implementation in the API that would do this ATM, so my code is kinda an not so effective version of it as it has to loop through all pages that have comments. This is no problem with smaller sites, but the more pages with comments there are the slower it would get. While it should work well up to couple hundreds of pages, Ryan's method would scale up to hundred thousands pages easily before getting any noticeable impact.

Before After

I use this excellent golden module by apeisa master: http://modules.processwire.com/modules/process-redirects/

To get all pending comments you'd have to loop through all pages that can have comments and have more than 0 comments. Then find the pending comments (status=0) and count them. $total = 0; foreach($pages->find("comments.count>0") as $p){ $total += $p->comments->find("status=0")->count(); } echo "$total comments pending";

Ok good to know, thanks for report.

Have you named the template "language_gateway" or changed the new configuration to match your gateway template name?

It's working fine here. Have you removed any code from gateway template?

Update to 0.1.1 information - Changed the method to parseUrl and page rendering into the module. This is to prevent the infamous "double render" issue and also make it work with prependTemplateFile, appendTemplateFile config introduced in latest PW 2.3. (Skyscraper profile anyone). - Added gatewayTemplate option in the module confiuration. For this to work, the gateway template used to create the gateway pages /en/, /de/ etc, must be named to "language_gateway" (default) to make it work, or change the name in the module configuration to fit your template's name. The template file is now just a empty file and you can remove the code. Thanks

Yeah, I noticed while trying the prependTemplateFile with LanguageLocalizedURL module. I found a solution to avoid the issue and also the double render issue it had before with render method. I commited an update to 0.1.1 and will update the module thread later.

Just looked like it's in a subfolder, in your error "/path/site/templates/language-gateway.php" /path/site/... So the first example doesn't work with urls which was wrong. It should be $config->paths->templates instead. <?php $page = $modules->get('LanguageLocalizedURL')->parseUrl(); include($config->paths->templates . $page->template . ".php"); Ah yes I see, this was added recently, somehow missed it or couldn't remember.

BTW what is prependTemplateFile appendTemplateFile? There's no such API method in PW.

Maybe because you got PW in a subfolder of webroot? It could also be written like this <?php $localizedpage = $modules->get('LanguageLocalizedURL')->parseUrl(); include("./{$localizedpage->template}.php");

Nicole, that's what my first solution is like, and this is how it's meant to work. You add the two fields to the page you want them and in the template file you output markup that will take those two values as to construct the selector needed. If you set that up, nobody has to change code, but you can edit it via those 2 fields. In PW you don't get fields that output markup by itself, you need at least some echo $page->field. Of course it would be possible to make the field output a markup string and not the plain or formated value. But it goes beyond what you really need and it would take a long post to explain everything. Doing a fieldtype which has two inputfields is even more complicated and in the end it is what the template/field setup in PW is made for, so you'd only mimic what is already there. My solutions show already what you could do otherwise, you have some alternatives.

Look at my corrected code, you was too fast. $page->template only returns name without ".php".

The LanguageLocalizedURL module uses gateway pages that "render" (as it is a page), in there it then will "render" the content of a page evaluated by the parser. The gateway template example provided uses $page->render();. So you got 2 render. To avoid it you could change the render to include the template that would originally be used. <?php $page = $modules->get('LanguageLocalizedURL')->parseUrl(); include($config->paths->templates . $page->template . ".php"); I'm not sure again about the drawbacks of this approach, but should work.

Thanks Pete, I'm happy if someone corrects me if it's vital. I just wanted to add another possiblity. You can also use the /site/config.php to add configuration you need throughout your site. Add this to the config file. $config->blogPageListLimit = 10; $config->blogPageListParentId = 1004; And you can use it wherever you need it. $pages->get($config->blogPageListParentId)->children("limit=$config->blogPageListLimit, sort=-date");

Welcome Nicole. I had a look at your module and there's quite some things missing. I'm with Pete that for what you want to create there isn't the need for a new fieldtype. But I'm not sure what exactly you're trying to achieve that you have come up with this approach, what is the goal? Just to explain a little about fieldtypes/inputfields. A fieldtype always needs an inputfield associated. The inputfield is then used as the "interface" to input values. The inputfields all have a render() method that will output markup in the editpage screen at the end. Also there's a database schema you should specify and also wakeupValue, sleepValue, sanitizeValue, formatValue and getBlankValue. So you can guess it's much more sophisticated and complex than you initially thought and you're mixing a lot of thing up that makes it hard to start with. Other "normal" WireData modules that hook into something or process modules that can create custom admin pages functionality are much simpler to start with. Also the getConfigInputfields() is to have settings for your module and not for something you went here. You could use it to globally define the two values of course, but it will only be available to superusers to edit it. Solutions To get back to what you want to acheive. I think Pete is right, but I think you don't want to create a front-end form? A good solution to have this on a page to configure, simply use two fields to have a integer (or range slider) and a page field to select the parent page. Basicly what you wanted to do with your module. Then you can use them in the template code to output the list. You can attach those two field to whatever template/page you want, maybe the home page or some other pseudo "settings" page you create. A code in the template then maybe looks like this: "parent_page" being the page select, "limit" being the integer field $settings = $pages->get("/settings/"); $results = $this->$pages->find("parent=$settings->parent_page, limit=$settings->limit, sort=-date"); echo "<ul class='$class'>"; foreach($results as $result) { echo "<li><h3><a href='{$result->url}'>{$result->title}</a></h3><p>{$result->summary}</p></li>"; } echo "</ul>"; For such a small thing it isn't really needed to have a module that renders that but you could create a helper function to include in your templates, or if you really want to start with modules, I think the following might be simpler to start with. Look at HelloWorld.module aslo to learn more. This is a module you can load and use its methods to call in templates. <?php class MyBlog extends WireData implements Module{ public static function getModuleInfo() { return array( 'title' => 'Blog', 'summary' => 'Displays a Page List', 'version' => 1, 'author' => 'Nicole Bardales', 'href' => '', 'singular' => true, 'autoload' => false ); } public function init() { // attach hooks maybe, not needed here } public function blogPageList($limit = 10, $parent = null) { $class = "page-list"; /* or you could retrieve the setting from a fixed page */ //$limit = $this->pages->get("/settings/")->limit; //$parent = $this->pages->get("/settings/")->parent_page; if(!$parent) return "Specify a parent int he second argument"; $results = $this->$pages->find("parent=$parent, limit=$limit, sort=-date"); if(!count($results)) return "No pages found"; $out = "<ul class='$class'>"; foreach($results as $result) { $out .= "<li><h3><a href='{$result->url}'>{$result->title}</a></h3><p>{$result->summary}</p></li>"; } return $out . "</ul>"; } } With this you can load the module in your templates and use the method it adds to output the list. // load module, since we made it non autoload $blog = $modules->get("MyBlog"); $parent = $pages->get("/blogposts/"); echo $blog->blogPageList(10, $parent); or // load module, since we made it non autoload $blog = $modules->get("MyBlog"); $parent = $pages->get("/settings/")->parent_page; $limit = $pages->get("/settings/")->limit; echo $blog->blogPageList($limit, $parent);

That's some nice ideas there. I'm sure this will come in handy and would make markup caching more powerful. I like the idea to have a module to expire them by rules. Though I don't understand those rules, are they somehow to define the cache and pages that when saved will expire something? Just to understand it correctly. 1name (cache) 1pages (pages) 2name 2pages ... Also the alternative way to create the cache is nice idea. Keep going

Yeah cosmetic, but my snippets is more scalable or doesn't matter how many leves, where you would end up with ->parent->parent->parent About snippets like this people often ask if there's a simpler way or more elegant. I often wonder what it would take in other CMS' to archive this