Robin S

How are you setting the 'prov' GET parameter? You say it isn't user input so I assume you are setting it in your own code. Therefore set it to the ID value instead of the title value of the option.

Ah, good to know, thanks. Therefore in a case like this where you want to filter pages in a Page field I'd be inclined to do an extra $pages->find() for the sake of better readability. $subjects = $page->custom_menu; $subjects = $pages->find("id=$subjects, status!=hidden");

Wow, this is proving much more difficult than I thought. Seems that you cannot use a string like "status!=hidden" in a selector (although some posts suggest otherwise). Debugging shows that status is an integer and the different statuses are cumulative so you can't just check if the status equals a constant like Page::statusHidden but must use 'greater than' or 'less than'. This is the best I've been able to manage: $subjects = $page->custom_menu->find("status<" . Page::statusHidden); Surely it should be easier than that to use status in a selector?

Hidden means "excluded from lists and searches" so doesn't affect if the page can be selected in a Page field. Well, not unless you explicitly exclude hidden pages with a custom selector in the field settings as @horst suggests. Try: $subjects = $page->custom_menu->find("status!=hidden");

Hi Speed, welcome to the PW forums I don't have a direct solution to your problem, more a general recommendation based on my experience. I find the development process and (especially) the rollout to a production environment a lot easier if I develop using a virtual host. That way you're not having to worry about subfolders and localhost and all that; you can access your development site directly at http://my-project/ Here is an article about setting up virtual hosts in the free version of MAMP: http://foundationphp.com/tutorials/vhosts_mamp.php

On my shared hosting the use of Hanna Code tends to trigger a false positive in mod_security (which throws 403s and does other odd things that are a PITA to debug). Therefore I now routinely disable mod_security in my accounts.

Personally I don't think the tracking and ranking of donors is necessary or desirable. I support the idea of a donate button in the modules directory (if a module developer chooses to enable that for their module) but when donations become public information then it's inevitable that people start comparing the donations between modules and it creates a "winners and losers" effect that can do harm to the non-commercial motivations that led to a developer releasing an open-source module in the first place. Better to have donations be a private thing that can be a pleasant surprise for a module developer rather than a focus of attention. In the short term please bring on a donate button in the Tracy config screen.

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.