Robin S

The module(s) is a helper for working with images in rich text fields. So part of the functionality is about inserting and applying attributes to images in the RTE and part is sizing the images and and generating markup based on those attributes via a textformatter. Currently I'm splitting this functionality into two modules, but I would rather do it in a single module with a single configuration page. Not sure why it should be forbidden to autoload a textformatter module. To work around this, if my module extends WireData instead of Textformatter is there a way to manually apply a textformatter method via a hook? Edit: thinking some more, the textformatter side really does need to be separate so it can be applied selectively to fields. So two modules it is.

I just needed to fiddle around some more to find my answer. $image_fields = $fields->find("type=FieldtypeImage"); Looking at the data for a field I guess you can also find fields by id, flags, name and label. Nice!

What kinds of things can go inside a $fields->find() selector? Can I use a selector to find fields of a given type? For instance, find all fields that are instances of FieldtypeImage?

Is it possible to have a module that autoloads so admin methods can be hooked and also works as a textformatter? Or is creating two modules the only way? Setting an autoload value in getModuleInfo() seems to have no effect if the module extends the Textformatter class. Two modules would be okay for installation as one can auto-install the other, but needing two module config pages is bit of a pain. And the only other solution I can see is having one module store config data for the other, and that seems wrong.

I am finally getting around to exploring PW3.x (3.0.20 to be exact) but the new images field is always showing 'older/low quality' thumbnails. When I first upload the images and have not yet saved the page the thumbnail quality is good. But as soon as I save the page I get low-quality thumbnails and the low-quality notice. Ticking the checkbox to recreate thumbnails and saving has no effect on the thumbnail quality and the message remains. Any ideas how to fix this? PW is running on XAMPP with PHP 5.5.33

included_file.php <?php $fruit = 'banana'; echo "<p>My fruit is a $fruit</p>"; main.php <?php $fruit = 'watermelon'; call_user_func( function() { return include func_get_arg(0); }, 'included_file.php' ); echo "<p>My fruit is a $fruit</p>"; Output: <p>My fruit is a banana</p> <p>My fruit is a watermelon</p> Credit

This works... $module_config = new MyModuleConfig(); $defaults = $module_config->getDefaults(); Does that look okay?? I'm an OOP noob.

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)