Magento Functional Testing Framework was presented by Tom Erskine during contribution day which followed MageTestFest, which took place in Amerfoort in November last year. Right now it’s under heavy development, there were already 2 releases and it reached version 2.0.3.
System configuration is a very useful feature of the Magento platform. At the same time, it’s easy to create new configurations for your own custom solutions. We’ve already touched the topic on how to add new system configurations with different fields. Today I would like to describe one more type of fields, which can be used depending on your needs. This is a dynamic field block. Sometimes we need to have some complex data managed via system configurations, or we even don’t know beforehand the number of records to be added. In this case it’s impossible to create the exact fieldset in a system configuration tab. Therefore, dynamic fields will be really useful.
2017 has truly been the year of Community Engineering for Magento. For many years we’ve been hearing voices from the Magento community on how great would it be if we were allowed to work on fixing bugs and improving Magento core code… And now we’re living this dream. Moreover, this dream already delivers: 24% of the code shipped by Magento in 2017 came from the community. And all this came from 511 unique contributors. Impressive, isn’t it? And what’s helped the success?
It’s well known that Magento team announces new platform upgrades quite often. There is a minor upgrade every second month and a more critical upgrade with new features and more changes to the core almost every quarter on average. If we look back, since the release of Magento 2.0 in November 2015 there were around 30 releases for Magento Open Source and Magento Commerce. Looks like a lot, doesn’t it? So the question arises: do these changes actually bring any value to the website?
After the latest Database data format changes in Magento 2.2.x version, there is a need to convert existing PHP serialized data to JSON format. The new release provides upgrade scripts that convert Magento serialized data. But how to deal with custom extensions, which also use automatic serialization mechanism provided by Magento framework? Thankfully, Magento took care of that too.
The new Magento 2.2 release replaces the usage of default PHP serialized format to JSON format. The release also upgrades scripts that convert Magento data that is stored in serialized format e.g. Magento\Sales\Setup\SerializedDataConverter, Magento\Sales\Setup\SalesOrderPaymentDataConverter, Magento\Framework\DB\DataConverter\SerializedToJson classes. These major changes may affect the correct functionality of already existing custom modules and related data that is stored in the database.
Any Magento 2 page requested from a browser is processed by a web server. Magento 2 loads 170 scripts per page on average. All incoming requests add an additional load for a server CPU and Memory. As a result, it increases infrastructure costs to maintain an acceptable level of page load time.
One of the things that Magento first version lacked was an ability to clean up module data from the database upon its removal. This is a common situation when you uninstall an extension but all the related data remains in the database. You can only get rid of it manually. It is inconvenient especially if the module has created a bunch of new tables, custom attributes, system configurations etc. In this case, an automatic removal tool of such data would be very useful.
In Magento 2 there is a great feature, which allows to create an uninstall script for your module. Let’s find out how it works.
Recently we have shared a tutorial on how to add custom Admin system messages in Magento 2. Today we will cover another type of notifications that uses Default Admin Notifier – Notifications.
Having a particular version of the software easily discoverable makes hacker’s job easier and allows automated scrapers to gather a database of URLs with particular software versions that can be used at an event of security vulnerability discovery for attacks. Of course, hiding the Magento version won’t be enough to secure your store, but it is just a simple step to take, just like changing your admin URL that makes store a little bit more secure.