Hot answers tagged

6

I had a similar issue and it turned out I'd missed a form key in the Magento_CustomerCustomAttributes module override : Magento_CustomerCustomAttributes/templates/customer/form/register.phtml I'd check over each of the registration template files and make sure you haven't missed anything as this is very symptomatic of the 2.1.9 upgrade with regards to form ...


4

I found fix for development environment, because I use Mac OS and the apache php doesn't support these fonts and it's a lot of work to get it working and not mess up my system. open vendor/zendframework/zend-captcha/src/Image.php and add return in the constructor after the parent is called like this /** * Constructor * * @param array|\Traversable $...


3

you need to change the php configure script to include --with-freetype-dir=/usr/lib64/ where /usr/lib64 contains the libfreetype.so file. My final configuration so far looks like: ./configure --with-apxs2=/usr/bin/apxs --enable-bcmath --with-curl --with-gd \ --with-jpeg-dir=/usr/lib64/ --with-png-dir=/usr/lib64/ --with-freetype-dir=/usr/lib64/ \ --enable-...


3

Varnish 4 does not support -p esi_syntax=, instead you have to use -p feature= -p feature=+esi_disable_xml_check,+esi_ignore_other_elements esi_disable_xml_check, "Don't check of body looks like XML", "Allow ESI processing on any kind of object" esi_ignore_other_elements, "Ignore non-esi XML-elements","Allows syntax errors in the XML" ESI processing not ...


3

Its clearly a cron task, likely that of whatever server control panel you are using. du is a Linux utility for calculating disk usage of a given directory/file/path. You could try a quick grep through the cron tasks, but if you are using something like cPanel/Plesk - its unlikely the command itself is likely to embedded within the cronjob itself. grep -r "...


3

The system doesn't know what language the file is, so it's having trouble executing it. First you need to find where your PHP executable is. To do this use the which command: # which php /usr/bin/php In my case the executable is located at /usr/bin/php so my crontab would look like 15 * * * * /usr/bin/php /var/www/public_html/cron.php However, it's ...


2

You are right, the code lacks a semicolon to be valid PHP (however, the closing tag ?> is not necessary at the end of a file Search for AddHandler and SetHandler in all configuration files (for example using grep -r Handler /etc/apache2) and also in your .htaccess files, you might have missed it phtml files should not be executable on their own anyway, so ...


2

/var/di is only used in production mode. If it exists it needs to be deleted before you can run bin/magento setup:di:compile. I am assuming your local site is in developer mode and hence does not have this folder.


2

The issue is just because you may forget to add a slash ( ‘/’) at the end of base url in system configuration settings. /IP ADDRESS/Website/ Please try adding the same and test it again.


2

dont use file based caching. this causes many i/o requests which could slow down your application.


2

you can follow below steps go to app/etc/env.php file Set MAGE_MODE' => 'production' Run below commands bin/magento setup:static-content:deploy bin/magento setup:di:compile


1

I resolved the issue by removing the PHP via yum remove php and re-install PHP by following the link here: http://devdocs.magento.com/guides/v2.2/install-gde/prereq/php-centos.html I used the commands for PHP 7 on CentOS. Had to downgrade php from 7.1.4 to 7.0.26. This is also fine as this version is compatible with Magento 2.2


1

you see this config part: upstream fastcgi_backend { server unix:/run/php-fpm/php-fpm.sock; } this is where your php-fpm is listening. please check your php-fpm config, it must be the same socket path, with correct user read permissions. or change it to ip:port - 127.0.0.1:9000


1

You can solve it with the help of following command sudo yum install php72w-bcmath --disablerepo=epel\*


1

To update the URL to point to the subfolder, you can either modify the base URLs in the database as I assume you can't access the backend. You want to update in the core_config_data table both web/unsecure/base_url and web/secure/base_url to point to the base of the magento site. Then reindex and clear the site cache With setting permissions, Magento has ...


1

Please try: php bin/magento setup:install --base-url="http://example.com/shop/" --db-host="127.0.0.1" --db-name="th_magento" --db-user="th_magento" --db-password="asdfashd238" --admin-firstname="Hugh" --admin-lastname="Mongous" --admin-email="humongous@example.com" --admin-user="admin" --admin-password="...


1

Thank you all for the replies and the help! But it turned out to be a pretty simple fix that I just didn't realize. I was installing to the base url example.com/magento2/ but there was no magento2 folder. So it was 404'ing. I then just uninstalled and did the base url as example.com and now it works!


1

Check the requirements: http://docs.magento.com/m1/ce/user_guide/magento/system-requirements.html simplexml and DOM are required modules for Magento. http://php.net/manual/en/class.domdocument.php


1

In your php.ini settings, add/amend the below configuration. That should show you an error that points you in the right direction next time you try to load the page: error_reporting(E_ALL); ini_set('display_errors', 'On');


1

You have to delete the directory, not only the files inside var/di. Took me a while to figure that out :-)


1

Try letting the folder have read and write permission (i.e.: changing the permission to 777) to var directory, this worked for me for Magento 2.1. Ensure you are using recursive option. chmod -Rf 777 <magento install directory>/var/


1

grep -rnw '/path/to/somewhere/' -e "pattern" -r or -R is recursive -n is line number, and -w stands match the whole word. -l (lower-case L) can be added to just give the file name of matching files. In your case grep -rnw '/' -e "qunar"


1

The guides mean /path/to/your/store/var/cache/ eg. /var/www/vhosts/mywebsite.co.uk/httpdocs/var/cache/ NOT /var/cache on a Linux machine. Note the starting forward slash relates to the root of the file-system.


1

If you are running Magento 1.8+ I highly recommend you enabled REDIS cache (See KB article here) Here is some great information on speeding up Magento, implement the features that apply: http://www.magentocommerce.com/boards/viewthread/36225/ Finally look into optimizing your database using mysqltuner.pl and tuning-primer.sh Google these and run against ...


Only top voted, non community-wiki answers of a minimum length are eligible