Magento 2 extension broken after update? Support not answering your questions? We can fix it!
Main Causes of Broken Modules
The most common reasons for poorly written Extensions for Magento 2 are:
- avoiding code quality tools
- lack of database index (don't confuse with Magento 2 Indexers)
- suboptimal database queries
- poorly designed or lack of any caching techniques (such as shared block cache)
- abusing preferences over plugins
Code Quality
Did you know that code quality can be measured? There are tools available for PHP static analysis which check code for:
- readability
- complexity
- performance
- vulnerability
Many extension vendors do not adhere to the best programming practices. Even companies partnering with Adobe Commerce release modules for Magento 2 which are far from top quality.
PHP is easy to start building web applications - that's one of its greatest strengths. Amazing language for expressing business logic.
However, like any technology, it also has the other side of the coin.
PHP is easy to learn but hard to master which means there are no default constraints that would prevent inexperienced developers from making rookie mistakes.
Dynamic types and variables, magic methods, easy definition of complex abstractions.
These are features which make PHP flexible, but can lead to disaster when applied hastily.
Fortunately, automated linters and code quality tools come to the rescue. There are free packages that verify code performance and stability, for example:
- PHPStan
- PHP Mess Detector
- PHP Bench
- Rector
Furthermore, modern PHP features such as strong typing, named arguments, are techniques that strengthen the overall code assumptions.
Programming borrows many concepts from mathematics: boolean logic, algorithms and data structures to name a few.
Unlike natural languages, which are rich in nuance, ambiguity, and cultural context, programming languages are designed to be precise and clear. This clarity is essential because it enables the aforementioned tools to provide automated code quality feedback.
This is affordable and stable alternative to AI co-pilots based on LLM.
PHPStan slogan: Find bugs before they reach production.
Why plugins should be favored over Preferences?
Plugins and preferences alter native functions behavior. However, preferences override original class and its methods preventing leading to conflict with other extensions. Plugins can be chained and executed one after another by each Magento module.
In Magento 2 plugins are a form of Aspect Oriented Programming (AOP). Don't confuse them with extensions.
In other words, plugins system is a flexible mechanism of altering Magento 2 behavior. Such as USB cable works with compatible device and can be easily replaced. Preferences are like concrete or super glue. Only one can be configured at the time for given PHP interface or class.
Generally, preferences should be used for configuring internal module behavior or as the last resort when plugins can't be applied.
PHPStan Levels Overview
Every PHPStan rule level imposes stricter code checks which results in higher code quality. Here is a list of brief descriptions for each level from the PHPStan guide.
In simpler words, each level can be described as:
- Basic checks - Makes sure your code doesn't use anything that doesn't exist, like unknown classes or functions, and checks for mistakes in how many details you give to functions.
- Looks for places where your code might use something that hasn't been set up yet, especially in more complex situations.
- Does more thorough checks everywhere in your code, to make sure everything used is known and correct including 3rd party libraries.
- Makes sure the types of information being passed around in your code, like numbers or text, are what you expect.
- Finds parts of your code that aren't doing anything, like checks that will always be false or sections of code that can never be reached.
- Makes sure the information you give to functions and methods is the right type.
- Points out where you could be clearer about what type of information your code expects.
- Looks closely at complex situations where your code might only sometimes work and points those out.
- Checks that your code handles cases where it might not have all the information it needs.
- Is very strict with unclear data types, making sure your code is exact about arguments it is dealing with.
Magento 2 Modules Database Pitfalls: Indexing, Structure, and Normalization Challenges
Understanding the critical role of databases in application performance is critical.
Yet, it is often overshadowed by focusing on the frontend technologies such as SPA/PWA instead of targeting the inefficient data fetching at its core.
The misuse of databases rather than leveraging their full capabilities can significantly hinder performance and scalability - particularly in data-intensive environments such as ecommerce platforms.
The common pitfalls found in Magento 2 modules are:
- lack of indexes
- incorrect table data structures
- missing or incorrect database normalization
Lack of Indexes
Indexes are fundamental in enhancing database query performance by allowing rapid data retrieval.
Without proper indexing, every data request involves scanning the entire table, which can lead to substantial delays as the number of rows in table grows.
Implementing indexes on frequently queried columns, such as user IDs, product SKUs, or dates, can dramatically reduce search times and improve user experience.
However, it is crucial to strike a balance, as excessive indexing can slow down write operations and consume additional storage resources.
Measuring column cardinality is a good start to determine whether the column has potential benefits from index.
Cardinality refers to the uniqueness of data values contained in a particular column. High cardinality means that the column has a large proportion of unique values, while low cardinality means that the values are very repetitive.
In other words, if values are repetitive, this means we can be grouped within index and are found faster. In the same way you can browse books grouped by genre in the library.
Incorrect Table Data Structure
An optimal data structure considers factors such as the nature of the data, the types of queries performed, and the expected load on the system.
A common mistake is designing a data structure that does not align with these requirements, leading to inefficient data retrieval and updates.
For instance, a flat structure may be inadequate for hierarchical data, while a highly normalized structure could complicate queries that span multiple tables.
Understanding the application's access patterns and designing a data structure that accommodates these patterns is essential for achieving high performance.
Insufficient Database Normalization
Database normalization is a process that organizes data to reduce redundancy and improve data integrity.
The level of normalization requires careful consideration. While higher normalization levels (beyond 3NF, for example) can minimize data duplication and ensure consistency, they can also lead to complex queries that degrade performance.
Magento itself breaks normalization consciously for the sales' tables such as ordered items. Products might be removed in the future, while ordered items should remain in the admin panel and customer's My Account page.
On the other hand, insufficient normalization can result in data anomalies and redundancy, leading to increased storage requirements and potential inconsistencies.
The key is to find a balance that maintains data integrity without overly complicating data access.
What You Should Prepare
To ensure a swift and efficient resolution for your Magento 2 extension issues, please consider having the following items ready upon reaching out:
- Extension package (.zip) or link to the public repository
- Describe the issues you have with the module
- Magento 2 logs with errors caused by module (if available)
- Expected resolution timeline