Development request (for hook files)

[Wolfie]

If this is already possible then just label me a clown for this request but here goes.

The request is rather simple. Add or at least allow for a value to be defined (similar to IN_DEV) that would change the behavior of renaming hook files (upon import) so that the original filename remains. ie, hook_file_stored = hook_file_real

Obviously, it would be for use on sites (or at least at times) when a developer wants to make sure that a hook imports and functions properly while also allowing for editing the files without having to rename the hook files back to their original names. When editing the hook version within the hooks details, the 'stored' name is updated to the 'real' name and so the developer has to go in and rename the files anyway. This would simply save a step.

What I'm thinking is something like 'DEV_SITE' or something else, where 'IN_DEV' would be independent and continue to do what it does, but 'DEV_SITE' would simply say that certain functions or features should be skipped or disabled. (ie, DEV_SITE wouldn't enable extra features in the template tools section) Only exception would be for exporting hooks and such but otherwise DEV_SITE wouldn't make any changes that the IN_DEV setting makes.

[Aiwa]

I see what you're saying, but there are other issues at play here...

Your IN_DEV is a /master_*.. It's not in the ACP... So the import process would also require the /master_* disk files be overwritten if there are any added templates, language, or CSS... Otherwise you won't see them while IN_DEV... I don't think it wise to automate that because you could potentially overwrite any custom changes you've made that hadn't been imported for 'release'...

[Wolfie]

Your IN_DEV is a /master_*.. It's not in the ACP... So the import process would also require the /master_* disk files be overwritten if there are any added templates, language, or CSS... Otherwise you won't see them while IN_DEV... I don't think it wise to automate that because you could potentially overwrite any custom changes you've made that hadn't been imported for 'release'...

I think we're talking apples and oranges here. When IN_DEV is on, you get extra stuff available, like being able to export a hook, seeing hidden settings groups, etc. The new value would be to enable a somewhat more 'permanent' development mode where it would be understood that certain features would be skipped over because the admin isn't using it for a live site. It wouldn't enable template tools or do anything else that IN_DEV enables (except exporting hooks perhaps). I know that the 'stored' names of hooks is to reduce the chances of two hook files having the same 'stored' name and so reduce possible issues. But if someone is on a dev site, they should already be aware of the risk by disabling that feature. The developer may want to disable IN_DEV and do some testing and if they need to modify a file and then update the version number and export it, then they shouldn't have to worry about renaming one or more files.

[Aiwa]

So, you want a new 'dumbed down' DEV mode? Something that is specific for hook development?

[Marcher Technologies]

he wants a flag that simply has imported hook files use the original file-name.... and realistically, i don't see the need for an extra flag, if IN_DEV is on, using the original filename on import should be non-issue, and is actually really annoying to have uninstalled/installed the hook for a confirmation test and have to rename the files to work on them again after hook edit.

Also, the whole 'avoid conflicts' as the goal of the rename is rather moot and pointless, as the classname is still the same, conflicts of that nature are on the developers hands for using a non-unique.

[Wolfie]

So, you want a new 'dumbed down' DEV mode? Something that is specific for hook development?

No more like the enabling of certain features, disabling of others, but would be treated independently of IN_DEV. With IN_DEV by itself, it doesn't make sense to do things like disable the renaming of hooks upon install because that might not be why someone has it enabled (could be for skinning or other reasons). Instead, have a separate value that says to skip things like renaming of files and anything else that may be a nuisance to a developer (but is meant to prevent issues on live sites). This way someone could have IN_DEV off to test something out but at the same time, won't have to go stumbling over their own feet to make sure they dotted their I's and crossed their T's, etc.

he wants a flag that simply has imported hook files use the original file-name.... and realistically, i don't see the need for an extra flag, if IN_DEV is on, using the original filename on import should be non-issue, and is actually really annoying to have uninstalled/installed the hook for a confirmation test and have to rename the files to work on them again after hook edit.

The bolded part is the reason for the request, but I'm sure there are other things that could be tweaked to act differently that would be more developer friendly but that you wouldn't want on a live site. My concern with attaching it to 'IN_DEV' is that someone might not be using developer mode for hooks but something different and might want the hook renaming to remain enabled.

[HeadStand]

+1 for this request. The hook renaming drives me CRAZY.

[Ryan H.]

It's even worse when the hook you're working with has more than a dozen files. A simple way of disabling the renaming bits would definitely be nice.

[Wolfie]

It's even worse when the hook you're working with has more than a dozen files. A simple way of disabling the renaming bits would definitely be nice.

Wouldn't be so bad if it wouldn't 'forget' the stored file names when updating the hook.

Can you think of anything else that is a useful feature or design meant to prevent issues but for development is counter productive? Could help make a 'DEV_SITE' constant more beneficial, especially if it allows testing and such without requiring 'IN_DEV' to be constantly toggled. Set it and 'forget it' and have certain things remain in developer mode (like exporting hooks) but otherwise be treated like IN_DEV is off.