Robin S

I think the problem is something @BitPoet mentioned above: you want to be sure the matched page has some images tagged "prod" before you try and get one of them. As @Macrura says, find('tags=prod') and findTag('prod') will do the same thing. // either... $sub_image = $pages->get("has_parent.id=$sub->id, template=product, product_images.tags=prod, sort=random")->product_images->find('tags=prod')->getRandom(); // or... $sub_image = $pages->get("has_parent.id=$sub->id, template=product, product_images.tags=prod, sort=random")->product_images->findTag('prod')->getRandom(); // then... if($sub_image) { // whatever... } Edit: If it's possible that no pages have any images tagged "prod" (and it's probably a good idea in any case) then you should actually break this into two steps to make sure your $pages->get() operation has returned a page. $sub_image_page = $pages->get("has_parent.id=$sub->id, template=product, product_images.tags=prod, sort=random"); if($sub_image_page->id) { $sub_image = $sub_image_page->product_images->find('tags=prod')->getRandom(); } if($sub_image) { // whatever... }

Alternatively you can have your module autoload only in the PW admin. Then the hooks you add in init() won't apply to API code you use in a template file. public static function getModuleInfo() { return array( 'title' => 'My Module', 'version' => '1', 'summary' => "Module summary.", 'autoload' => "template=admin", ); }

Of the autoload modules in my testing installation, bd() worked in 5 and failed in 7 when called from init(). Probably the random load order issue you mentioned.

Suppose you have a module where you want users to be able to fill out some fields for a configuration, but then the user should be able to add several of these configurations. This is something I've come up against a few times when working on modules. Any suggestions of strategies for this? I'm thinking of something similar to a Repeater - is this possible in a module configuration? I know my module could add a page to the tree and literally use a Repeater field within it but I'm not keen on that because (a) the Repeater module isn't installed by default and it seems a bit mad to require it just for a module configuration, and (b) I'd prefer to have the module configuration done in the module settings rather than on a separate page The only alternative I can think of is to use a textarea field in the module config and require users to carefully format/separate the values for multiple settings on a single line, and with each subsequent line being a different configuration. This seems a bit primitive and error-prone, although it is what I have been using thus far. Is there some middle ground between these two options? Do you think some sort of repeatable block for module config would be a good feature to add to PW? Not something that actually adds pages like a Repeater, but rather something that still allows the whole module config to be stored as a string in the DB.

Do you mean that we can debug in module init() now? That would be really cool but I just tried it with v2.8.2 and got " Call to undefined function bd()..."

This is the code that appends the JS: https://github.com/ryancramerdesign/ProcessWire/blob/devns/wire/modules/Page/PageFrontEdit/PageFrontEdit.module#L397-L404 All I can suggest is that you debug by editing the module code directly. For example: 1. Log a message to see if function hookPageRender() runs. There are a number of return statements in the function so you can log a number of different messages at different places in the function to check if the function runs right to the end or if some condition is causing it to return early. 2. Dump $out just before it is returned to check that it contains the JS it should (if $out is empty then nothing will be appended). It will be a process of narrowing down where the problem is occurring.

The PageFrontEdit module renders the necessary markup (JS, etc) immediately before the closing body tag. It uses a simple string replace on the closing body tag to do this, so not much that can go wrong there, provided your template does indeed contain a </body> tag (which yours seems to). Do you see anything relating to PageFrontEdit in the page source just before the closing body tag? Of course double-check that you are logged into the back-end as superuser.

Can you give a bit more information please: 1. What version of PW is installed? 2. Which option did you use to enable front-end editing: Option A, B, C or D? 3. If using B,C or D please provide the template code you have used to try and enable front-end editing. 4. Any javascript errors in the browser console?

v0.0.6 released - adds an upgrade process to migrate existing data when upgrading from v0.0.4 or earlier.

v0.0.5 released - a major reworking of the module. TemplatesChildPages now saves template restrictions in a custom database table. The module no longer has a dependency on the Template ASM Select module. The module no longer adds a global field to templates. Much credit is owed to the Template Access by Parents module by @BitPoet , which provided the basis for the SQL additions.

Got it, thanks @LostKobrakai

Thanks @flydev, can you (or anyone) explain why it's necessary to manually add the Processwire namespace to this file? I thought the file compiler was supposed to take care of this automatically. If not, how do we know which files need to have the namespace added manually and which are compiled automatically?

@Juergen, you should remove the closing PHP tag at the end of the file. For PHP-only files it's normally considered best practice to omit the closing tag, because you can get errors and odd behaviour if any character or whitespace is accidentally added after the closing tag. Not sure if that could cause the problem you're having (your module works normally for me).

I figured that would be the case. Thanks for confirming.

Not just page IDs but template IDs, field IDs, etc. If I delete a page (template, field, etc) is the ID of that page released back for re-use or can I be sure that the ID will never be used for a new page in the future?

I'm grateful for the "what 2.8 is for" section in the post. With a limited understanding of namespaces and currently no need to use them in my projects I've been a bit confused about which version (2.8 or 3.0) I should use for new projects. I really just want to use whatever the majority is using as it makes the sharing of code in the forum easier. Now I have some clarity that 3.0 is the way to go for new projects.

The 'icon' value needs to be a single image url. A repeater returns a PageArray, so you need to get a single page from it and then a single url from that page. Assuming that the formatted value of the marker_icon field is set to "single item" you would do something like this: 'icon' => $page->map_repeater->first()->marker_icon->url Also, the $options array is something that applies to the map as a whole. It allows you to set a single custom icon to be used across the whole map. I don't think the module provides support for setting different icons to different individual markers.

Thanks all - I think I'm making some progress now after studying those modules.

I'm looking for examples of modules (but not Fieldtype modules) that create and query their own custom table in the database. Hoping to learn from these how to incorporate the use of a custom table in one of my own modules. These are the modules I have found so far: http://modules.processwire.com/modules/process-redirects/ http://modules.processwire.com/modules/template-parents/ The simpler the modules the better because my knowledge of SQL is nearly zilch.

find() would also work here: $primary_tags = $article->article_tags->find("id!=1336|1337|1338|1339|1327|1326|1328"); $secondary_tags = $article->article_tags->find("id!=1042|1043|1044|1340|1341");

The key thing is to load the select options via AJAX. There are are jQuery plugins that can help you do this, for example: http://plugins.krajee.com/dependent-dropdown/demo Edit: a couple of other examples... http://www.appelsiini.net/projects/chained http://tutorialzine.com/2011/11/chained-ajax-selects-jquery/

Have you set up URL segments for the home page template? See Ryan's post where he talks about the home template:

Me too; beautiful work. Love that grain - looks like film but I'm guessing not in this day and age? Maybe clicking the last image on each page could link to the next page?

It works for me even when the field is inside a fieldsettab: Incidentally, the ability to edit individual fields like this is new to me. How did you discover it, and is it documented in the code anywhere? I'm curious if there are other hidden tricks like this.

Try turning off HTML Purifier for the field also. With ACF and HTML Purifier off everything works for me the same as in the demo. I would say no if it requires having ACF and HTML Purifier off. These are pretty important or else careless editors can paste in all kinds of rubbish. And "Extra Allowed Content" should be kept to an absolute minimum - the allowances @OLSA suggested are so broad (plus you actually need other elements like iframe) that it's tantamount to turning ACF off altogether. But if there's a way to get it working with a reasonably strict ACF and HTML Purifier then it would be cool. Another thought: you could set up Hanna Codes for the different embeds, or even a single clever Hanna Code for all embeds that parses the URL and determines the markup needed for the embed. That would be cleaner and easier to lock down. And there is the Textformatter OEmbed module too.