If it’s not possible to remove an item from the cart in PrestaShop 1.6, try this solution:
Advanced settings -> Performance -> Move JavaScript to the end = NO
The problem seems to occur in Chrome and Microsoft Internet Explorer but not in other browsers like Firefox for example.
A client running PrestaShop 1.6.1.13 with PayPal payment module version 3.11.4 had problems after checkout of orders with an error message saying “699 kr was paid instead of 699 kr”. It turned out it was a rounding error where PrestaShop and PayPal use different methods of calculating the rounding.
The solution suggested was:
This solved part of the problem. However, the client applied a store wide discount of 30%, causing a product (for example) costing 999 kr to checkout at 699 kr. To be precise, 999 kr minus 30% discount is 699,30 kr, but the 0,30 was rounded off. The same problem as mentioned above occured even when putting one piece of this item in the cart and checking it out.
It turned out that the theme used (jms_homewares version 1.0) only display prices in full kronor, without any decimals, independent of the settings regarding decimals in the Preferences -> General tab. In this case the settings was set to display 2 decimals. Setting it to 0 decimals solved the problem. I should mention that I am not sure if this is standard behavoiur of jms_homewares or if it has been modfied by the website developer. However, in this case setting it to display 0 decimals made everyting work without errors.
After upgrade to Joomla 3.7.0 an error was displayed when saving an article in the frontend. The error message was “Warning. Empty solution not allowed”.
The error message is a bit confusing, not giving any real hint what it is about. It turns out it has to do with Captcha. A new feature in Joomla 3.7.0 is the possibility to use Captcha on article editing.
To solve the problem, go to Options -> Articles and select the Editing Layout tab. Make sure “None Selected” is set in the Captcha field and click Save. Do click Save if it is already selected because it seems the setting is missing after the upgrade. By saving, the setting will be added and the problem is solved.
Joomla 3.7.0 “Warning. Empty solution not allowed”
The Joomla! two-factor authentication is a great security improvement. But if you got locked out, maybe because your smartphone with the Google Authenticator installed broke down, was factory reset or the app was uninstalled – what to do?
Normally when moving, mirating or deploying a WordPress site, I use the Akeeba Backup plugin for WordPress. This works excellent, also for sites built using SiteOrigin Pagebuilder and SiteOrigin widgets bundle.
If, for some reason, it is not possible to use Akeeba Backup and a more traditional approach is used, like transferring the files using FTP, dumping the database to a SQL file, replacing the urls in the SQL file from the old url to the new, you will run into trouble if the old and new urls have different lengths (number of characters) because Pagebuilder uses something called serialization.
However, there is a solution:
Scenario: a SIP server running Elastix (Asterisk and FreePBX) with SIP-clients behind NAT. Outgoing calls from the clients (which where CounterPath Xten and Siemens Gigaset C530ip, i.e. completely different brands) works well, but incoming calls are disconnected after 8-10 seconds.
Googleing the problem suggests the problem is caused by a SIP REINVITE on the client side, which can’t happen because of NAT. During testing, I discovered that calls between SIP-phones connected to the same SIP PBX worked fine, even between different locations. Only calls that originated externally would be interrupted.
This made me focus on the trunks instead and I found out that the problem indeed was a REINVITE but it occured on the trunk side.
The solution was to add the following lines to the PEER DETAILS and USER DETAILS on the trunk configuration in the SIP server:
directmedia=no
canreinvite=no
To make the footer widgets visible when using the Cherry Framework 4 template for WordPress:
When trying to change a client website on a Ispconfig3 host from Fast-CGI to PHP-FPM the page just gave Error 500 Internal server error. Investigating the site error log showed lines like:
[Sat Oct 22 10:39:56 2016] [error] [client xx.xx.xx.xx] (2)No such file or directory: FastCGI: failed to connect to server "/var/www/clients/client6/web447/cgi-bin/php5-fcgi-*-80-domain.xx": connect() failed [Sat Oct 22 10:39:56 2016] [error] [client xx.xx.xx.xx] FastCGI: incomplete headers (0 bytes) received from server "/var/www/clients/client6/web447/cgi-bin/php5-fcgi-*-80-domain.xx"
Checking the status of PHP-FPM by the command:
service php5-fpm status
gave the result “not running”.
Investigating the PHP-log file, /var/log/php5-fpm.log, displayed lines like:
[22-Oct-2016 10:34:53] ERROR: [pool web405] cannot get uid for user 'web405' [22-Oct-2016 10:34:53] ERROR: FPM initialization failed
However, the site widh id 405 and user web405 did no longer exist on the server and has been left there by Ispconfig3 for unknown reasons.
The solution was to manually remove the file /etc/php5/fpm/pool.d/web405.conf file and then:
service php5-fpm restart service apache2 restart
After upgrading to Joomla 3.6.3 I got this error message when trying to login to administrator:
Error decoding JSON data: object property name separator ':' expected the bad data is: {""}
Solution was found here using the method suggested by Brent Laminack.
You need to issue the following SQL command using for example phpmyadmin:
update TABLEPREFIX_modules set params = '' where params like '%{""}%';
Note that you must replace TABLEPREFIX above with the prefix your Joomla installation is using.
If the Magento 2.1 setup readiness check fails with an error message displaying nothing for the PHP version, similar to this:
PHP Version Check
Your PHP version is . The required PHP version is . Hide detail
You might also see error messages about open basedir restrictions, similar to this:
Cannot determine required PHP extensions: Warning: is_dir(): open_basedir restriction in effect. File(/etc/pki/tls/certs) is not within the allowed path(s):
The reason can be that Magento is by default expecting SSL/TLS. If not used, the above can occur.
Solution:
Edit the composer.json file and add a line to the config section so it looks like this:
"config": {
"use-include-path": true,
"disable-tls": true
},
I.e. add the line “disable-tls”: true (and don’t forget to add a “,” last on the preceding line). Now restart the setup.