By default, nginx will log visitor IP addresses in its access log. This is mostly useful for debugging purposes when you have some problem with your server. Also it’s often useful for mitigating bot attacks, hacking attempts, or other security-related issues.

Cloudflare is another DNS-level tool that can be used to speed up your website performance, increase security of your website, and many others. This time we will focus on cloudflare’s basic function called Cloudflare proxy. 

In the picture above you can see whether the DNS record is proxied through cloudflare. When you enable proxy, all visitor requests won’t directly hit your webserver and the actual server IP will be hidden. In contrast to traditional DNS (or, in Cloudflare they call it “DNS only”), we can usually know what is the actual server IP which serves a specific domain. This cloudflare proxy is good for both security and speed. Good for security because the actual server IP will remain hidden for the whole world, and good for speed because Cloudflare will acts as a “proxy” that will serve HTTP requests from cloudflare cache (if any). 

However, this proxy thing can sometimes cause a problem. One of them is this that we’re discussing in this article. If we enable proxy, then it’s gonna be the cloudflare proxy servers that will actually hit our server, not the real customer. That way, nginx will record cloudflare’s IP addresses instead of the visitor’s. To address this problem, we can apply some simple nginx configuration so that it will record the real customer IP. We assume that you already have a website running on nginx webserver and you have registered your domain on cloudflare.

Prerequisites:

1. Nginx with http_realip_module module (should come by default in standard nginx installation)

Steps:

1. Edit your site’s nginx config:
   vim /etc/nginx/sites-enabled/your-nginx-config-here
2. Add the following lines. This list of IPs might change. Please check here for an up-to-date list.

set_real_ip_from 103.21.244.0/22;

set_real_ip_from 103.22.200.0/22;

set_real_ip_from 103.31.4.0/22;

set_real_ip_from 104.16.0.0/13;

set_real_ip_from 104.24.0.0/14;

set_real_ip_from 108.162.192.0/18;

set_real_ip_from 131.0.72.0/22;

set_real_ip_from 141.101.64.0/18;

set_real_ip_from 162.158.0.0/15;

set_real_ip_from 172.64.0.0/13;

set_real_ip_from 173.245.48.0/20;

set_real_ip_from 188.114.96.0/20;

set_real_ip_from 190.93.240.0/20;

set_real_ip_from 197.234.240.0/22;

set_real_ip_from 198.41.128.0/17;

set_real_ip_from 2400:cb00::/32;

set_real_ip_from 2606:4700::/32;

set_real_ip_from 2803:f800::/32;

set_real_ip_from 2405:b500::/32;

set_real_ip_from 2405:8100::/32;

set_real_ip_from 2c0f:f248::/32;

set_real_ip_from 2a06:98c0::/29;

#use any of the following two

real_ip_header CF-Connecting-IP;

#real_ip_header X-Forwarded-For;

1. Save & quit
2. Reload nginx
   sudo systemctl reload nginx.service

That’s it! Now you should be able to see the actual visitor IP under your nginx’s access log. Let us know if it works!

Usually when redeploying new code or introducing critical changes to the server environment. It is common to restrict access to end-users for avoiding errors caused by end-users using an invalid or incorrect environment state.

Magento allows developers to set maintenance mode, redirecting all users to the application 503 page. 

bin/magento maintenance:enable

Also, the developers have the advantage of whitelisting one or more IP addresses, allowing them to test any change in the server without being worried about any end-user accessing the server at the same the server is being updated. 

For example, the following command will enable maintenance mode for all end users except for 192.0.2.20 and 192.0.2.21:

$bin/magento maintenance:enable –ip=192.0.2.20 –ip=192.0.2.21

Enabled maintenance mode

Set exempt IP-addresses: 192.0.2.20, 192.0.2.21

The command above hopefully will be a helpful tool in order to reduce server downtime, the same for maintenance and development time.

If you just installed the newest PhpStorm version or just upgraded from a previous version you might notice that the Magento PhpStorm plugin is not working; not showing any plugin-related menu nor allowing you to autogenerate code, reducing your job efficiency.

You are also sure that you followed the correct steps for installing the plugin but it still not working, even worse, the PHP -> Frameworks section is also missing from the IDE.

What happened?  

It turns out that since PhpStorm 2021 1.1, the PHP frameworks section is independently listed at the top on File->Settings, and for some reason, this detail is also missing from the official PhpStorm documentation:

That section will look exactly the same as previous PhpStorm versions, just click on Enable Magento Integration and select the Magento installation path.

After clicking OK the IDE will reindex and the menus will start displaying all the cool features from the plugin, speeding up your code development.

Happy coding!

It is inevitable that your Magento version; hosted by your server or cloud environment; will be updated at some point, due to being pushed by software or hardware upgrades, and there might be some rare scenarios that after an upgrade you will get the following error after executing some regular operations on both frontend and backend:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry

Normally, when getting this error, the common solution is to check the database for the following:

• If you know which tables are involved in the executed process; check that the increment property is correctly set in the corresponding column.
• Check for any unique property set in a column that is not allowing to insert/update new data.

However, the above solutions require a deeper understanding of Magento’s database structure, and changing the database manually might be risky, it might lead to data loss if you are not careful.

Luckily, there are scenarios that might not require such dangerous troubleshooting. For example, if the error is caused when saving/updating a product with Tier Price you would need to search for the module processing the update and check if the store scope is explicitly set by using calling setCurrentStore(), similar to this:

$this->_storeManager->setCurrentStore(0);

$this->_productRepository->save($product);

And just make the following modification for using the deprecated getResource()->save() function instead of the recommended Product Repository:

$this->_storeManager->setCurrentStore(0);

$product->getResource()->save($product);

//$this->_productRepository->save($product);

By using the deprecated getResource()->save() function Magento will overcome this issue and save the product normally, but of course, it would reduce performance a little bit by not using the ProductRepository.

At the moment of writing this article, there is no official plugin that addresses this issue on the ProductRepository, but at least it will allow you to avoid direct changes in the database. 

Another situation that would trigger the Duplicate Entry error is when trying the save a CMS page, but fortunately, Magento already released the patch MDVA-33606 for version 2.4.1:

MDVA-33606: solves the issue where the users get Unique constraint violation found error when saving a CMS page assigned to hierarchy tree. 

Finally, for applying a patch you must follow the instructions for your specific Magento version. The present article will not cover the different methods for applying a patch. If your Magento version is lower than 2.4.1 you can still check out the official Magento patch information and implement a similar solution to your version.

Happy coding!

Upgrading Magento Cloud is very simple but it will require you to read a lot of documentation for understanding the correct action plan; so for this reason this article aims to facilitate information on the upgrading procedure in order to help you in making a decision whether your environment needs to upgraded or not.  

Step 1: DB backup: 

Be sure to create all the necessary backups in order to easily roll back the environment in case the upgrading somehow failed or some data is missing after the upgrade.

Step 2: Upgrade Magento Services: 

Update the services that interact between them in the environment. Before upgrade please check the correct services version configuration for your environment.

Step 3: Upgrade the PHP version: 

Update the PHP version installed in the environment through docker. Before upgrade please check the correct version according to the version of the services to be installed or that are already running in your environment.

Step 4: Upgrade the Magento version: 

Update the Magento version installed in the environment through docker. Before upgrade please check the correct version according to the version of the services to be installed or that are already running in your environment.

Step 5: Apply patches (If needed): 

Create all the necessary patches or just apply the patches provided by Magento (just in case it is necessary for your environment.

Please remember that this is a general guide for upgrading your Magento Cloud environment; however, there might be some specific situations that might require specific modifications; but this document might give you a good starting point.