Robin S

If you're still seeing notices after doing this then the error reporting setting has not been changed successfully. You can use phpinfo() to confirm. Depending on how PHP is set up on your server you may need to use a php.ini file or .htaccess to change settings. Or if this is a cPanel hosting you can usually change error_reporting there. Your host can advise what you need to do to change PHP settings.

Thanks @horst. I have my dependent selects working acceptably well now. But there are a couple of things that could perhaps be improved if anyone has suggestions... 1. How can I add options to a select inputfield from outside getModuleConfigInputfields()? Any options used in the select must be added to field $f with $f->addOption() or else they don't pass validation and are not successfully saved on form submit. I need to add these options in my AJAX method according to what has been selected in the first select. I thought I would be able to do this... $fields = $this->modules->getModuleConfigInputfields($this->className); $f = $fields->get('my_select_field'); $f->addOption('my_value', 'my_label); But options added here do not persist, i.e. they are not included the the array of allowed options at the time the form is submitted and processed. Options added within the getModuleConfigInputfields() method in the module work normally. Currently my workaround is to set all possible options within getModuleConfigInputfields() and then filter out the 'wrong' ones with jQuery, but it would be nice to set just the 'right' options in my AJAX method. 2. The second one relates to what you say here... When accessing the module config page with an AJAX request we don't want all the normal form markup returned. I'm not sure what you mean about setting this manually with an if/else condition in init(). As I understand it, the form markup comes automatically from ProcessModule and doesn't depend on anything done manually in init(). The only modules that I know of that use AJAX in the config are the ones @adrian referred me to: http://modules.processwire.com/modules/process-email-to-page/ http://modules.processwire.com/modules/process-custom-upload-names/ These two avoid the normal form markup by doing exit() at the end of the AJAX method, but I think this is a bit ugly (and Ryan has said that it's best if PW can control its shutdown). So I am using a replace hook on ProcessModule::executeEdit. I'm interested if there are different or better ways to handle an AJAX request to the config page.

@POWERFULHORSE, if you have Imagick installed on your server you can try a slightly modified version (below) of the function I introduced in this post. // ImageMagick effects function imagickal($imagePath, $format, $method, array $arguments) { $path_parts = pathinfo($imagePath); $dirname = $path_parts['dirname'] . '/'; $filename = $path_parts['filename']; $mod = $method . '-' . implode($arguments, '-'); $mod = wire('sanitizer')->filename($mod, true); $savename = "{$dirname}{$filename}_{$mod}.{$format}"; if (!file_exists($_SERVER['DOCUMENT_ROOT'] . $savename)) { $image = new Imagick($_SERVER['DOCUMENT_ROOT'] . $imagePath); call_user_func_array([$image, $method], $arguments); $image->setImageFormat($format); $image->writeImage($_SERVER['DOCUMENT_ROOT'] . $savename); } return $savename; } I tested it as follows... $orig = "/site/templates/images/transparent.png"; $after = imagickal($orig, 'png', 'negateImage', [false]); echo "<img src='$orig'>"; echo "<img src='$after'>"; ...and the results...

Again I'm on the hunt for example modules to learn from. This time I'm wondering if anyone has released a module that uses dependent selects in the config - in other words, load select options for select inputfield A depending on the value of select inputfield B. Currently the module I'm working on requires a save after changing inputfield A, but it would be much cooler if I could update the select options for inputfield B via AJAX when the value of A changes.

Thanks, that's a good idea. Unfortunately it doesn't work for my situation because getModuleConfigInputfields() still reports the old set of configuration fields at the time that the saveConfig() hook runs. Not sure exactly when the inputfields are updated following a change - perhaps on the following page load of the module config screen? I have come up with something that works for now. I have an integer field in the module config that defines the number of repeated fieldsets, whose names contain an integer according to the iteration. In the saveConfig() hook I unset any fieldnames containing an integer higher than the fieldset count.

I don't think you need nested repeaters, just a single repeater that has a title field (title of the gallery) and an images field. The images field can contain multiple images. Use the description field for each image for the overlay text.

Thanks @BitPoet. Module config fields don't exist in $fields so I can't use that to check which config values should be weeded out in a hook to saveConfig(). But it did give me another idea: save my own JSON string of current config fieldnames in a hidden config field, then check the keys in the config array against that and unset any that are not included. But now I'm banging my head against another issue which is that it's annoyingly hard to set the value of a config inputfield using the ModuleConfig class.

I see that the approach of ProcessEmailToPage and ProcessCustomUploadNames is to save the repeatable fields as a combined JSON string to a single hidden inputfield. I'd like to try something different and use the core inputfields (as per a normal module config) inside a fieldset, with the number of fieldsets being variable. I've nearly got this working but have struck a problem with config fields being retained in the DB data after they have been removed from the config. This isn't just an issue for this repeatable config I'm trying to achieve but would also be an issue for a more typical module config if the number of config fields changed between versions. To illustrate, say my getInputfields() function consists of two text fields: text_1 and text_2. In the DB this is stored as: {"text_1":"foo","text_2":"bar"} Now I remove text_2 from getInputfields() and the inputfield is gone, all good. But the DB is unchanged and the value for text_2 is still stored. If the normal behaviour is not to remove config data when the config inputfield is removed, can I use a hook in my module to change this? I'm having trouble tracing where the ModuleConfig class actually saves to the DB. Does it do this via saveConfig() in Modules.php and would that be the right method to hook? Edit: found the source of this issue here in ProcessModule.module - the existing config array is loaded first and then data from the config inputfields is merged in. The net effect of this is that the inputfields specified in ModuleConfig can only ever add to the array of saved fields, never remove fields from it. The method isn't hookable so I don't see a way to override this behaviour.

Thanks @adrian, glad to have those modules as a proof-of-concept.

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.