Robin S

This should be saveModuleConfigData() not setModuleConfigData() - thanks kongondo Yes, that's what we mean. Or clicking "Save" on the module config screen. Most modules that I have looked at don't do saveModuleConfigData() on install. Random example: TextformatterVideoEmbed This doesn't work - getDefaults() is a method of the ModuleConfig class, or MyModuleConfig class which extends ModuleConfig. It's not a method in the module class.

I don't see how Table can help here, because it doesn't allow for dependent selects (i.e. selects that change options/pages based on the value of another select in the same row). And it doesn't include SelectMultipleTransfer as one of the available inputfields. Did you investigate to see if a PageTable (hereafter 'PT') could work for you? Dependent selects work here, you can use "show if" settings to control field visibility, and you can choose the PT template fields you want to see in the table. So it seems like it would be a good solution. If you define a parent page for the PT pages and set a dedicated template for that parent page you can then use the "Name format for children" option to skip the page name step when adding new PT items. See the Setup Page Name module for more name format options. As the for the title field for the PT items: either set it non-global and remove it from the PT template, or use an 'added' hook to set the title automatically and optionally a 'saveReady' hook if you want to form the title from field values in the PT page. I can elaborate on this if needed.

This would work, and it would be a solution if the module you want the config data for is one that you have created yourself. But most modules, whether they use the old or new way of setting config defaults, do not do this. The old and new way of setting module config perform the same as far as I can tell, in that both do not make the defaults available to getModuleConfigData() unless the module specifically saves them with setModuleConfigData(), which is what horst is suggesting. But it's not common for a module to actually do that. Modules do not need to force a manual save for either method, so long as you only care about making the default values available within the module itself. I agree that it's desirable for getModuleConfigData() and getConfig() to return the config regardless of whether the config consists of the defaults or a manually saved variation to the defaults. It's not really an edge case because it's quite common to leave a module config at the defaults I think. For modules using the newer ModuleConfig class it seems like this should be possible because there is a standardised way of setting defaults. For modules using the older config I suspect this wouldn't be possible because of the variety of different ways defaults are stored and used inside those modules. Back to my immediate problem: assuming the module I want the config defaults for uses the ModuleConfig class, how can I use the getDefaults() method to return the array of defaults? I can get the individual values by name like this... $modules->getModule('MyModule')->my_value ...but I want the array of all values so I don't need to know and specify each by name. The getDefaults() method is in the MyModuleConfig class, but that isn't a module itself so I can't do something like... $modules->getModule('MyModuleConfig')->getDefaults() But there must be some other way to access that method, right?

Thanks. I was wrong about defining config with getModuleConfigInputfields() - I can't get the default config data with getModuleConfigData() unless the config page has been saved, and that applies to either method of setting the default config. So if getModuleConfigData() only works if the module config page has been saved, how do I get the default config data if the module just been installed and the config had not been changed or saved? Any defaults set for the config work in the module exactly the same as if they had been manually set, so it's frustrating to need a different method for getting the default config. I guess we have to check to see if getModuleConfigInputfields() returns an empty array and if so check something else to get the default config. The new way for setting module config extends a core ModuleConfig class, and contains a method getDefaults() that returns the config defaults in an array - this sounds like exactly what I need, but how do I call this method to get the defaults array? My objective is get the config data for one module inside another module.

If I set my module config data the old-fashioned way, in the main module file with public static function getModuleConfigInputfields(array $data) { ... then I can get the config info successfully with $modules->getModuleConfigData('myModule'); Edit: I was wrong about that - it only works if the config has been manually saved. But if I set the module config in a separate file using the ModuleConfig class then getModuleConfigData() returns an empty array. Any idea what I'm doing wrong? Update: I have got it working but it's still a bit strange. I can't get the config data if the module config page has never been saved (i.e. it is in its default state after install). Once I save the module config page I can get the data with getModuleConfigData(), even if I haven't changed anything from the default settings. A bug maybe?

Good news: you can have dependent selects Bad news: it has been said that dependent selects do not work inside repeater fields I've never tried them inside repeaters myself. I say give it a go, particularly if you are using PW 3.x because repeaters have had some upgrades there. If it's still a no-go maybe a PageTable could substitute?

That JS for inserting images into the CKEditor field is really cool! For setting the width with the "small" command, try: element.setAttribute('width', 100); For anyone trying out Can's code, note that the JS that adds the HappyImageSelector is for PW3.x image field markup. Not hard to adapt to PW2.x though.

For something like this you can use normal fields (i.e. page/options select and text fields), and set the widths of the inputfields so they appear in row groups. If you want a single heading across both inputfields something I have done in the past is: create a fieldset, place the grouped fields inside the fieldset, use AdminCustomFiles to hide the labels of fields inside the fieldset.

I had this problem, and I believe it's caused by deleting the default lister (aka "Find"), which is something that becomes possible when Lister Pro is installed. If you have done this the solution is to create a new lister called "Lister". Because the default lister is used by the core it would be better if Lister Pro did not allow you to delete it, but instead made it simple to disable it for non-superuser roles. If you have other Lister Pro instances and you don't want certain roles to see the default lister you have to set up a special permission for the default lister and then not apply it to a role. There's definitely scope to make this process a bit clearer and easier for Lister Pro users.

For static links you could use AdminCustomFiles and append the links with jQuery. Beyond that you could duplicate and rename the admin theme module and then code in whatever links you need, as I don't think the menu render function is hookable (for the default theme at least). Or a process module, as you say. Also, if by internal links you mean links to edit a particular PW page remember that you can set up page edit bookmarks.

I've been browsing through the core module settings (found some unknown-to-me goodies in InputfieldPageName, JqueryWireTabs and ProcessField) and I came across the ProcessPageType module. This module has a setting (empty by default) for "What fields should be displayed in the page listing?". What does ProcessPageType do and where in admin its interface?

The suggestion by gebeer can achieve that markup - you just need to modify the PHP used in the Hanna code. If you consider it's not user friendly to type the Hanna code then you can make use of the Hanna Code Helper module. If you wanted to support multiple galleries per page and don't want to worry about the 'show' limit in gebeer's code it occurs to me that you could create a repeater field, the template for which contains only an images field. Then your Hanna code could get then nth repeater item (as specified by the user in the Hanna tag) and output its images. Shouldn't be too difficult to code. Downside is the user would need to be instructed not to reorder gallery repeaters after they are in use. ...the template for which contains a title field and images field, and the the Hanna code finds the gallery by title. That said, to do this type of layout (and an infinite number of others) properly I recommend the Repeater Matrix - it's a pro module but well worth the cost.

Thank you adrian, that file has fixed it.

I resolved this issue - it was related to the default SQL mode changes introduced in MySQL 5.7 I set sql_mode to the previous MySQL version's default of NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION and all is good now.

@seanmvincent Yes, you can't use Hanna Code recursively with the current version. But see this post and this pull request - you could manually update the module with the code from the PR.

More strangeness: the timestamp in the error log and the timestamp in the database for the same comment are exactly 1 hour different. Error log: 10 hours ago 2016-05-30 08:48:19 puppyfan /stories/punters-favourite-is-one-very-fast-goat/ SQLSTATE[22007]: Invalid datetime format: 1292 Incorrect datetime value: '1464551299' for column 'created' at row 1 (FieldtypeComments) Database row: 1204 Good on you Calum for taking the risk on the Goat.... 3 114 1 puppyfan barry+six@mydomain.co.nz 1464554899 1590 122.58.151.116 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) Ap... 0 0 HfDxzuBCb8t8d6uVQWYJeiDFFouiA9dAXGb_qhx_2lK9vlnIbP... potLYc_2ERq9vc7RGD42xyTr81tfOZk3qSMMKR77 0 0 NULL Note the difference of 1464551299 vs 1464554899, which is 2016-05-30 07:48:19 vs 2016-05-30 08:48:19

Thanks for the help, really good advice. I think I have found the source of the problem, and the answer came from looking in the PW error log (duh!). There were a heap of similar 'Invalid datetime format' errors there, and most mention FieldtypeComments. An example: SQLSTATE[22007]: Invalid datetime format: 1292 Incorrect datetime value: '1464551299' for column 'created' at row 1 (FieldtypeComments) All the errors are for row 1, and I suspect even the ones that don't mention FieldtypeComments relate to the comments field because they are identical in all other respects (apart from the timestamp of course). When I check the FieldtypeComments table in phpMyAdmin I can see that all the entries the 'created' column are indeed saved as timestamps. Some strange things: 1. My comments field continues to work normally and all the comment times are displayed correctly on the front-end and back-end. 2. When I ran the SQL query suggested by Bill C my comments field was not one of the ones listed (results were 2 x file, 4 x image, and 1 x procache tables). Is the comments fieldtype meant to store its times in datetime format? Could the table perhaps have been created wrong on install with the wrong data type for the 'created' column? I know little about databases and not sure how to check this.

@Hardoman, It's certainly possible to have multiple menus generated by MSN on the same page. Having a desktop menu transform into a mobile menu is more about the CSS you write than MSN. There will be many ways to skin the cat, but I often use three menus per page: 1. A single-level horizontal menu of top-level pages (show at desktop widths, hide at mobile widths) 2. A vertical sidebar menu containing descendants of the root parent (show at desktop widths, hide at mobile widths) Example: $nav = $modules->get("MarkupSimpleNavigation"); echo $nav->render(null, null, $page->rootParent); 3. A mobile menu that contains all pages (hide at desktop widths, show at mobile widths)

Thanks, that was my first thought too. But I think it's actually a MySQL error code - Googling shows a lot of non-PW issues with the same code. I don't have any login/logout hooks, but I do have custom code for front-end user registration/login/logout. One thing I noticed that might be related is that when I add the 'Created' column to the Users lister (Access > Users) I see that the guest account and the superuser account were created '5 years ago'. Is that normal or a sign that something may be wrong with the created date for these users?

Thanks for the suggestion. Unfortunately the string 1464507951 doesn't appear anywhere in the database. Maybe it's not saved because it's invalid? Does the "Session: " prefix at the start of the error message have any significance? - I have the core SessionHandlerDB module installed. Or is that shown for all PW error notifications?

A couple of times when logging out (or it might have been logging in) I got an error message like: Session: SQLSTATE[22007]: Invalid datetime format: 1292 Incorrect datetime value: '1464507951' for column 'created' at row 1 How can I trace back to find out the table that is affected here? Anyone know what can cause this error?

Not really an answer to your question, but do these pages under /tools/ have template files? If no, they can't be viewed on the front-end. If yes and you are using them in other pages with $mypage->render() then you can make them not directly viewable by having this at the start of the template file: if(empty($options['pageStack'])) throw new Wire404Exception(); Apologies if this isn't helpful.

You have to add in the pagination. For the total count of matches use getTotal().

I suggest you go a different route. The downside to the way you are finding pages in your code above is that you can't do a consistent pagination of results. This is because you do a foreach() within your results list which produces an unknown number of additional results. So say if you need to apply a limit of 20 results for pagination you could end up with 22 on page 1 and 37 on page 2, etc. To avoid this it's best to get your results from a single $pages->find() operation. You don't show what is going into your $selector variable above, but below is some example code. The variable $search_term would be the sanitized term(s) coming from your search form. // Define the piece of the selector that checks fields for the search term // Let's say we only need to check the body field // But you can expand this with any other fields you need to search $selector_piece = "body~=$search_term"; // First we find any matching address pages $addresses = $pages->find("template=address, address_field~=$search_term"); $categories = new PageArray(); foreach($addresses as $address) { // And add their categories to a PageArray $categories->add($address->categories); } $categories = $categories->unique(); // Strip out any duplicates if($categories->count) { // Now we use OR-groups to say either the body must contain the search term // or the page must have the same category as one of the matching addresses $selector_piece = "($selector_piece), (categories=$categories)"; } // Search the website pages, but not address pages because we already dealt with them // If there is the potential of a lot of matches you should apply a pagination limit $matches = $pages->find("$selector_piece, template!=address, limit=20"); // Output the matches, if any if($matches->count) { foreach($matches as $match) { echo "<p><a href='{$match->url}?searched={$search_term}'>{$match->title}</a></p>"; } } else { echo "<p>Sorry, no matches.</p>"; } And then in your pages where you show addresses in a filterable table: <script> $(function() { $.urlParam = function(name) { var results = new RegExp('[\?&]' + name + '=([^]*)').exec(window.location.href); if(results==null) { return null; } else { return results[1] || 0; } }; var searched = $.urlParam('searched'); if(searched){ $('#filter').val(searched); } }); </script> Adjust $('#filter') to match your filter field as needed. You might need to attach this to a callback that runs once the table plugin has initialised.

I was running an older version of Tracy Debugger (v1.2.9) and just upgraded to the latest (v1.7.7). Using the Tracy dev branch on the front-end I get 'Array to string conversion' errors in all of the panels. Tracy works fine in the back-end with dev branch, and also works on front-end and back-end with the stable branch. An example error: exception 'ErrorException' with message 'Array to string conversion' in ...\site\modules\TracyDebugger\ProcesswireInfoPanel.inc:334 Stack trace: #0 ...\site\modules\TracyDebugger\ProcesswireInfoPanel.inc(334): Tracy\Bar->Tracy\{closure}(8, 'Array to string...', 'D:\\Websites\\__w...', 334, Array) #1 ...\site\modules\TracyDebugger\tracy-master\src\Tracy\Bar.php(93): ProcesswireInfoPanel->getPanel() #2 ...\site\modules\TracyDebugger\tracy-master\src\Tracy\Debugger.php(230): Tracy\Bar->render() #3 [internal function]: Tracy\Debugger::shutdownHandler() #4 {main} PW is running locally on XAMPP, PHP v5.5.33 --------------------- Update: I found the source of the problem - there is a conflict between the dev branch of Tracy Debugger and FieldtypeTemplates (Template ASM Select). Update 2: FieldtypeModules and FieldtypeFields also conflict.