Leaderboard

Just some more thoughts on this topic I just asked myself Why would someone use Drupal or Typo3 and therefore read what they write on their sites. https://www.drupal.com/product/web-content-management https://www.drupal.com/product/commerce https://typo3.com/about-typo3/why-typo3-cms/ The shocking truth is that they don't say anything new at all. Some arguments are valid, some are BUZZword Bingo but almost all of them match perfectly well with ProcessWire, too. If we wanted to create a huge list of arguments for ProcessWire we can find a lot of material out there in the interwebs. Can ProcessWire compete with Drupal or Typo3? I think we all know the answer. Next step Who uses Drupal or Typo3. http://www.typo3-websites.eu/en/typo3-cms/typo3-references/commercial-enterprises/ https://www.drupal.com/showcases This is way more interesting to look at. Big companies, big budgets and big agencies. Absolutely well designed sites well presented. Drupal plays the showcase-game very well. Every site gets a lot of attention. Not only a screenshot, a link to the website, a link to the creator and a few links to modules. Everything is a case study. Browsing the list of sites is a really nice experience and makes me want to try Drupal and built awesome sites. Could this be done with ProcessWire sites as well? Absolutely. Should we invest more time in presenting sites and projects? You guess it.

Great topic idea. FYI, in AdminOnSteroids you can globally add plugins (with buttons, if available) to all ckeditors. Please feel free to suggest a plugin to add to aos. Additionally you can selectively set, add or remove buttons per user role, template, etc with its FieldOverrides submodule.

@wbmnfktr I removed the security related link, which was outdated anyways, as it was for the 2.x legacy version of ProcessWire. Right now, for PW3 there are no documented security flaws. The article is now translated into English and available here: https://jensmartsch.de/blog/why-processwire-is-the-best-choice-for-your-website Additions and comments are welcome. I also updated the first post, with links to both versions.

This is interesting - it might be the MySQL version, but it might also be the MySQL ONLY_FULL_GROUP_BY setting. ProcessWire requires that is removed, but it only gets removed for 5.7.0+ https://github.com/processwire/processwire/blob/3fc9f69da75e1bc4a3f0842f12a57bd6a1b65099/wire/config.php#L897 If you add this to your config.php it might just work: $config->dbSqlModes = array( "5.0" => "remove:STRICT_TRANS_TABLES,ONLY_FULL_GROUP_BY" ); That said, I would definitely get an upgrade to MySQL because there could be other issues with that version as well.

Forms are an essential part of most websites, and it's no surprise that there's an excellent premium module Form Builder but what if you're on a zero budget for whatever reason? It is possible to build forms quickly and easily by making use of a couple of free modules and the admin UI to give you a great deal of flexibility and speed of development, particularly if you need multiple forms on a website with different fields. 1. First you're going to need to install a couple of modules: Form Template Processor Fieldtype Select External Option 2. For each form that you want to display, create a template without a template file and add fields to it as you normally would. (eg I have formContact, formRegister etc) Tip: under the Advanced tab in the setup for each template, I add a tag Forms so that all my forms templates are nicely grouped together in admin. 3. Create a new field of type Select External Option and call it formTemplate In the section Create options from any database table select templates as the source table id as the Option Value name as the Option Label 4. Create a new template file and call it renderForm.php (or whatever else you like) Add an email field to this form - This will be the email address that forms get submitted to. Add the formTemplate field you previously created to this form. This will allow you to select which of the templates you previously created such as formContact, formRegister etc you want to render. Add any other fields as usual that you want to render on the page. Add the following PHP code to the template file. $recipient = $page->email; $form = $modules->get('FormTemplateProcessor'); $form->template = $templates->get($page->formTemplate->label); // required $form->requiredFields = array('contactName', 'contactEmail', 'contactMesssage'); //Optional: This can be improved by having a field in the page template with a CSV list of required fields eg $form->requiredFields = explode(',', $page->requiredFields) $form->email = $recipient; // optional, sends form as email. FormTemplateProcessor can also save forms to the database. $content .= $form->render(); //generate the form to display. Note: this doesn't actually render the form at this point, but you have it in the $content variable ready to output wherever you want in your template. Add any template HTML or other PHP code and echo $content; wherever you want to render the form. 5. Create a page using the renderForm template, and provide an email address, and select a form that you want to display. 6. Use CSS to style the form as required. 7. View your new page, and check that the form renders correctly. 8. You can modify the templates you created at step 2 or create new ones as required if your requirements for what fields forms display changes. Note: The Form Template Processor module can also save form input as pages, and the FieldType Select External Option can be set up with filtering, so this solution can probably be refined further.

Hi @jaro, I've been having a look at the Repeater issue and the BreakRepeaterFields demonstration. Interestingly, the issue is not that fields are copied from one repeater to another. It is that the module interferes with the listing of fields when the repeater field settings are viewed in ProcessField, causing the fields of one repeater to appear in the AsmSelect of another repeater. So if you check the database the fields associated with each repeater is actually correct despite the incorrect listing shown in ProcessField. But if the user then saves the field in ProcessField it is at this point that the associated fields become incorrect. Could you explain why the module needs to hook ProcessPageView::finished? This method fires on every page view, front-end and back-end. But most of these page views will have no connection to field settings or template settings changing. Instead of hooking this method, couldn't you hook only methods that are related to field and template settings? So some method in ProcessField and ProcessTemplate? And also, the module is looping over all fields on every page view. Could you focus in on just the field that is being edited? So when field1 is edited in ProcessField, just export the data for field1 rather than looping over every field. This would avoid the situation where the data for repeater2 becomes involved when editing repeater1. I should say that I've just had a brief look at the issue so far, so there might be good reasons why the module does what it does.

Hi guys, I published a new article "Why ProcessWire is the best choice for your website (not always, but in most cases)" on my website It is also available in German "Warum ProcessWire die beste Wahl für Ihre Website ist (nicht immer, aber in den meisten Fällen)". Feel free to comment or give me advice on missing things. Cheers Jens

Despite Soma helpfully telling us we are all wrong, the code I suggested in that thread works for me: So you set up a field in each PageTable template to hold some reference to the container page - in the example below I use an integer field for the page ID, but you could use a Page Reference field instead. You would set the field to hidden so users do not see or change it. But for demonstration purposes I have left the field visible and also show the value in the PageTable columns. Note that the value is only set when the PageTable field does the AJAX reload (when the modal closes), so the value is not available when adding a new page to the PageTable until the modal is closed. In /site/init.php $wire->addHookBefore('InputfieldPageTableAjax::checkAjax', function($event) { $field_name = $this->input->get('InputfieldPageTableField'); // Just for this PageTable field if($field_name !== 'test_pagetable') return; $page_id = (int) $this->input->get('id'); $item_id = (int) $this->input->get('InputfieldPageTableAdd'); if($page_id) $page = $this->pages->get($page_id); // $page is the container page if($item_id) $item = $this->pages->get($item_id); // $item is the PageTable item // Set integer field to $page->id $item->setAndSave('container_page_id', $page->id); });

For some inputfield visibility constants it is too late to set them at inputfield render. For Inputfield::collapsedHidden, Inputfield::collapsedNoLocked and Inputfield::collapsedYesLocked these are handled by the InputfieldWrapper class. I've found that a good method to hook for setting the visibility of fields in Page Edit is Field::getInputfield. This example is for /site/ready.php but easy to adapt to a module context: $wire->addHookAfter('Field::getInputfield', function(HookEvent $event) { // Only for ProcessPageEdit if($this->page->process !== 'ProcessPageEdit') return; $field = $event->object; $inputfield = $event->return; if($field->name == 'proj_code_folder') { $inputfield->collapsed = Inputfield::collapsedNoLocked; } });

Ah, good find, thanks. Fixed in v0.0.8.

Two options: 1) Admin On Steroids gives a tooltip to show field names and link to edit them: 2) Tracy shows a list of fields (and their values and settings for the page being edited. This is available from the Request Info Panel

Version 1.0.7 excludes email and password confirmation fields from spam count. @Donald I hope, I've answered all your questions. Now I'm looking forward to merge your pull request to improve the documentation!

it has been discussed a lot on some topics, and it was determined that there is currently no easy way to pass data to the modal/page. One way to achieve it is to hook into the save of the owning page and at that point cycle through the items in the page table, setting that field to the owning page. This works fine, however is risky in case the users do not save the owning page after adding new items to the page table. You could optionally also run a cron job to scan though the pages and look for items missing that field and set them that way. Another way I have achieved this by using a custom 'page table' which i create using @kongondo's Runtime Markup, then i can put anything i want in the add new button (url params); Then i capture the input into a session variable, use that to set the field, then clear the session variable, hooking into save of the new item. To do it in a Page Table without doing the first way i suggested here and in the linked topic, i think you'd likely need to add a url parameter to the popup which means hooking into the button markup. This is the structure of the add new button: <a class="InputfieldPageTableEdit" data-url="/manage/page/edit/?id=9999&modal=1&context=PageTable" href="#">Title of Page</a> if you could add a url param, like &ownerPage=1234 you could then capture the input and use it to set the field. You'd need to have a hook on the save of the new page; I may be working on this so if i come up with a definitive solution will post back; i do think this is something that should have a decent recipe solution since it seems to come up often in my IA requirements.

Under the Code/File organization, it would be helpful to explain ProcessWire best practices for using: A single stand-alone process module. More than one process module (required = array(other modules)). Including a stand-alone class or interface in process modules. ... Just thinking out loud.

I have a question though: I have a template override for the title field in place. This works, but only in page-edit mode. i.e. I see my label + description when in page-edit view. But on this first "add new page" screen I only see the default "Title" label, and no description. Can I somehow force PW to use my template override on this screen? Or is it necessary for PW to first save the page, to apply this setting? (makes sense) Can I add two lines to the above code and "inject" my title-label & description? Edit: OMG, I use PW now what? since 5 years, or more? I should know better by now that it's as easy as this: $title_field = $form->getChildByName('title'); $title_field->label = 'my custom label'; $title_field->description = 'my custom description / help-text / instructions / examples'; $form->insertAfter($f, $title_field); sorry for even asking...

Hey @bernhard - as I mentioned, I now leave the Dumps Recorder disabled by default and only enable it via the Panel Selector if I need it which is usually only if there are some weird redirects going on that Tracy is missing. The main Dumps panel is now my own version (not the Tracy core) so I can control how it looks and behaves, and also the way it stores consecutive ajax requests. Does that make sense and work for you? I can bring back the "Preserve Dumps" option if it's really needed, but really the new "Preserve Dumps" approach is to enable the Dumps Recorder when needed and when not, just don't load it.

Had to play around with it and it works like a charm. Thank you @Kiwi Chris for sharing this. This will come in handy for smaller sites or prototypes. What I really like is that saving pages from the submitted form doesn't need an extra step as it does in FormBuilder. The created template is already the form and the template for the pages.

Also, you could ask why, but oh why they still have this MySQL version full of security vulnerabilities installed on the server ?! Just sayin, this version is eleven years old!

Maybe your problem is that your server don't met the ProcessWire requirements, it ask for a 5.0.15 or greater version of MySQL. https://processwire.com/about/requirements/ You might want give a try at installing a fresh ProcessWire 3 installation on this server to see what happen. Which hosting type are you using ?

Hi and welcome, The version of the MySQL server could help here. Post also the ProcessWire version (the old and the new) please.

@flydev Thank you so much for this module! Just a side-note: please consider turning the next version number to at least 0.1.0 or better yet 1.0.0 (I do not think this module is in beta state as it is stable. It might lack some functions you have not yet found the time to finish but those can be pointed out in the read me and not in the version number ) We have a recent discussion about this and it seems to be beneficial to use semver 2.0 : https://processwire.com/talk/topic/17767-module-release-notes/?do=findComment&comment=156350 And for those who doesn't already know I would like to point out that Duplicator is not just about duplicating but making regular backups (via (lazy)cron).

Your original image has an AdobeRGB colour profile. Because support for colour profiles is going to vary in PHP/GD/ImageMagick and from browser to browser it would be a good idea to convert and save your images with the sRGB profile which is the mostly widely supported. This was discussed recently on the forums here: More reading: https://fstoppers.com/pictures/adobergb-vs-srgb-3167

There you can download the module : https://github.com/flydev-fr/Duplicator The documentation is incomplete, you have for now to explore the settings on your own. The install instructions are written but the SDKs are not uploaded yet, which mean that AmazonS3, Dropbox and GoogleDrive are only available by installing them through composer. I will upload them tomorrow but they are not recently tested. Anyway, there is no requirements to run Duplicator as is. Just install Duplicator and Duplicator - Packages Manager then go to Setup > Duplicator and build your package by clicking the button. If everything run smooth, you will see the package listed and you will be able to download it directly and also the installer. To restore a website, just upload the package and the installer then go to yourwebsite.com/installer.php then follow the instructions. PLEASE, do not forget - after the end of the process - to delete the installer.php file and your package (this will be fixed in the v0.0.45). It should work with default theme and the UIkit theme. A dedicated thread will be created in the modules forum soon. Do not hesitate to share here your results by providing your hosting type / provider / config, etc.

A handy trick for dealing with the suffix added to inputfield names inside a repeater is to use the name of the associated field object instead, which you can get via the hasField property of an inputfield. In this case it looks like you want the Field object anyway so it could be: //$pageField = $this->wire('fields')->get($this->name); $pageField = $this->hasField; (not tested)

Part 1 of a 2 part Module & Service Reveal. I'm currently working on a new module: ModuleReleaseNotes that was inspired by the work I originally did on making Ryan's ProcessWireUpgrades module "release" aware. In the end, I decided to ditch the approach I was originally taking and instead work on a module that hooked in to the UpgradeConfirmation dialog and the module edit page. Aims My aims for this module are as follows... Make discovery of a module's changes prior to an upgrade a trivial task. Make breaking changes very obvious. Make reading of a module's support documentation post-install a trivial task. Make module authors start to think about how they can improve the change discovery process for their modules. Make sure the display of information from the module support files/commit messages doesn't introduce a vulnerability. Looking at these in turn... Making discovery of a module's changes prior to upgrade a trivial task. This is done by adding a "What's changed section" to the upgrade confirmation dialog. This section takes a best-effort approach to showing what's changed between the installed version and the updated version that's available via the module repository. At present, it is only able to talk to github-hosted repositories in order to ask them for the release notes, the changelog file (if present) and a list of commits between the git tag that matches the installed version and the tag matching the latest version. It will display the Release Notes (if the author is using the feature), else it will display the commits between the tags (if tagging is used by the module author) else it will show the changelog file (if present) else it will show the latest N commits on the master branch (N, of course, being configurable to your liking.) An example of the Github Release Notes pulled in for you, taken from Mike Rockett's TextformatterTypographer Module... An example of a tag-to-tag commit list from the same module... An example of a changelog - formatted to show just the changes (formatting styles will change)... Finally, an example of a fallback list of commits - sorry Adrian ... Making breaking changes obvious. This is currently done by searching for a set of configurable search strings. Later versions may be able to support breaking change detection via use of Semantic Versioning - but this may require some way of signalling the use of this versioning standard on a module-by-module basis. For now, then, you can customise the default set of change markers. Here I have added my own alias to the list of breaking change markers and the changes section of the changelog is styled accordingly (these will be improved)... Make reading of a module's support documentation, post-install, a trivial task. This is done by making some of the support files (like the README, CHANGELOG and LICENSE files) readable from the module's information/settings screen. There is an option to control the initial open/closed state of this section... Here is Tracy's README file from within the module settings page... Make module authors start to think about how they can improve the change discovery process for their modules. There are notes in each of the sections displayed on the upgrade confirmation page that help authors use each of the features... Make sure display of external information doesn't introduce a vulnerability. This is an ongoing concern, and is the thing that is most likely to delay or prevent this module's release lead to this module's withdrawl should a vulnerability be found. Currently, output is formatted either via Markdown + HTML Purifier (if it was originally a Markdown file) or via htmlspecialchars() if it has come from a plaintext file. If you discover a vulnerability, please get in contact with me via the forum PM system. Ongoing... For now, I've concentrated on integration with GitHub, as most people use that platform to host their code. I know a few people are hosting their repositories with BitBucket (PWFoo comes to mind) and some with GitLab (Mike Rockett?) and I would eventually like to have adaptor implementations for these providers (and perhaps GitKraken) - but for now, GitHub rules and the other hosts are unsupported. Links Github: ModuleReleaseNotes PW Module Repository: Here

Metadata Exif Version 0.9.0 (currently a WIP) for PW 2.8.+ / 3.0+ This is a new attempt to add easy EXIF reading support to ProcessWire. It should be an easy and less error prone API task. Thats why the module internally uses lowercase key names for all EXIF keys and all of your requested key names. But you are not forced to use lowercase key names, you can use any mixed chars for it as you like. You will get back an array or object with keynames / properties named the same (casesensitive) way as you have passed them in with your request. API The module adds one hook to the Pageimage: getExif($options = null) Without any $options passed to the method, it returns all EXIF data in a RAW multidim array. Passing a simple list with requested key names as array to it returns an array with only the values of those requested keynames. If you want change the output from array to object, you can use the a boolean "toObject" set to true. Additionally to this and / or any other option, you need to put your requested keynames list to the option "keys". $rawArray = $image->getExif(); $options = array('Whitebalance', 'Flash', 'ISOSpeedRatings', 'FNumber', 'UserComment'); $array = $image->getExif($options); $options = array('toObject' => true, 'keys' => array('whitebalance', 'flash', 'isospeedratings', 'fnumber', 'usercomment')); $object = $image->getExif($options); Possible options are A working example $options = array( 'keys' => array('ISOSpeedRatings', 'FNumber', 'Flash') ); echo "<table><tr>"; foreach($options['keys'] as $key) echo "<th>{$key}</th>"; echo "</tr>"; foreach($page->images as $image) { $exif = $image->getExif($options); echo "<tr>"; foreach($exif as $value) echo "<td>$value</td>"; echo "</tr>"; } echo "</table>"; This will output something like: With the boolean option "unformatted" passed as true, the output would look like: For some keys, that only store something like integer values, what are not very meaningful to most of us, the module contain xyzFormatted methods. This way, it is easy to enhance and maintain the module in the future. Help wanted It would be nice if some of you test the module and report back if the intended API suites your needs. And you are very welcome to post suggestions for which keys you want to have a ...Formatted method. Thank you! https://github.com/horst-n/MetadataExif

Hi guys! I've been a bit away from the forums lately but I didn't forget you all (well, I'm not writing much, but visit all the time) Here is our latest site http://www.plateau.studio The design is by Plateau themselves. Some of you will probably recognize "The Weekender" magazine from their portfolio, since we also did their site some time ago https://www.the-weekender.com

Some nice updates this morning for the Console and the Snippets Runner panels. 1) The code injection feature (the one that lets you run hooks etc at init, ready, and finished) now has better error handling. It will no longer inject code if it detects any type of error (previously it wasn't properly detecting 500 errors). 2) The Console panel now makes use of orange and red icon colors. The orange simply indicates that you are currently injecting code, and the red indicates that there is an error in your code and as such, nothing is being injected. 3) The Console panel now restores the last error to the results section on page load so if you missed the error when you clicked "Run" to register the code, you will see it again as a reminder of what needs fixing. 4) 500 errors in the Console and Snippet Runner panels now show the full error message - previously this had to be tracked down in the browser dev console's Network tab. Hopefully these changes will be nice improvements to debugging code in the Console and Snippet Runner panels. Let me know if you notice any problems. Cheers! PS I have been using the Console code injection feature for all my hook testing lately and really enjoying it.

It just so happens that there is... Templates: Child Pages You could use this in conjunction with the hook below, which will use the template context for title label, description and notes if the number of allowed templates has been restricted to one: $wire->addHookAfter('ProcessPageAdd::buildForm', function(HookEvent $event) { $form = $event->return; $template_field = $form->getChildByName('template'); if($template_field->type == 'hidden') { // Only one template is allowed for this new page // Get the template $template = $this->templates->get($template_field->value); // Get the title field in the context of this template $title = $template->fieldgroup->getFieldContext('title'); if($title) { // Set the properties of the 'title' inputfield $title_field = $form->getChildByName('title'); $title_field->label = $title->label; $title_field->description = $title->description; $title_field->notes = $title->notes; } } $event->return = $form; });

Hi @teppo Finding out that there is also few more bugs with PW3: revisions don't work - it always shows the latest version (the sliding preview or /setup/version-control/preview/?pages_id=1328&revision=511 urls). I did debug this quite a bit and this SQL generated by PageSnapshot::snapshot always returns Empty set (although there should be data and database seems to been populated fine): SELECT t1.pages_id, t1.id AS revision, t2.fields_id, t2.property, t2.data FROM ( SELECT MAX(t1.id) id, t1.pages_id, t2.fields_id FROM version_control__revisions AS t1, version_control__data AS t2 WHERE t1.id = 513 AND t1.pages_id IN (1328) AND t1.timestamp <= FROM_UNIXTIME(1511771437) AND t2.revisions_id = t1.id GROUP BY t1.pages_id, t2.fields_id, t2.property ) AS t1 INNER JOIN version_control__data AS t2 ON t2.revisions_id = t1.id AND t2.fields_id = t1.fields_id GROUP BY t1.pages_id, t2.fields_id, t2.property In history tab clicking pagination also changes the tab (minor annoyance) I also updated this to PW3 (well, added namespace to each .module file and changed PDO references to \PDO, but that didn't had any affect to these bugs (didn't test the earlier image test though). Here are those attached if you are interested (didn't test that well and took about a minute or so). ProcessVersionControl.zip

Really??...on PW 2.3?

sorry, didn't know that you can't set that up dynamically?? crazy. ok sorry, then i was of no help

Hey Bernhard, PayPal.me is in most respects a great service. The only draw back is you have to have a paypal account to use it. We have it set up but don't really want to force people to get an account just to send money. We also have interac e-transfer as an option but that's not for everyone either so PayPal is still important. I looked at the paypal buttons as well. The only problem with them is you have to set a fixed price when you set it up. Each customer will have a different amount owed so it won't work. They have donation buttons that allow users to enter a custom amount but there's no flexibility with the set up. You'd think Paypal wouldn't be so rigid in their payment solutions, forcing people to work the way Paypal expects rather than bending to meet customer's needs. I told them as much in a support ticket which is maybe why I haven't heard back from them.

So I've been working on a special class for the app interacting with the app's db tables. I've went and added 2 tables onto here. pwusers - This is where I store just the id of PW users (since the app has its' own users table as well) users_pwusers - A relationship table connecting pwusers to the existing users table of the app. The idea is when a new user is created in PW, I would simply: Add that id to the pwusers table Create the user in the users table in the app Add the 2 ids into the relationship field. From there, I have a way to retrieve information from the app associated with the user created in PW. I believe this is the focal point between the app and PW. Setting up this way will allow me to keep the the front end and the app separate in case I ever want to move the app to somewhere like AWS or Rackspace and utilize their database services for high volume. My only concern that's in the back of my mind is synced backups and restores. It's still in early development phase so there's still a lot of room for pivotal changes if anyone has a better approach.

Thanks - i can't recall how i solved the lister columns for other users; i will do some more testing; at worst case i will show the other users how to setup the lister on their own, and then it gets stored somewhere(?) or maybe i should enable the bookmarks and tell them to use that(?) i see that basically when the lister comes up for page selection, that it does use the default columns; perhaps there could be some way to integrate lister pro, so that VPS doesn't need to take on the task of configuring the lister; in other words for users who don't have lister pro, then bookmarks seem to be the only way to store a 'view' for the popup, but if you have lister pro, then maybe you could specify the name of a lister to use and then the module could read those settings for the popup in that case, or even maybe there could be a way to export a lister pro setup into VPS popup screen..

@Robin S after additional tests, I've found that the "007" release works as expected for fieldset visibility only outside individual templates (fields visibility overwrite). correct?

Yes, that works, thank you so much -- I knew there was nothing the Processwire API couldn't do

I'm even more confused than you . That's the main source of my confusion. This was working before and I remember you asking this question previously. I have now checked, way back to VPS3 and it's not working! Not even in PW2.7. I don't know if it's a caching issue. Not currently supported but it can be done; we have this in Media Manager. I haven't been able to reproduce this. I've just tested and initSelector works fine here (PW 3.0.84). Strange one. We have no add new button in VPS. Must be a CSS issue related to Bookmarks? When the modal loads (if using default theme), there's a brief flash of some button but then it disappears. Sorry about this issues. However, I am afraid these Lister issues will now have to wait until after the next release of VPS which is quite close. I was going to request a number of you to beta test VPS5 (given the move to PW 3 + the other changes coming in RE Robin's suggestions). I hope you don't mind waiting till that is sorted. Thanks.

It would be good if PW did this by default on module installation. Maybe there is some downside but I can't think of any situations where you want the module config data to look populated (by setting default inputfield values) but not actually be populated. Default values could/should still be set in the construct method so there wouldn't be any notices necessarily. But if the config data was removed from the DB then the config page would appear empty despite default values still being used, which is a different kind of misleading I guess. I'll ponder it some more.

@Robin S - no worries re your custom actions - I totally understand if they are not ready/relevant for public consumption. I also understand where you're coming from regarding module default settings. Generally I don't find it an issue because if the settings page hasn't been saved, then the defaults will be used when running the module so effectively what the user sees is what they will get. But, there are exceptions, and this module is certainly one of them. I have a couple of others as well and I do a settings save on module install to solve this - maybe this should be the standard approach? I can't see any downsides, although I wonder if it is safe to actually remove defaults - what if the module was installed, but the settings db data fields was somehow emptied? I guess you'd have to uninstall and reinstall, but it might be a mess of notices in the meantime, but maybe that is ok as this is not a likely scenario. Not sure how to get everyone on this page though?

I will certainly contribute any actions that would be useful to others, but I only have two so far (the ones you see in my screenshot) and one is a work in progress. The first just an interface for uploading a CSV file, but I don't think this is useful as an action to bundle with the module because the action doesn't do anything by itself - it requires code to process the CSV lines, which would depend entirely on what the user wanted to do. The second is part of an exploration of how to resize existing images to save on disk space. I have a lot of older sites from before client-side resizing was introduced, and users have uploaded massive images that waste a lot of disk space. I'd like to upgrade PW on these sites and then loop through all the oversized images and replace them with smaller versions. I've worked out how to do this, but again I don't think it makes for a useful action to share. Firstly, for a large list of images this should be broken into smaller jobs that run on a LazyCron (or maybe the new Tasker module) to avoid a timeout. And secondly this is a destructive process that has the potential to do a lot of harm if used incorrectly, so I wouldn't want to put this out there and maybe contribute to a disaster. Yes, that's what happened. No need to change from using the module config data to populate the table - I can understand why it wouldn't be good to parse all the files every time the list is loaded. But as a more general issue I think that perhaps module developers should rethink how values are populated to the module config page. Currently nearly all modules, mine included, set default/fallback values for config inputfields by just setting the value for the inputfield as it is added to getModuleConfigInputfields() (or one of the many equivalent methods for defining config inputfields). There is probably a tutorial somewhere that started this practice. The problem with doing this is that when viewing the module config page, there is no way for the user to distinguish between values that are actually saved to the config and values that will be saved to the config if the config form is submitted. I'm sure I'm not alone in expecting that when I view the module config page I am seeing the config values that do exist, not ones that will exist if I submit the form. Each time I think about this I get different ideas about what the best solution would be. Currently I'm thinking that we module developers should be saving the config values that we want to be the default config as part of the module install method. Then we don't set any default/fallback/other values in getModuleConfigInputfields() besides those coming from the saved module config. That way the user can have confidence that whatever they see in the module config page is data that actually exists in the saved config. And if the module does display config values that are not actually saved yet these should be highlighted in some way. Any thoughts on this?

IUC in action:

yeah, if you haven't used it yet, it almost becomes a 'can't live without' - on sites where you do use a URL field, it saves a ton of clicking, super convenient, been using it since way back when it was it's own module..

Just basic test fields.. sometimes just some basic fields do break something. If I know that you use an email field with the checked option verify email address, it's pretty easy for me to submit a hotfix and exclude it from the counter. Thanks @maxf5 for pointing it out. You don't have to use the prefix at all. All fields which are added by the module will be prefixed – just to make sure the name has not been chosen yet. Please do not rename scf_website and scf_date because they are used for spam tests. The rest is up to you!

I really like the idea and the direction this article takes but there is one thing that ... has some kind of aftertaste. You are writing ProcessWire ist sicher (ProcessWire is safe) and telling people that there are no documented security issues but linking out to a page that tells something different - at first people will only see: Github ... ProcessWire... Issues... Security... security... security... I know about PWs high level of security but even I had to take a much closer look at those issues. Your audience could get this horribly wrong without further explanations as they will not dive deeper into those issues.

Thanks @Robin S, awesome support! For whatever reason, my fieldset did not changed its behaviour from 0.0.6 to 0.0.7, I still cannot control it via custom selectors after page save. I reverted back to the combo presentation "closed" and checkbox fieldtype "yourcheckboxfieldtypeName" as "not checked", as this is still a working solution for me. I mean, when the checkbox is checked and the page is saved, than the fieldset is showed. If not checked, the fieldset is hidden via css

you need to echo out your desired array key, or object property, depending on what you choosed. You choosed an array for the return, therefore you need to output the key "FNumber" of the array: $result = $page->galleryimages->first()->getExif( array('FNumber') ); // output the value for one key of the returned array echo $result['FNumber']; // if you have choosen the result as object, you would use echo $result->FNumber; This all you can read in the initial post of this thread.

Yeah, you have the page id correct. Did you try echoing: $settingsPage->id like I suggested? If that works, check other fields on that page and see if somehow it's just the store_hours field.

Wondering if anyone has had any luck configuring templates for ckeditor?... the plugin is included with the default package, and enabling it was easy enough, but setting the config to recognize the path to the custom templates is not working... i could edit the default in the wire/ckeditor. but somehow there must be a way for the system to allow for the setting of the custom templates js file i tried adding this to my additional config options templates_files:/site/templates/js/mytemplates.js but am getting js errors of all sorts.. and the template popup is blank also tried adding this to the config.js in /site/modules/InputfieldCKEditor CKEDITOR.editorConfig = function( config ) { config.templates_files = [ '/site/templates/assets/js/mytemplates.js' ]; }; but that didn't work either... Edit: Decided to go a different route, and simply create a module that will append stuff to the current page body, based on a page select field; this way I can create my templates (which i call boilerplates) in processwire and then insert those boilerplates right into the editor and make modifications from there... using it for text mostly but could be use for almost any content you might need to reuse in an RTE... here's the gist.. https://gist.github.com/outflux3/cf5807ddedfaa5c0d425#file-gistfile1-php if anyone is interested and looks at it, let me know if you see any issues or potential problems; this will always append the body fields of the selected pages to the current page body field and then remove those from the page select field... working well in some initial tests

The problem is that page $f doesn't know the repeater item changed. Those repeater items are individual pages themselves. You can solve this by saving the repeater item ($g) rather than the owning page ($f): 1. Replace your $f->save(); with $g->save(); 2. Also replace your $f->of(false); with $g->of(false); 3. Lastly, I also suggest replacing your first line with this: $found = $pages->find("parent=/invitations/$user->name, guests.guest_name=" . $sanitizer->selectorValue($form['oldname'])); Adding that selectorValue() sanitizer in there will prevent problems from occurring if the guest_name happens to contain characters like commas or quotes.