Under no circumstances should you directly modify the theme or plug-in source code, unless it is just for temporary debugging, because the theme plug-in will restore the source files you changed every time it is updated, forcing you to manually restore the modified code again and again. And the cost of restoring it accidentally can be very high.
If you have a choice, you should avoid customizing the child theme through template override (Override). The same reason is that the more the theme or plug-in source code is updated, the gap between your overlay files and them will become wider and wider. You may unknowingly lose new features or fixes provided by new versions of source code because you want to keep custom code. Source code synchronization and customization requirements are incompatible, unless the webmaster is willing to re-apply customized code to the new template source file after each update. If you do this, congratulations, a huge maintenance black hole has been created. This problem is extremely common among many WooCommerce-specific themes, so I have stopped using such themes (such as the well-known Flatsome ) in the past two years. At first glance, these themes appear to be very professional, but due to the pursuit of functions in one step (Out The risk of inconsistency brought by the large number of WC native template coverage used by of the Box is not worth it from the perspective of the architecture and the stability requirements of high-end sites.
If developers are disciplined enough, using child themes in modern WordPress development is almost pointless. It is not necessarily a good idea to develop custom plug-ins right from the start, at least until the requirements are fully iterated and mature. Developing plug-ins lacks the deployment flexibility for rapid iteration.
The PHP customization required for the backend should be achieved with the support of Code Snippets or similar plug-ins, and completely relies on the actions and filters provided by WordPress/themes/plug-ins. The required customization of the front end should be achieved with the support of CJT or similar plug-ins, using code that is as less intrusive as possible (for example, the customization of the settlement page should be done based on the two JS events of update_checked and updated_checkout provided by WC).
Some side effects of PHP customization are very hidden, and the more general the interface, the more so. Therefore, background customization must strive to choose an interface as accurate as possible. Many official documents are unclear or ambiguous. Developers and webmasters probably have no other good solution except full testing. This is the price of using open source software.
But the actual situation is obviously not so perfect. Not every PHP customization can find the corresponding action or filter, and not every front-end customization has available JS events or function interfaces. This is the challenge of complex WP customization development. At this time, instead of diving headlong into looking for a “clever Hack”, it is better to send an email to the theme or plug-in author, tell them your customization goals, and see if they can provide a solution (sometimes they will directly Send you code snippets), if the other party confirms that there is indeed no ready-made code available, then you can submit a feature request to ask them to add a customized interface in the next version. My personal experience is that more than half of developers will at least seriously consider it, and 30% of developers are willing to immediately accept the free idea you provide and quickly complete the integration.
There are naturally a lot of lazy developers. After you feel that the other party lacks sincerity in communicating with you, you might as well try consulting a third-party professional developer. Allow me to recommend myself here.
Sometimes, it is much easier to customize the whole page than to customize multiple parts of the page, so if you can’t find a way to customize it locally, it is better to switch your thinking and see if it is more feasible to change the abstraction level.
When the customization goal cannot be achieved after exhausting technical and non-technical means (this situation accounts for about 5% of the cases I have encountered), we should communicate with customers in a timely and rational manner, explaining the fact that effective customization cannot be achieved and the consequences of forced customization. The systemic cost (of using consistency-breaking methods) is a sacrifice of stability and a significant increase in maintenance costs.
Many times there are multiple means to achieve the same goal, and even the goal itself can be modified. Finding another way will only lead to a hidden future. It is a completely normal choice to give up some customization, and some technical processing is not worth doing, even if the customer puts forward his own needs. , and it may not be the result of careful consideration. In fact, most of the time it is not.
Customization is a huge possibility that the WordPress ecosystem gives us. It is first and foremost a good thing. It requires a little discipline when operating it. Like other development, there is a matter of taste.
Leave a Reply