John Heenan

To make myself clearer, does this mean there are currently no modules or plugins we can trigger a named event through an internal webhook URL? This is apart from whatever extra data may or may not be required or supplied. Also, does security of internal webhooks rely on an obscure URL path with SSL, or do we need to build in security? Can a header be set to confirm if an admin is making the request? Also is there a way to determine if an outgoing webhook is not fake, apart from such methods as checking normal web headers that are dispatched with every request?

@Paul, I got the outgoing webhook to work after I removed .cgi at end (and copied script to name without .cgi). But after I put back .cgi again it continued to work. I am not convinced the iniital URL was wrong. With regard to your statement on incoming webhooks, does this mean there are currently no modules or plugins that listen to any of the events we can set? 1. Can you please give us a very simple example of a module that will listen to some event and will trigger another event harmlessly, such as below. 2. Can you add in extra events, like the following, so we can test without risk of destructive action. Desired extra events: Test1.beforeTest, Test1.createTest, Test1.deleteTest, Test1.afterTest, Test2.beforeTest, Test2.createTest, Test2.deleteTest, Test2.afterTest

I have just changed the event to Packages.editAfter for both incoming and outgoing webhooks. Still same lack of any effects.

Blesta version: 5.10 beta 1 PHP: 8.2.7 OS: Debian 12.5 (stable, bookworm) My outgoing webhook: My incoming webhook: Send the follwing direct to outgoing webhook without Blesta: curl https://somedomain.com/cgi-bin/dumpalltoemail.cgi -H "Content-Type: application/json" -d {\"testvar\":\"whatever\"} No problem. I get an email back echoing the json I sent. Send the same to blesta server, which I would expect to forward on as above: curl https://someblestaserver.com/plugin/webhooks/trigger/index/testname -H "Content-Type: application/json" -d {\"testvar\":\"whatever\"} Nothing echoed back. Make some changes to any package. Outgoing webhook is not called.

@Paul My solution, commenting out line 268 in file of btcpay_server/btcpay_server.php. also fixes problem of @Kurogane

@Paul I would like to add two feature requests. One minor and one large. I cannot put images into the requests topic so I will copy text from here and reference here. Also, the minor proposal gives context to the major proposal and the major proposal involves use of the BTCPay API, as mentioned here. So, maybe it is appropriate to link to here to start off and provide context. Minor proposals for enhancement of the Virtualmin module Proposal at https://requests.blesta.com/topic/minor-enhancments-of-the-virtualmin-module 1) Add in an extra text box below the 'Configurable Options' of an order form similar to Domain option below (which is not an option, it is a requirment). Call the option 'Site Header Text'. If you take this value and pass it to Virtualmin in the remote API version of the call to 'virtualmin create-domain' as parameter --content then this text will appear in the header text of the created default web site. The reference for the API is at https://www.virtualmin.com/docs/development/remote-api/#the-remote-api and the reference for individual commands of the API is the same as for those of the CLI. This means call is https://www.virtualmin.com/docs/development/api-programs/create-domain/ is the reference for create-domain API call. The reference does not explain what is done with the --content parameter and the reference to a filename does not appear to make any sense in [--content text|filename] with regard to code paths I followed in Virtualmin source code. Well, I have told you now what it does. The text of --content goes at the top of newly created web sites in big bold letters. 2) Also please pass in a --desc parameter with create-domain with automtically constructed text, such as "Created through Blesta, order ID: xxxx". This will appear in an admin screen in Virtualmin for the account holder and the text can be edited by the account holder. 3) The API refenece page above has the following text: "The output from remote.cgi is plain text, including the command-line program’s output and an exit status line indicating success or failure". Please make sure Blesta uses it. For example, during tests Blesta got told to create two different accounts with the same domain name. Virtualmin freaked and refused. Blesta thought everything was great and failed to provide any notification of failure. It might be wortwhile to check beforehand if the domain already exists. Major proposal for enhancment of use of BTCPay API Proposal at https://requests.blesta.com/topic/major-proposal-for-enhancment-of-use-of-btcpay-api-in-a-new-module The proposal is big but the text of the proposal is small. Pease add in an additonal module to allow creation of BTCPay stores that works in the same manner as the Virtualmin module. It would be great if the module could also be used to provide an addititonal service to order in other order forms, but this may be asking too much. The reference for users for what to do after user level store creaton is at https://docs.btcpayserver.org/CreateStore/. Please include a field for the store name. Suppose a user filled ''My New Store Created By Blesta". What an account holder will get when they login is in image below. They can go into Settings to alter the default currency. More information about what to do can be provided in links in the welcome email, as configured by the Blesta admin. The API reference to create a new store is at https://docs.btcpayserver.org/API/Greenfield/v1/#operation/Stores_CreateStore

A new batch from an upgraded backup with cron running in attached log file unique_log_entries.txt Also attached is latest version of script file filter_blesta_logs.sh. Extension .sh added so as not to cause alarm with downloads and file viewers. Slight difference in way shell called. Single paramer a is equivalent to parameters c s e w n (cron and server logs of error, warning and notice files). From blesta install directory: ./filter_blesta_logs.sh a > unique_log_entries.txt # don't forget the a parameter! When the next beta comes out I will repeat the procedure for two upgraded versions.

I think we should be getting more precise. For example, what exactly does default mean? There is no simple answer. Here is my attempt at providing a precise answer. Below is the default screen when a manual invoiceis created in BTCPay. 1. The Supported Transactions Currencies appears with three ticked boxes when Lightening is enabled and when LNURL is enabled 2. If Off-Chain and LNURL is selected then only the Off-chain will appear in invoice 3. If Combined URL/QR is chosen then only one QR box will appear. 4. The equivalent in the API is the "paymentMethods" array. 5. If the "paymentMethods" is not set in the API then this appears to be equivalent to choosing all available transaction curriencies, as BTCPay calls it. 6. The 'Default payment method on checkout' ABOVE provides a single choice way to override the setting BELOW in Settings, Checkout Appearance 7. The "defaultPaymentMethod" string in the API is, I guess as in invoice creation, really a way to say, no I don't really want the store default. 8. The upshot of all of this is that not setting either of the two API variables we (hopefuly) get a clear outcome: all available transaction curriences (unless LNURL clashes with Off-Chain) and no override of store default 9. Now what does 'store default' or its overide mean in practical terms? 10. If a combined URL/QR it means nothing. It can't, as there is no choice to make. 11. If not combined then it decided which of the two QRs is shown, with the chosen one having it's button in green. 12. A complicating factor is that if store settings indicate to show URLs as copyabe text, then they will both be shown below at the same time. So what happens if we do decide to pass a "paymentMethods" array and "defaultPaymentsMethod" string in the API call? Hopefully the answer is simple: that it corresponds to making alterations in a corresponding manner as with the manual invoice creation. With regard to issue with @Kurogane and alt coins, my guess is that not setting the two parameters mentioned in the API call will give him what he wants. Maybe he could let us know the results of commenting out line 268, as I did.

Altcoins FAQ for BTCPay at https://docs.btcpayserver.org/FAQ/Altcoin/ It looks like up to nine altcoins can be added. There are currently integrations for 14 altcoins.

I should also add that in the context of Blesta, sending a LNURLPAY makes little sense. It's main advantage is that payments can be made without generating an invoice beforehand, as LNURLPAY allows invoices to be generated on the fly.

I now have better information on how BTCPay behaves with settings and how the very popular Blink wallet behaves. There is bizarre behaviour can have a profound effect if Blesta invites admins to override settings. The BTCPay default payment method is set from Settings, Checkout Appearance, Invoice Settings BTC (LNURL-Pay) is only available if it is enabled from Lightning, Settings, Enable LNURL (image above). For Lightning, BTCPay will only every show an LNURLPAY or an Offchain fully encoded invoice, NOT BOTH ON THE SAME INVOICE. LNURLPAY has advantages over Offchain, but not when a regular invoice is being issued. In BTCPay, if a PARTICULAR invoice is specified to to show both LNURLPAY and Offchain encoding it will only show the Offchain encoding: the LNURLPAY setting is overriden. So checking all three below for a PARTICULAR invoice is pointless when generating an invoice as only Onchain and Offchain will show in the invoice, not the LNURLPAY. The effect is the same whether the unified on-chain and lightning URL/QR code is enabled or not (image above) The following is subtle with the Blink wallet. Blink will read LNURLPAY if not part of a unified QR code Blink will read Offchain if it is part of unified QR code with Onchain Blink will not read LNURLPAY if it is part of a unified QR code with Onchain. This means show a unified QR code with Onchain and LNURLPAY to Blink and Blink will choose the slow and expensive Onchain. So if a Blesta admin decides they will be smart, allows unified URL/QR, allows Offchain and LNURLPAY, but not Offchain which overrides LNURLPAY in BTCPay, and a customer pays with a Blink wallet, guess what, they are forced Onchain with a slow result and unnecessary expense.

Latest batch of unique log entries with latest version of filter script, now called filter_blesta_logs, now more generally useful and now requiring arguments The results in file unique_log_entries.txt got by placing script in Blesta install directory and running ./filter_blesta_logs c s e w n > unique_log_entries.txt No cron results (for reason mentioned above). Going to swap in another backup, upgrade it to Blesta 5.10.0 beta 1 and run cron to get cron entries.

Or the choice of what the customer sees, including the default choice or even no choice, could be left to the Blesta admin.

A refinement. Blesta could add to a customer form two choices, defaulting to first: Pay with BTC Onchain (this can delay order processing) Pay with BTC by server default (may or may not also include BTC Lightning) Or this could be left to the Blesta admin as a choice for all customers

A BTCPay method is set by API call if it includes an option to set it. I don't see how it has anything to directly do with a Blesta button. The buttons a customer sees on the final payment screen are BTCPay buttons, not Blesta buttons and what they are depends on what the API call instructed. To eliminate confusion, there is the Blesta invoice and the BTCPay invoice. The only way to make a payment with BTCPay is to 'create an invoice'. So there are two invoices involved. BTCPay really considers itself to be a store that includes a payment gateway. With Blesta we are short cutting the BTCPay store part and going straight to make a payment through generating a second invoice with an API call to BTCPay. Also the 'invoice' terminology is core with Lightning. Also the concept of an invoice expiring is central to Lightning. Which means if a customer does not pay before expiry then another invoice has to be generated with BTCPay. A regular BTCPay only recognises BTC crypto. Its payment methods are BTC Offchain and BTC Onchain. BTC Offchain recognises payment through a LNURL and through what I suppose is traditional Lightening, through a choice of both and also through a BIP21 unified Offchain/Onchain URL. Also all methods have QR codes. Why add to the confusion? Personally I think Blesta should stay out completely of changing BYCPay store default choices and make it very clear the payment method is chosen by the BTCPay store default. It only adds a second layer of confusion otherwise. I think Blesta should very prominently display advice to check defaults, to test well and also advise that Lightning is very convenient for customers (fast and tiny fees) but requires additional set up to using an onchain xpub address and that a hot onchain wallet should never be used with BTCPay. I think helping Blesta customers feel safe about using BTCPay is important. You could offer a choice to either force BTC Onchain use or to allow BTCPay store default. If you default to force BTC Onchain then this is backward compatible and you don't have to make any prominent announcements. You are requesting I provide opinions about what is best, something I cannot do.

I have tested with a new store with Lightning not enabled and the behaviour was fine with line 268 commented out. You ask as to best solution with my current config. No, if all wallets are BIP21 compliant. But they are not, including the world's most dominant Lightning wallet by far: Blink based wallets. Odd that https://bitcoinqr.dev/ refuses to even list Blink wallets in its compliance test conformity list. I deliberately took the unified BTC/Lightning URL and QR image option off during tests as I needed to see a clear visual distinction between BTC and Lightning during tests. Until I have made tests with different popular Lightning wallets, I will keep the distinction. Blink based wallets may not be happy with the unified BIP21 appoach, maybe for good reason. I will need to complete more tests to confirm some earlier results.

Here are current settings

For the record, this is what now appears in the Blesta log, as returned by BTCPay server, with the fix. s:14:"paymentMethods";a:3:{i:0;s:3:"BTC";i:1;s:12:"BTC-LNURLPAY";i:2;s:20:"BTC-LightningNetwork";}s:20:"defaultPaymentMethod";s:20:"BTC-LightningNetwork"; I did not see allowed payment methods with my own curl API resposne to the store for information. It likely reflects what my store currently allows as payment methods.

Yes, commenting out line 268 of btcpay_server/btcpay_server.php (->setPaymentMethods(['BTC'])) fixes the bug for me. The payment form for the invoice now shows both Bitcoin and Lightning payment options, consistent with the store defaults.

Found the bug. Line 268 of file btcpay_server/btcpay_server.php overrides any defaults with ->setPaymentMethods(['BTC']) Will see what happens if I comment out the line

From https://docs.btcpayserver.org/API/Greenfield/v1/#operation/Stores_GetStore there are four recognised default payment methods. When I do a curl with this API call to my store I get the answer 'BTC-LightningNetwork' in field defaultPaymentMethod. From Blesta logs for a create invoice call to my store, the following is in the returned data from the BTCPay serverr; s:14:"paymentMethods";a:1:{i:0;s:3:"BTC";}s:20:"defaultPaymentMethod";s:20:"BTC-LightningNetwork"; The documentation for this call is at https://docs.btcpayserver.org/API/Greenfield/v1/#operation/Invoices_CreateInvoice So it looks like Blesta specified to only use one possible payment method 'BTC' (equivalent to 'BTC-Onchain'), even though my store's default payment method is 'BTC-LightningNetwork'. My investigation continues.

AUD currency for both Blesta generated invoice and store manual generated invoice. Yes AUD is being converted to BTC/SATS properly with both invoices (uses Coingecko). Yes to second paragraph I don't understand the point about the button code. I am currently looking to determine what Blesta passes to BTCPay in the API call to compare with BTCPay API docs. Blesta logs the API call but not give the full call details. The response form BTCPays shows the payment method is BTC. Have to determine what the correct interpretation of this is. The store BTCPay default paymenth method (by my choice) is to allow both BTC onchain and BTC offchain (with Lightning) for invoices My main point is that an invoice generation can override the store default and this appears to be what Blesta is doing.

Blesta: 5.9.3 PHP: 8.2.7 OS: Debian 2.5 (stable, bookworm) When I manually create an invoice within BTCPay Server with my store's default payment method on checkout, the customer gets a choice between BTC and Lightning methods of payment: When Blesta creates an invoice within the same store, the customer only gets to pay by BTC: There is no option within Blesta to allow the BTCPay store to use its default method. I would expect that Blesta would either use the store default or offer a choice as to whether to override the store default or not

Wasn't doing anything. Numerous different H2o E_DEPRECATED messages have been logged below. Have not got round to making any changes yet. First the new version 0.1b of logs parse script now called grep_blesta_logs #!/bin/bash # grep_blesta_logs # Parse some blesta logs from blesta install direcory for unique messages # Version 0.1b, Author John Heenan, April 2024 # Reference: https://www.blesta.com/forums/index.php?/topic/25767-e_deprecated-messages/ cd logs_blesta || exit 1 year=$(date +%Y) function filter_log() { cut -d ' ' -f 1 --complement | awk -F, '!seen[$1]++' | sed 's/\home\S*\/blesta\///g' } if ls general-error-${year}-*.log >/dev/null 2>&1; then echo echo echo "**ERROR message, not E_DEPRECATED message**" cat general-error-${year}-*.log | filter_log fi if ls general-notice-${year}-*.log >/dev/null 2>&1; then echo echo echo "**E_DEPRECATED general notice, not including 'loses precison' message**" cat general-notice-${year}-*.log | grep -v 'loses precision' | filter_log loses_precision=$(cat general-notice-${year}-*.log | grep 'loses precision' | head -1 | filter_log) echo echo if [ "$loses_precision" ]; then echo "**A typical 'loses precision' E_DEPRECATION message**" echo "$loses_precision" else echo "**No 'loses precision' messages**" fi fi if ls general-notice-cron-*.log >/dev/null 2>&1; then echo echo echo "Unique cron messages" cat general-notice-cron-*.log | filter_log else echo echo echo "**Below is from the fresh install version, not the copy of production version into developer version for which cron should not be allowed to run**" echo "cat general-notice-cron-*.log | filter_log" echo 'general.NOTICE: E_DEPRECATED: Creation of dynamic property TicketManager::$SupportManagerDepartments is deprecated {"code":8192,"message":"Creation of dynamic property TicketManager::$SupportManagerDepartments is deprecated","file":"/vendors/minphp/bridge/src/Lib/Loader.php","line":256}' fi The output: ./grep_blesta_logs **ERROR message, not E_DEPRECATED message** general.ERROR: PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'package_pricing.default' in 'where clause' in /vendors/minphp/db/src/PdoConnection.php:196 Stack trace: #0 /vendors/minphp/db/src/PdoConnection.php(196): PDOStatement->execute() #1 /vendors/minphp/record/src/Record.php(793): Minphp\Db\PdoConnection->query() #2 /app/models/packages.php(1518): Minphp\Record\Record->fetch() #3 /app/models/packages.php(650): Packages->getPackagePricing() #4 /app/models/packages.php(577): Packages->appendPackageContent() #5 /app/models/services.php(831): Packages->get() #6 /app/models/services.php(191): Services->appendServiceInfo() #7 /plugins/domains/models/domains_domains.php(94): Services->getList() #8 /plugins/domains/controllers/admin_main.php(881): DomainsDomains->getList() #9 /vendors/minphp/bridge/src/Lib/Dispatcher.php(142): AdminMain->domains() #10 /index.php(21): Dispatcher::dispatch() #11 {main} **E_DEPRECATED general notice, not including 'loses precison' message** general.NOTICE: E_DEPRECATED: Creation of dynamic property NetGeoIp::$SettingsCollection is deprecated {"code":8192,"message":"Creation of dynamic property NetGeoIp::$SettingsCollection is deprecated","file":"/vendors/minphp/bridge/src/Lib/Loader.php","line":256} general.NOTICE: E_DEPRECATED: Creation of dynamic property SimplePie_Autoloader::$path is deprecated {"code":8192,"message":"Creation of dynamic property SimplePie_Autoloader::$path is deprecated","file":"/plugins/feed_reader/vendors/simplepie/autoloader.php","line":67} general.NOTICE: E_DEPRECATED: strpos(): Passing null to parameter #2 ($needle) of type string is deprecated {"code":8192,"message":"strpos(): Passing null to parameter #2 ($needle) of type string is deprecated","file":"/components/upload/upload.php","line":398} general.NOTICE: E_DEPRECATED: Creation of dynamic property NamesiloApi::$logger is deprecated {"code":8192,"message":"Creation of dynamic property NamesiloApi::$logger is deprecated","file":"/components/modules/namesilo/apis/namesilo_api.php","line":93} general.NOTICE: E_DEPRECATED: Creation of dynamic property H2o::$options is deprecated {"code":8192,"message":"Creation of dynamic property H2o::$options is deprecated","file":"/h2o/h2o.php","line":55} general.NOTICE: E_DEPRECATED: Creation of dynamic property H2o_Parser::$options is deprecated {"code":8192,"message":"Creation of dynamic property H2o_Parser::$options is deprecated","file":"/h2o/h2o/parser.php","line":56} general.NOTICE: E_DEPRECATED: Creation of dynamic property H2o_Lexer::$options is deprecated {"code":8192,"message":"Creation of dynamic property H2o_Lexer::$options is deprecated","file":"/h2o/h2o/parser.php","line":7} general.NOTICE: E_DEPRECATED: Creation of dynamic property H2o_Lexer::$pattern is deprecated {"code":8192,"message":"Creation of dynamic property H2o_Lexer::$pattern is deprecated","file":"/h2o/h2o/parser.php","line":13} general.NOTICE: E_DEPRECATED: Creation of dynamic property H2o_Parser::$lexer is deprecated {"code":8192,"message":"Creation of dynamic property H2o_Parser::$lexer is deprecated","file":"/h2o/h2o/parser.php","line":62} general.NOTICE: E_DEPRECATED: Creation of dynamic property H2o_Token::$type is deprecated {"code":8192,"message":"Creation of dynamic property H2o_Token::$type is deprecated","file":"/h2o/h2o/datatype.php","line":110} general.NOTICE: E_DEPRECATED: Creation of dynamic property H2o_Token::$content is deprecated {"code":8192,"message":"Creation of dynamic property H2o_Token::$content is deprecated","file":"/h2o/h2o/datatype.php","line":111} general.NOTICE: E_DEPRECATED: Creation of dynamic property H2o_Token::$result is deprecated {"code":8192,"message":"Creation of dynamic property H2o_Token::$result is deprecated","file":"/h2o/h2o/datatype.php","line":112} general.NOTICE: E_DEPRECATED: Creation of dynamic property H2o_Token::$position is deprecated {"code":8192,"message":"Creation of dynamic property H2o_Token::$position is deprecated","file":"/h2o/h2o/datatype.php","line":113} general.NOTICE: E_DEPRECATED: Creation of dynamic property H2o_Parser::$tokenstream is deprecated {"code":8192,"message":"Creation of dynamic property H2o_Parser::$tokenstream is deprecated","file":"/h2o/h2o/parser.php","line":63} general.NOTICE: E_DEPRECATED: Creation of dynamic property H2o_Parser::$searching is deprecated {"code":8192,"message":"Creation of dynamic property H2o_Parser::$searching is deprecated","file":"/h2o/h2o/parser.php","line":99} general.NOTICE: E_DEPRECATED: Creation of dynamic property H2o_Parser::$token is deprecated {"code":8192,"message":"Creation of dynamic property H2o_Parser::$token is deprecated","file":"/h2o/h2o/parser.php","line":92} general.NOTICE: E_DEPRECATED: Creation of dynamic property If_Tag::$args is deprecated {"code":8192,"message":"Creation of dynamic property If_Tag::$args is deprecated","file":"/h2o/h2o/tags.php","line":80} general.NOTICE: E_DEPRECATED: Creation of dynamic property H2o::$nodelist is deprecated {"code":8192,"message":"Creation of dynamic property H2o::$nodelist is deprecated","file":"/h2o/h2o.php","line":150} general.NOTICE: E_DEPRECATED: Creation of dynamic property H2o::$stream is deprecated {"code":8192,"message":"Creation of dynamic property H2o::$stream is deprecated","file":"/h2o/h2o.php","line":142} general.NOTICE: E_DEPRECATED: Creation of dynamic property SimplePie_Sanitize::$registry is deprecated {"code":8192,"message":"Creation of dynamic property SimplePie_Sanitize::$registry is deprecated","file":"/plugins/feed_reader/vendors/simplepie/library/SimplePie/Sanitize.php","line":100} general.NOTICE: E_DEPRECATED: Creation of dynamic property SimplePie_Locator::$dom is deprecated {"code":8192,"message":"Creation of dynamic property SimplePie_Locator::$dom is deprecated","file":"/plugins/feed_reader/vendors/simplepie/library/SimplePie/Locator.php","line":77} **A typical 'loses precision' E_DEPRECATION message** general.NOTICE: E_DEPRECATED: Implicit conversion from float 127.34694444444445 to int loses precision {"code":8192,"message":"Implicit conversion from float 127.34694444444445 to int loses precision","file":"/plugins/support_manager/support_manager_controller.php","line":64} **Below is from the fresh install version, not the copy of production version into developer version for which cron should not be allowed to run** cat general-notice-cron-*.log | cut -d ' ' -f 1 --complement | awk -F, '!seen[]++' | sed 's/\home.*\/blesta\///' general.NOTICE: E_DEPRECATED: Creation of dynamic property TicketManager::$SupportManagerDepartments is deprecated {"code":8192,"message":"Creation of dynamic property TicketManager::$SupportManagerDepartments is deprecated","file":"/vendors/minphp/bridge/src/Lib/Loader.php","line":256}

Here is a more robust version of the grep_logs script that I am now using, now called grep_blesta_logs. #!/bin/bash # grep_blesta_logs # Parse some blesta logs from blesta install direcory for unique messages # Version 0.1a, Author John Heenan, April 2024 # Reference: https://www.blesta.com/forums/index.php?/topic/25767-e_deprecated-messages/ year=$(date +%Y) cd logs_blesta || exit 1 if ls general-error-${year}-*.log >/dev/null 2>&1; then echo echo echo "**ERROR message, not E_DEPRECATED message**" cat general-error-${year}-*.log | cut -d ' ' -f 1 --complement | awk -F, '!seen[$1]++' | sed 's/\home\S*\/blesta\///g' fi if ls general-notice-${year}-*.log >/dev/null 2>&1; then echo echo echo "**E_DEPRECATED general notice, not including 'loses precison' message**" cat general-notice-${year}-*.log | grep -v 'loses precision' | cut -d ' ' -f 1 --complement | awk -F, '!seen[$1]++' | sed 's/\home.*\/blesta\///' loses_precision=$(cat general-notice-${year}-*.log | grep 'loses precision' | cut -d ' ' -f 1 --complement | head -1 | sed 's/\home.*\/blesta\///') echo echo if [ "$loses_precision" ]; then echo "**A typical 'loses precision' E_DEPRECATION message**" echo "$loses_precision" else echo "**No 'loses precision' messages**" fi fi if ls general-notice-cron-*.log >/dev/null 2>&1; then echo echo echo "Unique cron messages" cat general-notice-cron-*.log | cut -d ' ' -f 1 --complement | awk -F, '!seen[$1]++' | sed 's/\home.*\/blesta\///' else echo echo echo "**Below is from the fresh install version, not the copy of production version into developer version for which cron should not be allowed to run**" echo "cat general-notice-cron-*.log | cut -d ' ' -f 1 --complement | awk -F, '!seen[$1]++' | sed 's/\home.*\/blesta\///'" echo 'general.NOTICE: E_DEPRECATED: Creation of dynamic property TicketManager::$SupportManagerDepartments is deprecated {"code":8192,"message":"Creation of dynamic property TicketManager::$SupportManagerDepartments is deprecated","file":"/vendors/minphp/bridge/src/Lib/Loader.php","line":256}' fi