by Cristian Balan | Mar 19, 2023 | Magento
Multiple users have reported issues with Magento 2 (see GitHub magento2/issues/23618 or magento2/issues/23908) where customers are unable to proceed with their orders during checkout due to apparent problems with their shipping address.
In those cases, the customers will see a message stating Unable to save shipping information. Please check input data. OR The shipping information was unable to be saved. Verify the input data and try again.. E.g.:
Despite the screenshot above, the address might be correct and customer can’t do anything to unlock the situation hence leading to frustration.
Looking in the logs at var/log/exception.log, multiple related `Invalid customer address id` records can be noted. E.g.:
main.CRITICAL: Invalid customer address id 691 {"exception":"[object] (Magento\\Framework\\Exception\\NoSuchEntityException(code: 0): Invalid customer address id 691 at /vendor/magento/module-quote/Model/QuoteAddressValidator.php:77)"} []
Please note that the ID above is not che customer ID but the customer address ID that can be found in the `customer_address_entity` table. E.g.:
SELECT * FROM magentoDBname.customer_address_entity WHERE entity_id = 691;
This problem appears to be due to a bug occurring when particular conditions are met (see Stack Overflow). Sadly reading from those reports in GitHub and elsewhere, Adobe don’t appear to have figured out a resolution for this edge issue which seems to still affect the most recent versions.
Some code changes have been suggested by users to fix the problem while my preferred, albeit temporary, solution is that of updating the SQL code for those affected users (so we don’t change the Magento core code).
If curious, we can find the affected customers with:
SELECT entity_id, customer_id FROM quote WHERE customer_id != 0 AND customer_is_guest = 1;
And fix them with:
UPDATE quote SET customer_is_guest = 0 WHERE customer_id != 0 AND customer_is_guest = 1;
by Cristian Balan | Apr 29, 2021 | Magento
A brief write-up by Absolute Commerce on building and deploying Magento with a pipeline:
https://absolutecommerce.co.uk/blog/magento-2-pipeline-deploy-zero-downtime
Had this opened in my many tabs so thought will better save it this way for future reference. We might use some inputs for our pipelines.
by Cristian Balan | Dec 13, 2020 | Linux, Magento, Monitoring
I’ve used Papertrail before its acquisition from SolarWinds and was impressed by its simple interface and the logs scrapping capabilities. At the time, I have set Papertrail to monitor a few auth logs and trigger Slack notifications whenever SSH access occurred from a different IP than those whitelisted.
Well, years have passed since I’ve last played with it and now I have a new use case to monitor Magento errors recorded in its var/log/system.log and var/log/exception.log files. As I’ve forgotten how I did this at the time I thought I’ll put down my steps which might help later on.
First thing I’ve gone straight into reading the docs. That brought me into the app log files aggregate page.
The first step is to download the latest remote_syslog2 script from their GitHub repository. The only problem I have with this method is that you will struggle to keep things up-to-date without manually checking the repo for a new version and update. Hopefully one day we would be able to install via an OS package.
Ok, let’s download the latest current version and install. As I’m using Ubuntu I’ve done this:
wget https://github.com/papertrail/remote_syslog2/releases/download/v0.20/remote-syslog2_0.20_amd64.deb
sudo dpkg -i remote-syslog2_0.20_amd64.deb
The second indicated step is that of configuring and starting remote-syslog. The example only shows you how to do it with a single log so without too much fuss I’ve instead downloaded the custom config file and replaced the content of /etc/log_files.yml with:
files:
- /home/user/myMagentoWebsite.co.uk/public/var/log/system.log
- /home/user/myMagentoWebsite.co.uk/public/var/log/exception.log
destination:
host: logs7.papertrailapp.com
port: 77777
protocol: tls
exclude_patterns:
- main.INFO
pid_file: /var/run/remote_syslog.pid
Figured out that we can add multiple files just under the first example line. Also, the original /etc/log_files.yml had an exclude_patterns example which I’ve used to prevent main.INFO records from filling Papertrail as these are outside the scope.
The remote-syslog GitHub page has obviously more examples and explanations if we want to dig further into how it works.
Finally, the sudo remote_syslog command should get us set.
