Jump to content

Editing hook settigs requires IN_DEV


Michael

Recommended Posts

Posted

Currently, in order to edit a hook to change something like which template it hooks into, you have to turn on IN_DEV mode. This is bad because it puts the whole site into developers mode. We should be able to edit a hook's properties without having to enable IN_DEV.

Posted

The problem is, we wanted to keep the development of hooks outside of normal view of users. Hooks are already a complicated enough thing to present to a typical admin who knows nothing about how it all works....we didn't want to present any options that would confuse them further (and you know some people can't resist clicking a link even if they don't need to).

I'd prefer to keep any editing of hooks in developer mode myself. Not for the developer's sake, but for the end user's sake.

Posted

Maybe you should show the options to Root Admins only then? I just can't help thinking that the current setup is not ideal. On at least two occasions already here on this site, I've had to tell someone that they had to enable IN_DEV just to change the positioning of a hook. Whenever they would do that, all users on the board could either get huge ugly errors or get info revealed to them that they shouldn't have.

It would be one thing if a board admin could have a development board where they did have IN_DEV turned on so they could experiment with this, but even with that setup, once they figure out what needs changed there is still no way other than enabling IN_DEV on a production board to alter this (unless you want to edit serialized values directly in the database).

Posted

What about a new constant? "HOOK_EDIT_MODE", or something. As with any other constants, place that in initdata.php, and setting that to 1, would enable those edit sections. Which would allow any administrators to edit the hooks, without facing any security risks by putting the whole board IN_DEV.

Posted

[quote name='m4rtin' date='01 June 2009 - 03:26 PM' timestamp='1243866418' post='1806739']
What about a new constant? "HOOK_EDIT_MODE", or something. As with any other constants, place that in initdata.php, and setting that to 1, would enable those edit sections. Which would allow any administrators to edit the hooks, without facing any security risks by putting the whole board IN_DEV.

I was just about to suggest something similar too :)

Posted

If it's just positioning of the hooks, THAT should be editable without enabling developer mode if you ask me. That is, for positioning of a hook relative to a separate hook.

We can look into a separate constant if that would be really helpful. As I said though, the main goal is to keep this as simple as possible for the (majority) of admins that simply want to install a hook - they won't understand what all the stuff is for when editing it, and giving them the options isn't necessary. KISS rule and all.

Posted

Well, the best thing (in my opinion) is to show only the dropdowns to change if/foreach cycle and the other dropdown to selected the hook point of course when IN_DEV is not enabled.

When IN_DEV is enabled instead show everything as usual.

Posted

[quote name='teraßyte' date='01 June 2009 - 05:05 PM' timestamp='1243890353' post='1806873']
Well, the best thing (in my opinion) is to show only the dropdowns to change if/foreach cycle and the other dropdown to selected the hook point of course when IN_DEV is not enabled.

When IN_DEV is enabled instead show everything as usual.

Agreed. :)

  • 1 month later...
Posted

Can't promise anything for the 3.0.x point releases. We would want to do this as user-friendly as possible, which is a challenging task for this sort of thing. ;) We'll see.

Posted

For the shoutbox I need to release 5 different hooks just because the hook access point can't be edited, and is a pain to maintain 5 hooks (I might do a fix in an hook and forget to apply it also to the other one and such lol) :(

Posted

Oh, I understand and I'm not saying we don't want to do it. I'm just saying we'd need to do it *right* and it's hard to push something like that into a minor point release.

Posted

[quote name='teraßyte' date='13 July 2009 - 04:40 PM' timestamp='1247496006' post='1825468']
For the shoutbox I need to release 5 different hooks just because the hook access point can't be edited, and is a pain to maintain 5 hooks (I might do a fix in an hook and forget to apply it also to the other one and such lol) :(

Can't you make a new setting (probably separated from the core settings system) where you make a lit of pre-defined locations, and update the hook data upon save, and recache the templates?

Posted

This would require a lot more work as I would need to code a new area in ACP only to handle that, I just prefer to copy/paste the hook files and change the access point as it is much more faster :lol:

I'll definitely forget to update them sometimes but I'll live with this issue :P

Posted

[quote name='teraßyte' date='15 July 2009 - 11:40 AM' timestamp='1247650807' post='1826503']
This would require a lot more work as I would need to code a new area in ACP only to handle that, I just prefer to copy/paste the hook files and change the access point as it is much more faster :lol:

I'll definitely forget to update them sometimes but I'll live with this issue :P

It's not so difficult, really. I did something similar in an application. If I disabled the whole app, it also disabled the hook. You should be able to do the same, only you have to recache the templates when you're done.
And it also a bit friendlier for the user, than having to enable/disable hooks.

[quote name='bfarber' date='15 July 2009 - 04:34 PM' timestamp='1247668461' post='1826587']
I think it would be cool if a hook could be assigned to more than one access point as well (at least a template hook)

Didn't I suggest that in the early beta stages?


EDIT: No I didn't.
I reported/requested that several hooks could share the same source file.
http://forums.invisionpower.com/tracker/issue-13213-several-hook-points-cant-share-the-same-file/

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...