gornycreative

I am close to releasing a module that adds hook methods to Pageimage that will calculate the main color and/or a palette of dominant colors in an image. I've been looking at different options to store/cache this value based on a comparison of the options array used to grab the first calculation, because with some image sizes and precision factors and the number of images the calculation lags more than you would want on a front-facing site. If the data exisits, use it unless the options array passed along is different than the one stored - in which case recalculate. My initial thought was to store them in the filedata array for the given file, and I can get/pull the item but I cannot save the Pageimage filedata within the hook because the hook runs regardless of whether or not you get the initial images in a formatted or unformatted state. I can grab the data and save it outside the hook method like so: $page = $this->wire->pages->get('name=about'); $images = $page->getUnformatted('images'); foreach($images as $image) { $palette = $image->palette(); $maincolor = $image->maincolor(); $image->save(); } But this makes the process more cumbersome for developers. I'd rather have the hook method somehow be able to grab the unformatted version of the Pageimage from the Pageimages returned by the 'images' field, merge the filedata colors into the filedata array and save it. The problem is I can't see how to query an individual image/file within that Pageimages/Pagefiles array.

I believe what you are looking for is ImportExternalImages - which was designed to allow a user to cut and paste a blog article from another platform like Blogger into a specified text area and then have PW bring in the assets from the URLs that were pasted into a field you set up in config. https://processwire.com/modules/import-external-images/

I tried turning on tags for an image field using the following config: 'detailed_images' => [ 'label' => 'Detailed Images', 'flags' => 0, 'type' => 'FieldtypeImage', 'icon' => 'picture-o', 'fileSchema' => 271, 'maxFiles' => 0, 'textformatters' => [ 0 => 'TextformatterEntities', ], 'extensions' => 'gif jpg jpeg png', 'outputFormat' => 0, 'descriptionRows' => 5, 'useTags' => 1, 'gridMode' => 'left', 'focusMode' => 'zoom', 'clientQuality' => 90, 'inputfieldClass' => 'InputfieldImage', 'unzip' => 1, 'tags' => 'content_components', 'collapsed' => 0, 'columnWidth' => 100, ], But when I try to edit a page that has the field in the template I get a SQL error: 'field_detailed_image.tags' column not found in 'field_list'. I tried looking deeper into the methods and thought perhaps calling getDatabaseSchema would call the private updateDatabaseSchema but it seems like that doesn't work. I have turned off useTags in the meantime but I'm guessing this affects any fieldtype that extends fieldtypeFile.

I'm afraid I have listened to this loop way too much since I discovered their long-form channel.

Exactly why I asked. And there is a potential solution actually and I found it and started working on some things and forgot to come back to this. The getTableData() function for fields seems to pull just the configured settings in the database table. getExportData actually uses the data from the getTableData call and merges it. It's in wire/core/Field.php

Frames reminded me a lot of Pinegrow - https://pinegrow.com/ - which has some pretty handy shortcuts in the WP version for breaking out flat HTML designs into loop and block files. Once Yootheme Pro started incorporating real-time previews of custom fields and post/page types it finally started catching up to the flexibility and convenience of certain types of PW builds. I am still finding it faster to work in PW, even though I have had a lot more experience with WP.

Never mind. The simplest way to do this is include $rm->watch methods in ready.php that cover the subset I want to pay more immediate attention to and then run migrate those watched files there: $rm = $this->wire->modules->get('RockMigrations'); $rm->watch($wire->config->paths->site.'/migrations',2); $rm->watch($wire->config->paths->site.'/migrations/matrixtypes',1); bd($rm->getChangedFiles()); // Just to check on things. $rm->migrateWatchFiles();

Say I define in my migrate.php: $rm = $this->wire->modules->get('RockMigrations'); $rm->watch($this->wire->config->paths->site.'migrations',3); $rm->watch($this->wire->config->paths->site.'migrations/matrixtypes',1); Suppose I make a change/save/touch this file as /site/migrations/matrixtypes/meta_zone_1.php: <?php namespace ProcessWire; $rm = $this->wire->modules->get('RockMigrations'); $rm->setMatrixItems('meta_zone_1', [ 'profile_image_block' => [ 'label' => 'Author > Profile Image Block', 'head' => '{matrix_type}', 'sort' => 1, 'fields' => [ 'profile_image_block_layout' => [ 'columnWidth' => 50, ], 'profile_image_block_bio' => [ 'columnWidth' => 50, ], ], ], ]); I've brought in the RepeaterMatrix functions from v1 and added the filetype test to createField - let's assume that. Manually triggered these work. When I run $rm->getChangedFiles() I can see the saved file in the list. A change was detected. If I run $rm->migrateWatchFiles(); the file is rendered and the repeatermatrix item is added. I need to run that method, however, in say Tracy console for the changed files to be seen and migrated. However, when I make changes to watched modules and pageclasses that use MagicPage the migration methods automatically run the next time I load an admin page after saving my changes. How do I get that behavior with watched php files that aren't magicpages or in a module? I can see that ready() in the module contains migrateWatchFiles() - I'm guessing it should be firing? If I add bd($this->getChangedFiles()); ahead of this, it always returns an empty array even though when I run the same method in Tracy it detects changes as I save different files.

I don't know why, but I'm not able to get watched files to trigger. They appear in the watchlist when I run a dump. There are rockmigrations methods in the files. I've set the files to force = true in the watch method in migrate.php. I'm at my wits end. migrate.php triggers on change. Page classes trigger on change. I can't get a single watchfile to trigger. Is there a format to watchfiles that I am missing? Edit: The reason I am running into this now is because I had been keeping field migrate definitions and matrixtype definition methods all on one file but that is starting to get hefty and so I wanted to break out the matrix definition types for various repeatermatrix fields into separate files that would only trigger when a new type was added.

I tried moving the error checking portion that tests for admin and processes form input to the ready() and left the hook definitions in init() and it seemed to work fine as written.

If I do a bd in Tracy: /** * Initialize the module * */ public function init() { $input = $this->wire()->input; // $isAdmin = $this->wire()->page->template->name === 'admin'; bd($this->wire()->page); //Should be the same bd($this->wire->page); //But Just in case I get this: Not even a NullPage object which would at least be something. I found a similar method in a thread from years ago where the limitations of init() were also mentioned. I can't recall if that's the first place I'd seen - it - perhaps in the core code itself? From wire/config.php - I think this is where I first saw hints that anything done in init() doesn't know what page exists. But this doesn't say explicitly that you couldn't *get* the page while in the init context, just that the API var isn't instantiated yet. I'm wondering if bumping it to the ready() state would be an option? The thread I linked never really came to a satisfying conclusion - but I'd also like to know if there is a definitive best practice for how to do this. @horst @Robin S ?

Hey there, I'm trying to track down some PHP warnings, and one comes from this module. I understand you are trying to do some error checking in the configuration in the init() function, but unless I'm totally off on this there is no page context for the init() function in modules. I get two warnings on line 68 because template is run on null and name is run on null.. $this->wire->page in the init() method is null because as far as I understand when the init() method is run there is no page actually loaded yet. As a result $isAdmin is never true and that entire module config test block never loads? The hooks are outside the block - so no problems there, but I'm guessing that clearing variations from the module config doesn't work.

What is the best way to get an array of the default settings for a given fieldtype, and are these defined at the core module layer or a class layer or somewhere else? This seems to be where I should go but I've had problems figuring out exactly how to call it abstractly: https://processwire.com/api/ref/fieldtype/get-config-array/ I'm not talking about the configuration for a fieldtype instance, I mean the config of the class.

When you have a Page Reference inputfield, there are two different template options settings: With the standard migrate() config array, the template_id setting gets processed fine if you use a template name instead of the template_id - the green checkmark. The template_ids setting does not get processed if you use template names. Nothing appears. Adding the processing block I wrote above allows template names to be used in that template_ids setting.

Sorry I'm working in @gebeers RepeaterMatrix fork right now, but if you could add around 3200 in RockMigrations.module.php: (This is below the $key === "template_id" conditional test block.) if ($key === "template_ids") { foreach($val as $sub => $tpl_name) { if (is_string($tpl_name) and $tpl_name !== '') { $tpl = $this->getTemplate($tpl_name); if (!$tpl) throw new WireException("Invalid template_id"); $val[$sub] = $tpl->id; } $data[$key] = $val; continue; // early exit } } This would allow the 'Selectable Pages > Additional Templates' setting on Page Reference fields to migrate the 'template_ids' setting properly with template name references into of raw ids in a similar manner to the template_id setting conversion.

Okay. I'm playing around a little bit with the getCode functions to pull names instead of IDs for certain things and looking at the repeatermatrix situation a little more but I will also look at the tab add situation after.

I'm looking at the code for wrapFields() - is this only for Fieldset and not FieldsetTab? If you are using custom tabs is adding a FieldsetTabOpen field type still recommended and then $rm->addFieldToTemplate('fieldname', 'content-page' , 'tab', 'tab_END'); still the best way to do it?

That's very helpful - thanks!

I have been using $page->sort settings to try to migrate consistent page arrangements and all has gone well except I can't seem to alter the sort arrangement of the error page. I know it is a reserved page. I can alter the sort order between the various reserved pages but I cannot get it to appear higher. The strange thing is that I can set the sort number and if I try to find all pages off of the root page and and sort them by sort: $list = $this->wire->pages->find("parent=1,sort=sort",["include"=>"all"]); and then db($list) the error page does appear properly sorted in the array that results: But in the Pages menu, it remains lower: Are reserved status pages special in this regard?

If you want - I'm not sure if others just haven't ticked the box and gotten the errors, but if its more internal use for you I won't bother with it. Thanks.

Regarding the "include version in admin footer from package.json if it exists" feature - I'm a little confused about what this is for. The code points to the package.json in the site root, not the module root. https://github.com/baumrock/RockMigrations/blob/d957caeb5e4607d0b0afbb00ef18cdcb52895d83/RockMigrations.module.php#L923 But I don't think Ryan stores the processwire version there - which version number is this supposed to show? RockMigrations? My site root package.json looks like: { "dependencies": { "htmx.org": "^1.8.6", "jquery-typeahead": "^2.11.1" } } I started looking into this because I was getting a stdClass::$version warning.

Thank you for addressing this so quickly!

Changing line 40 in TextformatterTypographer.module.php from: public function getModuleInfo() { return json_decode(file_get_contents(__DIR__ . '/TextformatterTypographer.info.json'), true); } to: public static function getModuleInfo() { return json_decode(file_get_contents(__DIR__ . '/TextformatterTypographer.info.json'), true); } resolved the installation issue.

Hi @Mike Rockett I just tried installing this on a dev version of pw 3.0.220 and it seems the new module overhaul might have picked up strange behavior: I mentioned this in a thread of Ryan's also as I'm not sure where the incompatability lies. I also noted that php-typographer has advanced to v6.7.0 which includes some php 8.1 deprecation resolutions.

Had an unusual experience trying to get TextformatterTypographer to install. Looks like it is just essentially a wrapper around a composer library install but for some reason the InstallModule process choked on it with v 3.0.220 If this is a plugin problem I can address it there. The plugin needed to declare the getModuleInfo() function as a static function. Once I added the static attribute the installation went as normal. public static function getModuleInfo() { return json_decode(file_get_contents(__DIR__ . '/TextformatterTypographer.info.json'), true); } I've added the fix request in the plugin thread. I'll leave this here in case there are other older modules that have similar issues.