Michael

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.

I can understand your frustration, but what you deem as high priority may not be what most people feel. In order to accurately track what you're looking for, every single topic view would need logged. For many sites, that's an unrealistic expectation considering the number of not only registered members pinging the topics repeatedly, but guests and search engines. Would something like Google Analytics or a similar tool be able to capture this data?

Deleting all posts is a fairly resource intensive action, particularly if the member has made a lot of posts. For each post you delete, you may need to rebuild the topic it was in (in case that post was the first or last post in the topic), and then you need to rebuild all forum data for all forums they posted in (so that the number of topics and posts in each is accurate), and then you need to rebuild the forum stats (so the total number of posts is accurate). When you delete all members' posts from the ACP, it does it in cycles of 50 posts, and redirects to a new page automatically where it does the next 50. You'd have to program something into the warn panel to be able to replicate this, as deleting all posts from someone who made 5,000 posts on the forums could not be done all in one shot.

I would say that for the frequency of how often most folks need to do this, and this is just going off my experience here, it's enough that an Admin can do this option in the ACP as it comes up. Whenever I have needed to delete all posts from one member, I wasn't doing it when I was just warning them, I was doing it when I was banning them via the ACP, where I would have the ability to delete all of their posts right there anyway. Just my 2 cents.

Deleting all posts is a fairly resource intensive action, particularly if the member has made a lot of posts. For each post you delete, you may need to rebuild the topic it was in (in case that post was the first or last post in the topic), and then you need to rebuild all forum data for all forums they posted in (so that the number of topics and posts in each is accurate), and then you need to rebuild the forum stats (so the total number of posts is accurate). When you delete all members' posts from the ACP, it does it in cycles of 50 posts, and redirects to a new page automatically where it does the next 50. You'd have to program something into the warn panel to be able to replicate this, as deleting all posts from someone who made 5,000 posts on the forums could not be done all in one shot.

I would say that for the frequency of how often most folks need to do this, and this is just going off my experience here, it's enough that an Admin can do this option in the ACP as it comes up. Whenever I have needed to delete all posts from one member, I wasn't doing it when I was just warning them, I was doing it when I was banning them via the ACP, where I would have the ability to delete all of their posts right there anyway. Just my 2 cents.

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).

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.

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.

Just set IN_DEV at the top of the admin/index.php that is what I did.

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.

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.

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.

No, there is no downgrade option. And the 2.0 software has not been available for many years now. It's extremely buggy, insecure, and outdated.

Or, to rate the true quality of your posts.

Bring back neg rep please

Ah, so it's yet another topic about you wanting to use javascript in code in the editor. :rolleyes:

Ah, so it's yet another topic about you wanting to use javascript in code in the editor. :rolleyes:

For the record, I still don't understand why the layout was changed. It worked perfectly well and looked more than organized as a table.

Can you not manage this through you app's coreVariables.php?

At least, that's how I understood it based on the article. http://resources.invisionpower.com/index.php?appcomponent=cms&module=articles&article=7508

All this weekend, I have almost literally been tearing my hair out trying to debug a problem with an app I've been developing for IPB3. A debug statement in the top of index.php to var_dump($_GET) said that it was empty, but it turns out that it wasn't. That's an Apache/PHP bug/problem I think. It turns out that the root cause of my problem was that I hadn't got my code and folder structure quite correct, so that IPB couldn't find my application's executable code. Because of this, it was defaulting to the root URL for the board.

It would have been nice [and I would have slightly more hair] if IPB3 had given a warning message stating that although the application was registered in AdminCP, it couldn't work out which code to execute. Perhaps this type of warning could be given only if IN_DEV mode is switched on?

How come search results don't show the topic's author anymore? In some searches, that's even more important than the topic title.

I like the rollovers, but would *love* them if they could preload the background image for the rollover. The split second white bg trips me up a bit lol.

There is one already, but it is available to customers only:

http://forums.invisionpower.com/forum/419-ip-board/