zc_plugins vs redefining File Paths like DIR_WS_INCLUDES #5812
mc12345678
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Working on preparing an admin plugin for transition to the new zc_plugins architecture, but I have noticed something that could become a significant issue either for a store or those supporting plugins.
The use of almost any "predefined" filepath if that path/folder has been modified away from a ZC default install. For example, if DIR_WS_INCLUDES has been defined/redefined to use the folder 'keeps', and a plugin uses DIR_WS_INCLUDES, but the plugin is provided with the folder being located at 'includes', execution will not find the the associated file because the keeps folder likely does not exist in the plugins internal structure.
While this renaming of folder paths may be infrequent/specialized, it has had me wondering if I should hard code folder names instead of using or attempting to use the internally defined paths and provide some sort of additional clarification. See, while the "same issue" may occur in the main fileset, when copying the files and folder structure over to a "legacy" system, it is at least visible what folder(s) are in alignment. Under the zc_plugins structure, plugins have no comparative structure to readily compare.
Should there be a separate set of defines for use within the zc_plugins structure, possibly supporting an "if this / else that" type structure so that the plugin files would be self contained within the plugin rather than attempting to map against the store's file structure from within the
zc_plugins
directory?I'm not entirely sure myself of what might be a good solution without having more insight into the larger plan/consideration...
Beta Was this translation helpful? Give feedback.
All reactions