Macrura

yes confirmed

This one is designed to work in the admin, so all of the settings, and how the javascript works is only going to work in the admin. But it's such a simple plugin, you could easily roll it into a formbuilder form.

cool - thanks - did it and it worked. Sorry for the 'false alarm'...

I started getting this error with the latest version: PHP Warning: in_array() expects parameter 2 to be array, string given in .../TracyDebugger/TracyDebugger.module.php:1078

I think it is an important and valid question, discussion topic. One option is to let the admin set, within the module config, which template(s) to be used for X purpose, which page root, and so on. (This is how it is done in various modules). Another option is to include JSON files for field, template and page creation with the module and let the admin install them. Or have the option to install the fields, templates and pages, or not (using a checkbox in mod config), like in the AdminHelp module. This means that anyone who downloads the module will be able to make their own decision about if they want to install all of those things.

Hi @Sevarf2 - i haven't tested the mod, so was hesitant to commit the change, but i should be able to do it this week. Are you having the same issue as Martijn?

Cool - i was building this, but i got stuck on the Unsplah api which was telling me they didn't like downloads and wanted to only allow usage that would use the source image from them, and this wouldn't work with an images inputfield, or imagesizer engine, or any other image manipulation like srcsets etc; So i gave up... Looks like somehow you solved all of this, so thanks! Does this use a fixed api key, or will that api key need to be configurable at some point?

@Martijn Geerts - many thanks for taking the time to make the fix here! I will implement is and do some tests and update the module soon.

The Processwire admin does not support webp. Webp is an output format, but not a valid source format for images. The Imagesizer engine of Processwire is not capable of resizing webp images, therefore when you save, it cannot generate the thumbnail, and that's why you get the error. You'll need to delete that webp image and upload a jpg instead.

@MarkE cool, i should be able to work on this soon, definitely in June, and will make some improvements according to your suggestions. If you want to post the mods here i can look at them.

hey thanks - yeah, as you can see from the way the module is setup, it doesn't force you to use the installable fields, so in theory you could just setup any template you want to use for help docs, and any family relations required; and then you just select those in the module config. The default, out-of-the-box behavior is to be only 1 level. As far as i can see in the process module, if any help doc has children, they do get rendered; are you saying you need to go down a 3rd level?

for (1) I'll need to call getFormatted which is what we do in ProcessDocumentation: $docBody = $docPage->getFormatted($this->body_field); Not sure what #2 is, in terms of a pop-out button; I also see now that this module has a hardcoded fieldname for the help doc body, so that needs to become configurable, as it is in ProcessDocumentation.. My original version did recurse down one level to child pages of the help pages...

@MarkE - should be ok to use this, and i wouldn't say that this module is no longer supported, if there were to be a bug report, pull request, or feature request, this module is still live and functioning, and may receive future updates, especially with regards to permissions and flexibility of use. But in the meantime as mentioned above, ProcessDocumentation is a bit of a larger scale module and was designed so that it would be possible to have unlimited documentation pages, all accessible from the top admin menu, as well as the ability to download the PDF; In conjunction with the ContextHelpTemplate, you can achieve the same functionality ad Admin Help, so that you have a tab for help right on the page editor, which can open in the panel (instead of wiretab) if preferred. So in that sense, ProcessDocumentation is an evolution of this module, but doesn't necessarily replace it for simpler use cases. It is also possible that this module, AdminHelp could use updates to support pw panel, or other features of ProcessDocumentation.

Cool!

@Pretobrazza, OK (1) so i just made a small modification which will convert the extension to all lowercase before it checks the field settings - each field has a list of allowed extensions; i'm guessing you don't have both jpg and JPG, so this will solve this hopefully. (2) Processwire expects an integer for image width, so if there is a % in the width, i guess the imagesizer is fatal error. I don't think it is technically correct to have anything other than an integer in the width attribute, but I have updated the module to skip resize for any images that have a percent in the width attribute. (3) You can run a simple script in Tracy Debugger; $p = $pages->get([page id]); foreach($p->children as $c) { $c->of(false); $c->save(); } @Pete - sorry for not replying to your post, i wasn't following this topic for some reason, so i didn't see your post. I'll look into the multilanguage thing, so that it scans all of the languages. I'm. guessing that right now it doesn't work at all for importing images in a multilanguage RTE field.

this one works great for this scenario: https://modules.processwire.com/modules/templates-child-pages/

The module has been updated and now loads the prev/next links via ajax, which should hopefully solve any issues with the module potentially slowing down the page editor load. The work of finding the prev/next pages is handled by an ajax request after the editor is loaded. Been tested on all 3 admin themes, with link locations in breadcrumbs and in tabs.

In one sense that could be an interpretation, but another interpretation is that it can be used on the front end, and i know of some other devs that do use it on live sites so i think it's still risky to autoload scripts or styles on a module without just loading the assets where you need them.. I don't currently know any modules where the $config->styles/scripts load on the front end inadvertently, but i'll keep a lookout. I have a module that loads into those for the purposes of use on the front end (Soundmanager). The idea is to create an ecosystem where markup generating modules can have a way to load dependencies on the front end - in Soundmanager2, you need to load the various files based on your settings. By checking to see if there is anything in $config-styles/scripts, i can have modules that can load dependencies using the core $config class. Maybe there is a better way, but $config is a useful class and i'm using it all over the place for front end development..

@kixe So the issue here is that the module has a JS file named the same as the module - this is a problem because this module is autoload, and as such the module's JS file is polluting the front end output for any of us who use $config->scripts, meaning that our scripts for use on the front end inadvertently includes the module's js file, which is not only unnecessary, but also is breaking my frontend api. a much better way of loading the JS file is to rename it and then just load the JS on the module's setting page, you can do that by checking the input and loading your js. For now i just disabled the js file, i don't even know if it is needed, or being used, and this has fixed the problem.

@Sevarf2 - just updated the code to ensure that both the settings array and the key within the array exist. (This would prevent inadvertently adding a settings array or setting if the key is typed incorrectly), if they don't it will ignore the changeSetting() call.

thanks @Robin S that makes sense, i'll implement your code. *Note: module updated.

i don't think that works - PHP_EOL should be the standard for cross platform, and it is also in the core, so i think if anyone is seeing issues with line breaks would also see them where the core uses PHP_EOL..

@Sevarf2 If you want to test this, you can add the following code to the module at the end of "SettingsFactory.module". /** * @var $key - the settings key * @var $_key - the setting within the key * @var $value - the new value */ public function changeSetting($key,$_key,$value) { $modData = $this->modules->getConfig('SettingsFactory'); if(!array_key_exists($key, $modData)) return; if(!array_key_exists($_key, $modData[$key])) return; $modData[$key][$_key] = $value; $this->modules->saveModuleConfigData('SettingsFactory', $modData); } and then this would be the way to change the setting from api: $factory->changeSetting('wiretabs-testing1','settings_client','new value'); in limited testing this has worked fine, but i'd recommend a few more tests before using on production. I haven't commited this to the master yet - it probably needs to include a check to ensure the target key exists in this case. This also illustrates that it would be possible to add settings (addSetting), but since the fieldset is defined in a hard file, any settings added in the api would not be editable in the admin, so not sure if that would be useful.

you could try replacing line 263, which is this: $itemsList = explode(PHP_EOL,$that->itemsList); with this: $itemsList = preg_split('/\n|\r\n?/', $that->itemsList); let me know if that fixes it; if so then i can test on non-windows and then make the change to the module...

ok thanks - i think it can be done no problem, but i think the api should be cleaner where you don't need to deal with setting array values; i'll have to post back once i have a working prototype.