Scope module assets ( v2 )

[pyronaur]

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.js is 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_Module class. 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_view which simply always returns true, with a //@todo attached to it :) - the whole asset enqueuing process needed a refactor.

Introducing EF_Module_With_View
The 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_Module class because all of the modules already are extending it. But EF_Module is also instantiated directly and it’s also extended by a EF_Dashboard class 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_Module and is meant to be extended further by modules that have views, that way they have access to necessary methods, like is_current_module_settings_view() and is_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_Interface and EF_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

• Force predictable and consistent enqueuing methods with PHP Interfaces across EF Modules
• Add a an reusable and easy to use class EF_Module_With_View that provides methods to easily determine whether or not assets are needed
• Refactor most modules to extend EF_Module_With_View instead of EF_Module and enqueue assets when they’re needed

Fixes #351

[pyronaur]

Looks like tests need fixing, working on it...

[pyronaur]

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 get_custom_statuses - it doesn't make sense for the methods to not work just because it's not the relevant view.

Todo:
[ ] Move is_custom_status_view out of register_custom_statuses method
[ ] Check up on the rest of is_custom_status_view and make sure they make sense
[ ] Make sure all other is_ methods (like is_calendar_view) make sense and their usage isn't broken like is_custom_status_view()

[WPprodigy]

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.