LostKobrakai

Exactly. You just would do good in renaming the module and placeing it in a file like ModuleClassName.module and mostly it's a good idea to pack it in a folder with this name, too. Edit: Just for your education: The "autoload" config tells processwire to load the module everytime. Also you could use this to alert the user in the admin about the modules activity. This will generate a message, e. g. like the one telling you the page has been saved. $this->message("Changed title according to settings in …");

I find it easier to manage these things in a module like this. Also you need to use a before hook, as saving the page with the new title after saving would trigger an infinite loop. See next posts <?php /** * ProcessWire 'Hello world' demonstration module * * ProcessWire 2.x * Copyright (C) 2014 by Ryan Cramer * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://processwire.com * */ class PutYourNameHere extends WireData implements Module { /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * * @return array * */ public static function getModuleInfo() { return array( 'title' => '', 'version' => 1, 'summary' => '', 'singular' => true, 'autoload' => true, ); } public function init() { $this->addHookAfter('Pages::saveReady', $this, 'doStuffOnPage'); } public function doStuffOnPage($event) { $page = $event->arguments[0]; if($page->template->name === "blog_page" && $page->blog_categories == "Swatch"){ // Do your thing } } }

Didn't notice the naming issue Martijn mentioned. My module does a few more thing and therefore I just got rid of these and renamed the module quickly. Also be sure to use the current development version, not the stable one.

Regarding question one I would suggest looking at the Table ProField. It's a custom table, but inside of ProcessWire. Information about using processwire via command line can be found here: http://processwire.com/api/include/

You were not the only one, to expect something other than processwire love

The problem with image resizing is the fact that it's php. In php every line of code gets executed after the one before is finished. The same thing happens on resizing the image. The template generations is halted as long as the new picture isn't ready. Possible workarounds would be: Using the thumbnails module (or it's new reinvention). This lets the thumbnails be generated on upload. Using a autoload module, to generate thumbnails every 15 minutes or so. Each of this versions require you to have predefined sizes of thumbnails. To be fair, on a regularly visited site, this shouldn't be a problem, as each thumbnail has to be generated only once. So only the first visitor to see a new image(s) should get the loading time, the second one just gets the thumbnail. So as long as you don't upload 100s of images before someone visits the site, it should do the job quite well out of the box.

You can call all the pages you normally use via ajax. In the corresponding templates php file you can check for ajax requests like this: if($config->ajax){ //AJAX }else{ //Not AJAX } Everything else is business as usual.

In your template list, there's a collapsed filterform on the top, there you can enable the visibility of system templates. Then you can add fields to the user template. If you need to show those fields in the profile site of the admin backend you can enable them in the settings of the ProcessProfile module. To use them on the frontend there's no need to do that. As for the actual saving of the faves, you could use a page field, where you store the faved pages.

Had to do this yesterday. But this works only on the newest dev version of processwire, because Ryan just implemented the removeTab() method. Older versions will still show the tab, but no actual form to delete something. <?php /** * ProcessWire 'Hello world' demonstration module * * ProcessWire 2.x * Copyright (C) 2014 by Ryan Cramer * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://processwire.com * */ class RemoveDeleteTab extends WireData implements Module { /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * * @return array * */ public static function getModuleInfo() { return array( 'title' => 'RemoveDeleteTab', 'version' => 1, 'summary' => '…', 'singular' => true, 'autoload' => true, ); } public function init() { // Remove Settings Tab in Global settings for non superadmins $this->addHookAfter('ProcessPageEdit::buildForm', $this, "removeDeleteTab"); } public function removeDeleteTab(HookEvent $event){ // check what role the user has, if superuser do nothing if($this->user->isSuperuser()) return; $page = $event->object->getPage(); if($page->template->name === "settings"){ $form = $event->return; $fieldset = $form->find("id=ProcessPageEditDelete")->first(); $form->remove($fieldset); $event->object->removeTab("ProcessPageEditDelete"); $event->return = $form; } } }

This is meant to work that way. The translation is entity encoded, that's why your html isn't parsed as you'd expect it. Have a look here about how to do this without including the markup: https://processwire.com/api/multi-language-support/code-i18n/

The more flexible way would be to not hardcode anything, like this. <a href="<?php echo $pages->get("template=login")->url; ?>">Sign in</a>

I really like the map feature. I see all the locations on the forum, but it's nice to have it visualised how this community is spread around the world.

Maybe have a look at this article: http://processwire.com/docs/tutorials/how-to-structure-your-template-files/. Ryan does explain the difference in template structuring there. After this you should be able to restructure the exambles to your needs even if there's an echo in it.

$page->pagetable //Get the pages as sorted in the pagetable $page->children //Get the pages as sorted in the tree

A pagetable field is no representation of the pagetree. It's just another variant of a pagefield with multiselect. Kinda like a advanced asmSelect pagefield. You can even have pages in the pagetree, which aren't in the pagetable. You could write a module, which would sort the fields in the tree after each save, but maybe this can become complex if there are also other "non-pagetable" pages involved. Edit: The children tab is meant to be used for managing children of a page.

As your data for the inputfield isn't from the database processwire has no way of understanding your data. So you need to write a fieldtype module where you define, which data would be saved in which way to the database. That's nessesary, so your users can actually choose something. You could write this from scratch or extend a existing fieldtype. The other thing is the inputfield module, which manages only the inputfield as part of the forms in the backend and the processing of submitted form data. //Edit: This helped me greatly getting started with my first custom fieldtype: https://github.com/somatonic/FieldtypeDimension

Am I right, that you're just battling with adding a string to a textfield instead of replacing it? This adds a new line to the top. $page->price_history = "13.95 2015/01/01\n".$page->price_history; // Another syntax, but the same $page->set("price_history", "13.95 2015/01/01\n".$page->price_history); But you should include a limiter which removes the lines after a set amount of them. Something like this. $newhistory = "13.95 2015/01/01\n".$page->price_history; $pos = strpos($newhistroy, "\n", 1600); // Search for linebreaks after 1600 chars if($pos) $newhistroy = substr($newhistroy, 0, $pos); // Limit the string

I can see the concern especially about assistive software. But on the other hand html 5 is not a draft anymore and the last update of your article was a few month before that. I think for my current project I'll still go with a traditional headline structure. But in the long term the html5 spec should become more and more supported. This should make building modular sites much easier, because you don't need to care if you're placing the module after a h3 or h4. Each h1 in this module will automatically become a h4 or h5, given it's wrapped in a sectioning element.

You already have the subpages from the pagefield, so the selector must be has_parent. I don't know if it works with the name / url, but for sure with the id of the parent page. Edit: No need for has_parent. Was a little to eager in posting.

In the template settings unter the tab cache, that's the tamplate caching I'm talking about. It should only be enabled, if there's no dynamic content on the page, as the whole outputtet html of this template will be cached. So all your code from the corresponding template.php will be omitted as long as there's a valid cached version.

Do you have template caching enabled? By default it's only enabled for guests, so this would explain your experience. Also a cached html page would not parse any form inputs.

I'll see what I can do. I think the saving part will be the most complex thing of such a module.

No scientific statement, but I noticed that the admin backend seems to be faster on my shared webhosting than on my imac with mamp. Don't know why it's this way.

I would imagine something more like this, where one could drag and drop from the fields list to the templates. The fields are only there as list to choose from. Click on the title could open a modal edit. Maybe two buttons on the bottom, to add Fields / Templates to it. Edit: It's just so cool to have this mockup build faster than I could have in some design software.

I think slowly I get why Joss suggested in another topic a seperate Processpage, which sole purpose is stiching together fields and templates.