• Jay •

You guys are awesome at alienating people who used to be ardent supporters of the product and company. Kudos!

You might if you were limited to administrating the blogs section and a hook was malfunctioning, causing problems for your section and the site owner was away, leaving you without a way to disable it. Anywho, thanks for the discourse folks. :)

It's a good suggestion, tack away. :smile: Honestly, that was my initial thinking when I first posted the thread because I just saw a problem and wanted to suggest a fix. The talk about having to hunt down hooks made sense, so I modified my suggestion to address that issue.

Not true at all. Many hooks have configuration settings. Also, the administrator for an application should be able to disable hooks that start malfunctioning if the root admin isn't around.

What's with all the hostility, dude? Yeah, I'm asking you. You're the one that brought it up. Either quote where I said they didn't exist or stop being a confrontational ass. I asked out of curiosity. Now to address your questions: (MT33)Reputation Protected Applications 1.0.2 - Core Hooks, for add-ons such as you described above. (MT)Synch Me! 1.0.3 - Under the current setup, IP.Board Hooks, since that's where the settings are located. Although that does bring up another topic, such as where notification settings should be, since IP.Board will be an optional application starting w

To address this question, it's to allow an administrator for one application to have control over the hooks related to that application without giving them carte blanche over all hooks/add-ons. Why should a blog admin have access to gallery add-ons? Why should a gallery admin have access to IP.Content add-ons? and so on... By listing the hooks/apps in their respective sections, you could restrict permissions to those hooks/apps to the admins that are responsible for that area (and of course, to admins with no restrictions). I can understand wanting one big master list of ho

Alternatively, you can use this mod and not have to wonder whether somebody read it but didn't click the button.

Such as?

Or you could simply remove the bit and do warnings from the member profile page.

Under the old "everything is a bastard child of our board software" doctrine, that is true. However, if all of the applications are supposed to be able to be used independent of IP.Board in the next major rewrite, that should include the hooks & add-ons. That's not to say that a blog add-on should not interact with the board software (such as listing featured blogs on the board index), but recognize the simple fact that, although it does interact with IP.Board, it is a blog add-on because that's the application for which it was designed.

Themes means themes. There are blog sites just like there are forum sites. I'm not asking for a different back end for each application, so the settings would still be centralized - in the same admin cp. Just under their own respective headers within that admin cp for organizational purposes.

For member groups, that would be nice. Or on the same note, allow them to edit the member group, but prevent access to the Blog permissions (for board admins that we wouldn't want fiddling around in blog sections). But what about hooks and add-ons? The way they are now, they're all jumbled together in a disorganized mess that you have to scroll through to find the one you're looking for. If they were listed under their respective application's header, it would be much more efficient. Speaking of header, I hope this means that the other IPS applications will no longer be relegated t

Since the different IPS applications are going to be treated as separate entities, I hope that behavior carries through to the Admin CP. IP.Blogs, Gallery, and Nexus should have all settings, hooks, themes, permissions... everything related to that application under its respective heading instead of scattered throughout the IP.Board Admin CP. As it is, for example, we had to give a blog admin access to our hooks, and add-ons area, which includes board files unrelated to blogs, and members area for the ability to edit groups which can affect more than just blog permissions. Argument

Bah, IMG tags are borked.

Marcher Tech, if he's taking on projects. Ditto Michael, also a busy guy though.