John Heenan

Thanks for the report. For others, the attched file is 9.2MB of deprecated messages logged mainly from files originating in vendors/blesta/h2o/h2o directory. Below I deal with a specific fix for a reported message and an example of an appoach that made 80 IDE reported error messages disappear for a single file with a two line fix, that may also be reported in messages. A specific fix that fixed five errors in one go when fixing one: Here is one of the reported messages: ... general.NOTICE: E_DEPRECATED: ...{"code":8192,"message":"Creation of dynamic property H2o_Token::$type is deprecated","file":".../vendors/blesta/h2o/h2o/datatype.php","line":110} Download the source code, open in VSCode, use a php extension such as inteliphense and hover over red underlined part of line 110 to see undefined property type message. All five red lines disappear with one line added: protected mixed $type, $content, $result, $position; A more general approach that fixed 80 reported IDE errors in one go: There may be an incredibly easy to fix a lot more very quickly that I have noted to try. Just poking around within VSCode IDE shows file components/invoice_templates/perforated_invoice/perforated_invoice_pdf.php has 81 problems: Who wants to fix problems like this? However, with a change of two lines from to I can make 80 of 81 reported problems disappear.

This bug has alredy been fixed in Blesta 5.10.0-b2 beta, which was released nine days ago. I missed the release because b2 beta was not announced in the Blesta software feed reader. The fix used is the same as a shorter fix included in a post by me below. The fix I included for the upgrade/downgrade bug is also included in b2 beta. Thanks Blesta

Blesta: 5.10.0.b1 PHP: 8.2.18 OS: Debian 12.5 Line 871 in Virtualmin module file virtualmin.php, in editService function, now causes an error instead of a deprecation message with php 8.2.17, with array_key_exists: if (!array_key_exists($key, $service_fields) || $vars[$key] != $service_fields->$key) { $service_fields is a stdClass, not an array. Reference for array_key_exists is at https://www.php.net/manual/en/function.array-key-exists.php One line fix is : if (!property_exists($service_fields, $key) || $vars[$key] != $service_fields->$key) {

This fix, however, does not fix the issue of file present but uninstalled plugins having their events read and newly instralled plugins having to wait for the cache to be renewed for their events to be rrecognised. Cache renewal is forced with cache deleion.

There is a one line fix for cache requiring deletion (for incoming webhooks to work) at:

There is a one line fix for cache requiring deletion (for incoming webhooks to work) at: There is also another posted fix to allow incoming POSTJSON to work.

With Blesta 5.10beta1, an incoming Webhook fails if the cache is used. The cache is incorrectly constructed. Following is a one line fix. Edit line in plugin file webhooks/models/webhook_events.php FROM 'file' => $file->getRealPath(), TO 'file' => (new ReflectionClass($class))->getFileName(), This inserts the correct file name for later use within the cache. The reason the workaround, which is to delete the cache, works is that when the cache is constructed the correct required file gets included in order to construct the cache, along with many others, from using @include_once $file->getRealPath(); earlier. The $file variable is stale when used as above. Using reflection avoids having to construct an earlier mapping of each found Observer class to the file name it came from.

With Blesta 5.10beta1, incoming Webhook call backs with GET and POST have been confirmed to work with a workaround (link at end). POSTJSON does not work. Following is a one line fix. Edit line in file controllers/trigger.php FROM $params = json_decode($post); TO $params = json_decode($post, true); Explanation for fix: from https://www.php.net/manual/en/function.json-decode.php, setting the second paarmeter to true guarantess the decoded json will be returned as an associative array instead of an object. Currently a workaroud is required to get incoming Webhooks to work. Information at

With retesting, POST does work, POSTJSON does not work without source code alterations as the JSON is passed as a class object and not an array. New topic posted at

Both GET and POST for incoming webhooks works. POSTJSON for incoming webhook does not work without alteration of source code as the incoming JSON parameters are passed as a class object, not an array.

The name of the event to form an incoming callback for in Webhooks is WebhooksIncomingExample.add The cache has to be deleted twice: once to even view the event to register the callback, a second time to successfuly obtain a result (with repeat deletion). More informration in topic linked to in above post.

Blesta: 5.10beta1 PHP: 8.2.17 OS: Debian (stable, bookworm) Attached is a zip file of a plugin called webhhook_incoming_example, link webhooks_incoming_example.zip, that can be used to demonstrate an incoming webhook. Problem is the webhook only works ONCE after the webooks cache has been deleted, such as with command: rm cache/?/plugins/webhooks/* After calling once the cache is recreated and just an empty answer is returned, while the cache exists. This suggets there is a Webhooks cache bug. Whatever is recorded and read back from the cache is not reconstructed to its original pre saved form. If an oncoming GET webhook has been setup with callback 'webhooksexampleadd', then the following URI path can be used to add two integers a and b with values 1 and 2: /admin/plugin/webhooks/trigger/index/webhooksexampleadd?a=1&b=2 The answer after cache is deleted is returned as {"__return__":{"a":1,"b":2,"c":"a (1) + b (2) = c (3)"},"a":1,"b":2} The answer, until cache is deleted again is [ ] There is more information with images in topic at

Some notes on progress. 1. I added in the following two functions below the automatically generated getEvents() function in sample_a_plugin.php (part of SampleAPlugin class) public function SampleaAdd(EventInterface $event) { $params = $event->getParams(); $this->logger->info("SampleaAdd $params", [$params]); $a = (int) ($params['a'] ?? 0); $b = (int) ($params['b'] ?? 0); $c = $a + $b; $resultadd['a'] = $a; $resultadd['b'] = $b; $resultadd['c'] = "a ($a) + b ($b) = c ($c)"; $event->setReturnValue($resultadd); } public function triggerEvent($name, array $params = []) { $this->logger->info("triggerEvent", [$name, $params]); $eventFactory = new EventFactory(); $eventListener = $eventFactory->listener(); $eventListener->register($name, [$this, $name]); $event = $eventListener->trigger($eventFactory->event($name, $params)); // Get the event return value $returnValue = $event->getReturnValue(); // Put return in a special index $return = ['__return__' => $returnValue]; // Any return values that match the submitted params should be put in their own index to support extract() calls if (is_array($returnValue)) { foreach ($returnValue as $key => $data) { if (array_key_exists($key, $params)) { $return[$key] = $data; } } } return $return; } 2. I left the SampleAObserver class where I had previously added it in as above (at the end of sample_a_plugin.php and outside SampleAPlugin class). 3. I could only get incoming webbhook events triggered with a GET request. A POST_JSON request causes confusion because an object gets passed through instead of an array. I could not get a plain POST with parameters recognised, the parameters were ignored. 4. The incoming webhook only work ONCE after the cache is busted. After this the event is not triggered again until the cache is busted again. 5. In my example, setting an outgoing POST_JSON webhook for the same incoming webhook resulted in the data form the incoming request getting echoed, not the results of the event triggered. This makes sense. The triggerEvent function can be expanded to fire a second 'after' event which can include both the original paremeters and the result, which can be subscribed to instead. 6. The outgoing webhook, which echoes incoming parameters, only activates if if the event is triggered as above. Hence the same requirement to bust the cache is required. 7. Following is the result of making a GET request to the incoming webhook to trigger the 'Sample A' add event to add 1 and 2 with URI path /admin/plugin/webhooks/trigger/index/SampleaAdd?a=1&b=2 8. The result shown from above to add 1+2 is {"__return__":{"a":1,"b":2,"c":"a (1) + b (2) = c (3)"},"a":1,"b":2}. Again, it will only work once after each cache bust as above. 9. So, I did manage to simplify as noted above. All additions are to a single file and there is no use of a load function to include the Observer derived class. Ironically I have not so far being able to trigger incoming webhook events in the domain module or in core events.

There is a default cache refresh time of two hours set in config/blesta.php. Of course for development purposes with webhooks this is not practical, so the webhooks cache needs to be busted, as above during development.

A quick review of Webhooks source code reveals why the bugs exist. In fact it was a review of the Webhooks source code that prompted tests to confirm these bugs do exist, rather than behavioural observations. I was lucky I reviewed the code before starting tests. Just to be clear, 'Sample A' exists to prove bugs and does not include a triggerEvent function, but it can easily be added into a top level model file. Blesta likes to keep Observer derived classes in separate files and include these classes in parent triggerEvent functions through a load mechansim. The triggerEvent function is required for incoming Webhooks and I assume other functionality. Also the use of an Observer derived class, as above, is also required for Webhooks functionality and I also assume other functionality. It does not matter what file it is on as long it is in a plugin top level .php file. While Observer derived classes in separate files is fine for complex core functionaliy, I would personally like to see use use of a less complex mechanism, like including the Observer class in the same top level model file as the triggerEvent function for simpler use cases, while keeping an option to change.