MarkE

Just posting this here as I raised an issue some time ago about TextformatterHannaCode module, which has not been responded to or addressed (see https://processwire.com/talk/topic/3745-hanna-code/page/18/?tab=comments#comment-217245 and https://github.com/ryancramerdesign/ProcessHannaCode/issues/26). I have also recently raised a PR (https://github.com/ryancramerdesign/ProcessHannaCode/pull/27) to fix it. Essentially the problem is that, if you have a PHP Hanna Code which is namespaced (ProcessWire), then the module will remove the namespace (irritating in itself), but also (and maybe more seriously) it will omit the line if(!defined("PROCESSWIRE")) die("no direct access"); which is potentially a security weakness. The PR is a simple one-word fix.

A slightly odd case this: I have a WSL/Docker/ddev setup that has been working very well. Then, for no apparent reason, Docker Desktop failed to start the docker engine. I tried all the suggested fixes without success so decided to uninstall it and run Docker from within WSL instead. After successfully doing that, I found that the db was empty so PW would not run. I imported a recent backup database from the production site into the empty db using phpMyAdmin and it appeared to be OK. However, on running the PW site, I got a 500 error. I tried importing an old dev backup and that worked OK. So, now I had PW running in dev, but not with the latest database. I then tried to use the PW backup tools to download the latest version from the live site and upload it into the dev site and got the following message after clicking 'upload': ProcessDatabaseBackups: File could not be downloaded (https://[Database path].sql) 403 Forbidden: (tried: curl) Any idea what might be causing this and how to fix it? At the moment I am stuck without being able to work on a current database version and can't get it successfully imported via either phpMyAdmin or PW. One thing that looks rather odd is that the message says it can't be downloaded (not uploaded) and that the database path given is a path to site/assets/files on the LIVE site. EDIT: Also, I see that the uploaded backup IS listed on the backups page. However, restoring it results in errors*. All a bit random and confusing! * The error appear to be because not all modules are loaded. Commenting out the calls and refreshing the modules seems to fix this.

@ryan - this still seems to be open. I assume the intention is not to add the namespace if it isn't in the hanna PHP code, otherwise it should be added and so should the 'die'. I think, in that case, the fix is simple - replace the line `$code = str_replace($openPHP, "$openPHP\n$firstLine\n", $code);` by `$code = str_replace($php, "$openPHP\n$firstLine\n", $code);` The existing line does not work because, if namespace was in the code it has been removed, but $opnPHP includes it, so the str_replace does not operate. I have created a PR for this ----------------- If you do not have namespace declarations in your hanna code php and need them, then the following executed in Tracy console seems to do the trick: $h = $modules->get('TextformatterHannaCode'); $codes = $h->hannaCodes(); $codesAll = $codes->getAll(); foreach($codesAll as $code) { $codeString = $code->code; if(!strpos($codeString, 'namespace')) { $codeString = str_replace('?php', '?php namespace ProcessWire;', $codeString); } $code->code = $codeString; $codes->save($code); }

Does anybody use this and/or have a guide for using it with ProcessWire? There are guides for various CMSs and frameworks and they are open to more.

Interesting question. I am increasingly putting hooks in module ready() methods rather than ready.php, which naturally leans to the second approach, so I’d be interested if anyone has benchmarked this.

Another thought, you may want to record invoices separately from orders, to deal with unsatisfied or partially satisfied orders. Alternatively this might be handled by status fields on order lines. At the risk of repeating myself, getting the business specification right is paramount. PS I absolutely agree with @teppo regarding decimal fields. A slip on my part.

Another reason for doing some deep thinking about the entity model before choosing. If payments can only ever belong to an order (and only one order) then they should be children of the order otherwise they risk being orphans. If payments can cover more than one order, then they should stand alone, but you need to do serious thinking about how they are allocated to each order if the amounts don’t match exactly. This might be achieved via an “allocation” field (float or decimal) in the order and the payment. And/or you might need to split orders down into order lines. An accurate understanding of the business model is required. Plus how it might evolve. Then do the entity modelling. Lastly decide how to implement in PW. And don’t forget that @Robin S‘s excellent ConnectFields module is just the biz for maintaining many-many relationships (e.g. between the two allocation fields referred to above).

I would think it all depends on the cardinality of the relationships. If one-many then children are fine. Otherwise group separately and probably use ConnectFields module.

Not sure why @ryanintroduced that. Should we request reversion?

Nothing really. You just make sure PhpStorm is listening then run “ddev debug”.

Probably worth mentioning that since moving to ddev, I have found that xdebug works well with PhpStorm too. Much better than Laragon. My mileage!

Something like this hook in your ready.php file? wire()->addHookAfter('InputfieldSelect::render', function($event) { $inputfield = $event->object; if($inputfield->name == 'my_select_field') { if(count($inputfield->options) == 1) { $inputfield->description = "text for one item"; $event->object = $inputfield; $event->return = "<p>{$inputfield->options[1]}</p>"; } else if(count($inputfield->options) == 0) { $event->return = "<p>No options!</p>"; } } }); EDIT: Added condition so that it only operates on the relevant inputfield. Also, note that while this fixes the UI, you will need to make sure the value is provided where needed as it is no longer selected (may be possible to address this by making the value required and providing the default value). EDIT2: For example, you could set the value like this: $page->of(false); $inputfield = $fields->get('my_select_field')->getInputfield($page); if(count($inputfield->options) == 1) { $page->test_select = $inputfield->options[1]; $page->save('my_select_field'); } Is that any help @The G?

I now have my project files in the WSL2 environment and that does seem to improve things without mutagen. I also tried running PhpStorm in WSL2 but it was a bit of a pain and no quicker.

Thanks for all the ideas @Jan Romero . Personally I got a bit frustrated with TrackChanges because it seems to be a bit random about what it records - for pages as well as fields etc. That’s why I started using getFresh() for pages with a home-built compare function because it gave me full control and understanding. So my idea was to do something similar for fields and templates (and fieldgroups) - the code above is my attempt at this and no doubt can be improved. The getFresh() for pages is hugely more complex! Nevertheless, I agree that a more robust and consistent TrackChanges is desirable.

That seems to work and might be sufficient if you just want to know if there are any changes. The test that I did - adding a field to a template - gave a curious array of changes in the bar dump, viz: array 'compile' => array 0 => 3 'noParents' => array 0 => '' i.e. nothing about the field that had been added. I have no idea why this is. On the other hand, my getFreshSaveableItem() method returns the complete template before any changes, so includes the related fieldgroup. However it may be slower - I haven't benchmarked them.

I stopped doing that a while back because it was taking longer to recognise code changes. But it may have been down to some problems I was having with PHPStorm, so I’ll try again now those problems seem to be fixed 🤞. Thanks for the nudge.

So here's a (hopefully better and working) solution. Add the following as a hook to (i.e. new method for) WireSaveableItems: public function getFreshSaveableItem($event) { $saveables = $event->object; $item = $event->arguments(0); $database = $this->wire()->database; $sql = $saveables->getLoadQuery()->getQuery(); $query = $database->prepare($sql); $query->execute(); $rows = $query->fetchAll(\PDO::FETCH_ASSOC); $newItem = null; if($item) { foreach ($rows as $key => $val) { if ($val['id'] == $item->id) { $row = $rows[$key]; $newItem = $saveables->initItem($row); // there should be only one matching item break; } } } $event->return = $newItem; } This returns the item as it is in the database, so if you call (say) wire('fields')->getFreshSaveableItem($myfield) in a beforeSave hook, you will get the version of $myfield that is in the database - i.e before it is saved and can compare it with the version about to be saved. But if you want to use this, test it out well first! Maybe someone else can come up with something better (or even a PR for the core?!)

Just bumping this in case anyone has any ideas. As stated above, my work-round is rather clumsy and inefficient. Surely there must be an easier way?! EDIT: I notice that WireSaveableItems has a hookable method ___saved(Saveable $item, array $changes = array()) but I can't find anything calling it with the $changes parameter set.

Not the only thing broken, I think. All recent topics seem to be showing ‘0 views’ even though there are replies.

What software do people like for showing off their modules, websites etc.? I have tried the (free version of) screencast-o-matic and Clipchamp but neither really suits me. The former is a bit simple whereas the latter is rather complex. I'd like to be able to record activity on a screen, pause the recording while I gather my thoughts or segue to a different sequence, add captions (or maybe audio) and cut or append videos. Any suggestions?

The description for 'add new tag' in (say) the field setup in the back-end UI reads 'You may use letters, digits or underscore.' It does not mention capital letters. However, if capital letters are included, they seem to get converted to lower case. On the other hand, via the API you can set $field->tags to have values which include capitals and these are then shown correctly in the UI and is maintained correctly in the API. But if you amend other data for the field (say) then the tag is amended to the lower case version. Is this a bug? What should the proper behaviour be? It has certainly caught me out - assigning tags with capitals in the API which work fine for a while until some unrelated part of the field is changed and then the tag no longer matches the original.

Thanks for all the tips, @Robin S. However one of the fields I need is a repeater matrix and that doesn't seem to support autojoin. Also, while I could get autojoin to work (for other fields) via the field settings, I couldn't replicate your example in my system - none of the requested ('autojoinable') fields were joined. I am on PW 3.0.206. findRaw() works as documented and gets all the fields and may be usable for my purposes, but that doesn't feel like the right answer. It seems like findJoin might be a bit buggy - I'm not sure @adrian's issue has been resolved. But it may be something strange in my set up.

New version seems to do the trick. Thanks @adrian.

Thanks @Robin S . Sort of ‘doh’ as I had heard of autojoin, but never used it or looked into it. That post explains everything, although I wonder if some fuller documentation in the API for $page might be helpful. I guess using autojoin is more efficient than getting the page then using getFields().

Having used PW for a few years now, I feel that this is a really basic question about something that ought to be obvious to me! So I'm prepared to say 'doh!' If I get a page object via the $page API (or page() or $pages or whatever) it doesn't always seem to have the fields fully populated. For example, here is the 'Field List & Values' display (partial) for a page 'gallery-of-apples', it has 5 fields: If I call $page and dump it, all I get is the title field, but by getting the fields via getFields() and setting them, I get the complete picture - see Tracy console image below: What is going on here? Why don't I get all the fields and values with $page?