Robin S

Hi @BitPoet, I just created a GitHub pull request with a fix for this. Cheers.

@seanmvincent That sounds like a PHP error is occurring. If you turn on PW's debug mode do you see any error messages? Also, it looks like there is a mistake in the example code in your post. I think you want $pages->get() not $page->get().

Okay, makes more sense now. @Ivan: Seems like it would be easier to leave MSN and Menu Builder out of it. If you know the page structure you want just build a normal PHP multi-dimensional array of page IDs or page paths, then turn these IDs/paths into page objects as you iterate over the array and output the necessary markup.

Where does the $title variable come from in your code? You don't show where it is set. To set the URL you want to set the name of your page. $np->name = 'something'; If you don't set a name (as in your code) the name is generated automatically from the title. If you are setting a name from a variable you can pass it through $sanitizer->name($my_variable) to make sure it is a valid name. In your case you want to set the name to the same as the page ID. But when you are first creating your page the ID doesn't exist until you save it. So you can do something like this: $np = new Page(); // create new page object $np->template = $templates->get("lost-property"); $np->parent = $pages->get("/lost-property/"); $np->title = 'my title'; $np->save(); // save the page so you can get its ID $np->name = $np->id; // set your other page fields $np->save();

If you literally want to pass it to MarkupSimpleNavigation you don't need a multidimensional PageArray. You just need a normal PageArray of root pages and MSN takes care of the recursion from the root pages.

I have a question regarding the condition: Is there some way around this? I don't want to give any other roles this permission besides superuser (and the only superuser is me) because I don't want to give site editors the ability to restore backups. But I also don't want to have to be regularly browsing the website myself just to ensure the backup cron job runs. You mention running the backup from a standard cron job above - how does the db-backup permission come into play here?

Thanks for the feedback . The faulty field rendering was due to the fact that the Children tab loads via AJAX, so AsmSelect fields contained there don't get to attach their JS/CSS files in the document head in the render() method as they normally would. Have worked around this so should be fixed now in v0.0.3 I should have said in the first post that this module is only really good as a stopgap measure until either: a) this functionality is built into the core, as I think it should be b) someone builds a better module for this My dev skills are beginner/middling at best. I built this module for mostly for my own use and as a learning exercise. It gets the job done but I don't doubt for a second that there are better solutions possible. Regarding your suggestions: 1. Not sure this is a major problem as I think only multi-instance PW 3.0 sites are affected. But it was simple to change wire() to $this so went ahead and did that. 2. I have changed the template storage field to global. Not 100% sure this is the way to go so would like to hear more opinions on this. As for whether it is correct or not to use a fieldtype for storing the data - I have mixed feelings about this. I get where you're coming from and part of me does think it's a bit hack-ish. But on the other hand, the data stored in the field 'belongs' to the page so in many ways a fieldtype is ideal for this. I guess it depends if you believe a fieldtype should only ever hold page content and never page metadata. An example of another module that holds metadata in fieldtypes is Lumberjack so it's not without precedent. In any case, I don't have a good enough knowledge of MySQL to create a dedicated table and database interface in this module. Bitpoet does this in his TemplateParents module and maybe once I've learned a bit more about MySQL I could do something similar but for now I think this module will stick with the fieldtype approach.

The old wiki seems to be unreachable now. Google shows links like http://wiki.processwire.com/index.php/Module_Creation but they just redirect to the PW home page.

I have made a simple module for this: info here.

As it happens I was just last night tinkering around with a module for this: info here.

GitHub: https://github.com/Toutouwai/TemplatesChildPages For any page, allows the restricting of templates that may be used for child pages. Usage Install the TemplatesChildPages module. The module adds an AsmSelect inputfield "Template restrictions for children" on the Children tab of Page Edit. Use the inputfield to select from existing templates and any child pages added subsequently will be limited to those selected templates. Note that any template restrictions added via this module are in addition to any "Family" restrictions set for the child and parent templates. In other words, if template Family restrictions prevent a template being selected for a given page you can't override this simply by including the template in the parent's "Template restrictions for children" field. Why use this module? The module allows you to add child page template restrictions without having to create new or duplicate templates for the parent page. This forum post explains the situation well. Similarly, it makes it possible to use the "Add New" page feature without an unnecessary proliferation of templates. If you specify a single template as restriction for child pages you can add a Page Add Bookmark for that parent page that allows site editors to easily add a new page using the right template for the location.

Adapting Soma's code from here, in /site/ready.php: $this->addHookAfter('InputfieldPage::processInput', function($event) { $field = $event->object; if($field->name == "featured_products"){ $count = count($field->value); if( $count < 4 || $count > 6 ) { $page = $this->modules->ProcessPageEdit->getPage(); $old_value = $page->get($field->name); $field->value = $old_value; $field->error("You must select more than 4 and less than 7 products"); } } });

For PW 2.x it's difficult to avoid caching problems for your linked CKEditor JS and CSS files. One solution, albeit tedious, is to append a cachebusting query string to your URLs and update it every time you change the files. So in your field settings something like: /site/modules/InputfieldCKEditor/contents.css?2 This has been fixed in one of the PW 3.x releases.

I also hate empty paragraphs so gave this a try. Works well for me. This is an interesting one. There is a setting, but it doesn't work as intended. With the help of Tracy Debugger I did a bit of investigating as to why but haven't got to the bottom of it yet. The line intended to replace empty paragraphs in InputfieldCKEditor is this: $value = str_replace(array('<p><br /></p>', '<p> </p>', '<p></p>', '<p> </p>'), '', $value); But it doesn't match the empty paragraphs because $value has already passed through HTML Purifier where gets replaced with some mystery space character. So neither 'nbsp;' nor ' ' match the space character between the paragraph tags. I haven't been able to work out what this space character is because it's rendered like a normal space in the variable dump. --- Update: the mystery character is a UTF-8 encoded non-breaking space character. So the code above should instead be: $value = str_replace(array('<p><br /></p>', '<p> </p>', "<p>\xc2\xa0</p>", '<p></p>', '<p> </p>'), '', $value); Double quotes are needed around the string with the UTF-8 non-breaking space. I'll submit a pull request for this fix.

Here is a start for how you could create your search. It needs to be fleshed out for usage as global site search. For search input "rest home 1"... $addresses = $pages->find("template=address, title=rest home 1"); $categories = new PageArray(); foreach ($addresses as $address) { $categories->add($address->categories); } $categories = $categories->unique(); // not strictly necessary $results = $pages->find("template!=address, categories=$categories"); As an aside, because you are using Javascript pagination for your address list you could consider populating the filter field from a get variable for search results. To make it easier for visitors to see the address they have searched for if that address appears on page 3 or whatever. Nice looking site, BTW.

Further to what LostKobrakai said regarding storing your references to other pages in a Page field... So you have these pages somewhere in your site: social insurance rest home 1 rest home 2 And then you have a page "old age" that stores references to the pages above using a Page field called "addresses". You should be able to match "rest home 1" to page "old age" with a search selector like: $pages->find("addresses=rest home 1");

...accidentally overwrote my post, whoops. Anyway, continued below...

Modules > Core > ProcessUser > What fields should be displayed in the page listing?

Right you are, I didn't read carefully enough. AdminCustomFiles sounds like a good solution.

The whole module should be in /site/modules/ to begin with. You don't install modules into /wire/modules/ - that is only for the core modules.

Thank you, adrian. That fixes it. Just adding the curly braces around $fM['type'] was enough to avoid the error message. Before I read your reply I was doing $function = $fM['type']; $fields->add( self::$function($f, $fM['label'], $data[$f], $fM['desc']) ); which also worked.

When used with PHP7 I get this fatal error: Uncaught Error: Access to undeclared static property: MaintenanceMode::$fM in /home/mysite/web/test/site/modules/MaintenanceMode/MaintenanceMode.module:94 Is there an easy fix for this?

@Neo, I might be misunderstanding the flow of events but if you don't want people who haven't paid to submit the form you only render the form after payment. This wouldn't require any special Form Builder feature, just normal template logic. So it would go like this: User submits payment to MercadoPago from a payment page on your website. You check the response from MercadoPago to see if payment is successful. There must be some method in the MercadoPago API for this. If the payment was successful you render the form, maybe populating a hidden field from a get variable if you want to match the form submission to a payment. User submits the form for moderation.

@creativejay, my guess is that this is caused by mod_security. Try disabling mod_security (or ask your host to disable it) and see if that resolves it.

Thanks, I think you're right. However on a shared server I don't think it's possible to change the MySQL timezone. I found the following suggestion for adjusting the MySQL timezone via PHP: mysql_query("SET time_zone = '-6:00'"); Is there a better way to execute this using one of PW's $database methods? And where would be the right place to put this? In /site/init.php? It would be nice if the Session Handler Database module saved timestamps with PHP's timezone so this wasn't necessary. GitHub issue