Control Forumjump Depth Level

There are currently two settings which affect the display of forum levels, but none of them affects the forumjump box. This hack will add a third option to the Admin control panel, with the role of taking care of the forumjump box depth level.

Highly useful for board with a lot of child forums! Without this hack, all forums are displayed in the forumjump box, thus reducing its effectiveness and attractiveness.

Please post your opinions on this hack, and whether you like it or not. I was discouraged when no one installed my last hack, and it might determine whether I keep releasing hacks in the future...

Thank you!

What's new in version 1.1?
When moving a thread, the target forums list should contain all the forums. This has been fixed in this version. If you have already installed the first version, read the instructions on post #10 in this thread. Otherwise, the attached files are already updated.

[Swayed]

I decided to test this out on a cleanly installed test forum, and got the same thing. I'm pretty sure it's caused by version 2.2.5. The error was not brought about by a change in the global.php file, but rather one of the changes made by the functions.php file (which is also mentioned in the error).

Maybe at some point I'll try to figure out what is going on (I really want this script), but for now I would say not to install it on 2.2.5.

[Q8vbhacks]

also me help i get

Parse error: parse error in /..../....../....../admin/global.php(79) : eval()'d code on line 1

in admin Control Panel

also in forumhome

Parse error: parse error in /..../....../....../vb/global.php(103) : eval()'d code on line 1

Warning: Cannot add header information - headers already sent by (output started at /..../....../....../vb/global.php(103) : eval()'d code:1) in /..../....../....../vb/admin/functions.php on line 1459

[mgoiriz]

I think there's a problem when, in install_forumjump_depth.php, this line gets executed:

PHP Code:

$result = mysql_query ("UPDATE template SET template = template + '\$forumjumpdepth = \"$forumhomedepth_value\";\n' WHERE title = 'options'"); 


The field 'options' in table 'template' ends up being a simple 0, so all the previous options get deleted, and that's why I used to get the eval()'d errors.

Hope I helped.

[Q8vbhacks]

very thank but what A query but in phpmyadmin to remove this change & back like before

[Kianor]

I got the same error with 2.2.7, how can I go back again to a working situation?

Anyone knows a query to do to restore everything?

[ZiRu$]

a friend of mine installed this hack. He has the same problem....now he has to start from scratch. It's too bad because everyone else is having problems too.

[Edgemyster]

i've got the same problem and it's completely killed my forum... :<

we managed to restore our template.template(title='options') value from a stored version, but changes made to the setting table are irreversible since they are mathematically determined. Not so sure they should have anything to do with the problem though. The options template correction did NOT restore the site's functionality.

We are running 2.2.9, so the problem is not version-specific.

Sincerely,
- Screwed

[Edgemyster]

After 4 hours of pulling our hair out ... we fixed the problem.

This is the issue that some of you may get after installing the hack that basically turns your site to crap (parse errors at the top of every page - php files refusing to run, etc.).

We tracked the error to a database table that is modified by this hack. A query within this hack's installation file basically killed (removed) the 'options' data the "template" table all together. We had to restore this from an old backup.

After having done that, we still have the same problem. Firefly actually suggests in another thread to access the AdminCP, load the options, then save them - indicating that should fix the problem. It may for some of you, but we couldn't personally access our AdminCP any longer.

To make a long story a little bit longer, we did the following and got things working again:

1) Restore the 'options' data to the 'template' table from an old database backup. Try this first if you discover that your data has been erased here as well.

2) If you still have errors focusing on this line in the two global.php files (as we did) that points to the data modified in the database by the hack:

eval($optionstemp[template]);

Then comment out that line in ADMIN/global.php. And then load the AdminCP.

3) Click on your VB options, then save the options in AdminCP, as Firefly had suggested, and wah-lah - everything of ours was back up and functioning again.

A rather easy fix for something we beat our heads over for the last 5 hours.

My suggestion? DO NOT load this hack if you're operating on or around version 2.2.9 until it's problems are addressed (if ever).