Add-On Releases - CES Navbits Designer

CES Navbits Designer
Version: 1.4.3

*** NEWS ***
3/17/2007 - v1.4.3 released
2/25/2007 - v1.4.2 released
2/3/2007 - v1.4.0, v1.4.1 released
2/2/2007 - v1.3.0 released
1/24/2007 - v1.2.3 released
1/15/2007 - v1.2.0, v1.2.1, v1.2.2 released, screenshots updated
1/7/2007 - v1.1.0 completed - withheld due to inefficient processing
1/5/2007 - v1.0.1, 1.0.2, 1.0.3 released, screenshots added
1/4/2007 - v1.0.0 released - Custom Navbits launched

Known Issues:
- If you are a vbWiki Pro user, and you are getting a "Style has not been updated for Custom Navbits" message in your wiki, see this post: #21

What It Does:
Using a wizard in the AdminCP, allows admins to create a breadcrumb path for the vBulletin navbar that could be practically anything. This is useful for automating navbits on custom pages or anywhere else.

For example: After searching for threads or posts, vBulletin's default lastelement is always "Search Results." However, using this mod, I have been able to change it to "Search Results in Threads" and "Search Results in Posts" respectively.

Products to Install: 1
Plugins Included: 1
Files to Upload: 5
Templates to Edit: 1
Files to Edit: 2
Queries Added:* 0

*This now adds ZERO queries to modified pages, which I figure is the query count we all care about.

Mod Features:
- Add navbits for any page in the AdminCP
- Now makes use of the datastore
- Settings in vBulletin Options
- Supports relative and absolute links
- Breadcrumb can use any custom text
- Name your various custom navbit sets
- Use conditionals for further control
- Set execute priority of navbit sets with overlapping conditions
- Navbits immediately updated
- use FORUM_HOME, THIS_PAGE, WIKI_NAME as preset variables
- supports $vboptions, $vbphrase, other variables, and HTML
- Complete support for vbWiki Pro

How many more features can we add to a navbits extension?

Current Syntax:
As of v1.2.0, just fill in the form!

When using $vbulletin options or $vbphrases, do not use quotes inside the brackets:
BAD: $vbulletin->options['option']
GOOD: $vbulletin->options[option]

Tutorials:
- Introduction to creating custom navbits: Basic Tutorial
- How to exclude a parent forum from multiple subforums at once: Parentlist Tutorial

Changelog:
As of Version 1.4.3:
- fixed a warning that would occur in the AdminCP when no custom sets
had been created

As of Version 1.4.2:
- updated product dependency

As of Version 1.4.1:
- fixed a bug where the last element would be empty if script had a
custom set and the conditions returned false
- updated phrases
- fixed bug where table ces_navbits would not be removed from the
database on upgrade

Ideas for Future Versions:
- Suggestions?

Screenshots:
In order, these screenshots show the process:
1. Before Navbits Management
2. AdminCP Link
3. AdminCP Navbits Manager
4. AdminCP Navbits Designer (pre v1.4.1)
5. After Navbits Management

[blacklancer]

*waits for screen shots*

sounds interesting!

[Hornstar]

well hopefully you will post it by today, because otherwise a mod will delete this as its againt the rules.

You dont need to make a thread like this, there is another way to do what you were probably trying to do. (forgot the name of the option in the product manager)

[thincom2000]

Yeah, I needed the threadid to put in the product. Also taking a little longer than expected to debug. As usual.

[Dismounted]

You can use misc.php?producthelp=PRODUCTID to link to the release thread. Much easier.

[FleaBag]

I really do not understand what this does.

[thincom2000]

It basically provides a manager and designer to change the way navbits are displayed on a page.

For example, I first realized I wanted a mod like this when I installed vbJournal just to handle my site's news. On the news page I didn't want the word "Journals" in the navbits, but it was there.

It's also useful if you have coded your own custom pages. I wrote about 15 of them, where some were TOC, or they had obvious page hierarchies, and I wanted navbits to appear on them and to keep track of this. My navbar template ended up becoming a huge mess of conditionals that eventually took weeks to debug when the navbar stopped working.

Using the interface provided in this mod is not much different than defining the navbits directly in the code (which is a simple task now that I understand how construct_navbits() works). But it sure is a lot more pleasant and MUCH less time consuming to open up a manager in the ACP than searching through the source code to modify navbits entries one by one.

[thincom2000]

Sorry to double post in my own thread, but I have a question to those few who are actually using this mod. And also the instructions to get it working if you didn't read the readme.

As I'm working on the much more efficient v1.2.0, I think it's possible to have the installer/another page do all the file edits automatically, but is it that unfair to ask people to open the vBulletin PHP files in their FTP clients, search for the lines:

PHP Code:

$navbits = construct_navbits($navbits); 


or in vbJournal's journal.php:

PHP Code:

$navbits= construct_navbits($navbits); 


(I hope that's the only addon that doesn't use spaces appropriately)

Would it even be wise to have automated file edits add:

PHP Code:

($hook =  vBulletinHook::fetch_hook('Navbits_Process')) ? eval($hook) : false; 


before those lines? It seems to me that manual edits would be safer, that way if the code gets mangled you sort of know what changed. But I have seen people groaning over 1 measly file edit in other threads.

Does anyone have any thoughts?

[Tamrin]

Small question, I read the readme.txt file included with this, and it has a header with:

** FILE EDITS **

Probably a lot. If you want any custom navbits to appear
you must do the following in each PHP file you want
affected by the hack --

Now I'd love to edit our navbits as your plugin allows, but I'm afraid it's going to screw with future forum upgrades due to manual hacks in vBulletin's PHP files.., or am I wrong here ?

[thincom2000]

It's not going to really screw with future upgrades. The changes the hack makes will be overwritten when you upgrade to a newer version of vBulletin, and the modifications made have no known negative side-effects on vBulletin functionality. All we're doing is adding a single line of code here and there, not removing anything at all. <-- I believe that answers your question.

If your issue is not wanting to make file edits again when you upgrade your vBulletin software, read on. Most vBulletin updates are small, and you don't have to overwrite every file every time.

Many hacks may require you to make file edits. The upside of the Product Management system is that after a forum upgrade you can check your products and see which have file edits you may need to do again.

The edit for this isn't a big one, and with a quick Edit -> Find in your FTP client, it really shouldn't take too long to make the changes. The template edits required take into account the case of an upgrade where the new hook is overwritten from your edits, so that your navbits won't be mysteriously broken. Instead, the hack will just be non-functional until you re-edit your files.