Scope module assets ( v2 ) #487
Conversation
Even though this method was never implemented - deprecate it, in case someone is relying on it
Rename `disable_custom_statuses_for_post_type` to `is_module_edit_view`
…ngs_view( $this->module->name )
… fix-351-scope-assets
Instead of a plain `is_active_view()`
… fix-351-scope-assets
… fix-351-scope-assets
…w into scope-module-assets # Conflicts: # modules/calendar/calendar.php # modules/custom-status/custom-status.php # modules/editorial-comments/editorial-comments.php
|
Looks like tests need fixing, working on it... |
This fixes the test errors that happened after migrating most of the methods away from EF_Module to EF_Module_With_View Changed the class used in tests from `EF_Module` to `EF_Module_With_view` The test only tests a module with a view, not a generic Edit_Flow module.
|
Looks like this will have to wait a little bit. The tests caught a bug! 🎉 🎉 🎉 https://github.com/Automattic/Edit-Flow/pull/487/files#diff-228291de10e40133681b1ff8414a9a54L220 The code above will prevent EF from registering the post status if it's not the "View" page. That shouldn't be done in a "module view" but everywhere. Same applies for methods like Todo: |
|
Closing this for now, doesn't seem likely to get the merge button. I like the approach of doing this on a module-by-module basis, can certainly re-use much of what is here though. |
Previous PR (#441) history was messed up, re-creating it here with a better history:
Overview
At the moment, almost all assets are loaded on every admin page (for example -
calendar.jsis loaded in "Settings -> General”). Overall there were a lot of inconsistencies in asset enqueuing. The goal of this PR is to provide a reliable and predictable way of enqueuing module assets.Background
Every Edit Flow module extends the
EF_Moduleclass. However, some modules have dedicated views and some modules (like Dashboard widgets module) don’t. That’s where the inconsistencies begin.Most EF Modules enqueue assets. Some check whether they should enqueue assets, some perform the same checks in a different way, and some don’t check at all. Most of the modules use method
EF_Module::is_whitelisted_functional_viewwhich simply always returns true, with a//@todoattached to it :) - the whole asset enqueuing process needed a refactor.Introducing
EF_Module_With_ViewThe EF modules needed a few methods to make it easy to check whether the any given module is visible at the moment (and therefore, whether they should enqueue assets). In most cases this is either in the edit, list and settings views.
At first I dumped all the necessary methods on
EF_Moduleclass because all of the modules already are extending it. ButEF_Moduleis also instantiated directly and it’s also extended by aEF_Dashboardclass that doesn’t utilize the any of the “new” methods, so it didn’t make sense to keep them there.EF_Module_With_View extends EF_Moduleand is meant to be extended further by modules that have views, that way they have access to necessary methods, likeis_current_module_settings_view()andis_active_view()Adding PHP interfaces
There was no streamlined way of dealing with assets. Even enqueuing method names varied from module to module. That’s why I decided to 2 simple interfaces:
EF_Script_InterfaceandEF_Style_Interface- they will ensure that asset enqueuing methods are consistent and predictable. Also, by reading the class declaration it’s immediately clear whether or not the current module is enqueuing any assets.Summary
EF_Module_With_Viewthat provides methods to easily determine whether or not assets are neededEF_Module_With_Viewinstead ofEF_Moduleand enqueue assets when they’re neededFixes #351