Issue: Subdividing Default Namespace

Issue Tools
- View Changes

May 20, 2009 11:11 AM

tommythejoat

Regular Member

Subdividing Default Namespace

When subdividing default namespace can Default be made a vBulletin Category

In order to emulate the structure of our forums, we have created subforums of Default for each of our conversational forums. The result is like a set of topical bookshelves with articles in them but the automatic linking to articles from posts in the forum area still occurs.

We do not want articles to be created directly in Default and it has been made to not accept new posts in order to do that.

It would look a little better if Default could be made a vBulletin Category so we could get rid of the empty box that says "No posts in this forum" down at the bottom of the "bookshelf" list. We changed the status to category and it seemed to work OK, but I was concerned that something not readily visible might go wrong, so we changed it back to a Forum but with posting disabled.

Can Default be made into a Category if it has children that are able to hold articles?

Issue Details

Issue Number 598

Issue Type Bug

Project VaultWiki 3.x Series

Category Namespaces

Status Not a Bug

Priority 7 - Minor Features / Enhancements

Affected Version 2.3.0

Fixed Version (none)

Milestone (none)

Software DependencyAny

Users able to reproduce bug 0

Users unable to reproduce bug 0

Attachments 0

Assigned Users (none)

Tags (none)

May 20, 2009 11:56 AM

pegasus

VaultWiki Team

No it cannot. There are currently two ways of creating an article:

1. You can create an article in the current forum by clicking "Post New Article" from the dropdown.

2. You can click a red link. When you do this, it is frequently unlikely that the current forum is the correct forum - because the link could be an article that is suited for another subforum within that same namespace. The article is instead created in the namespace root as a catch-all, and mods assigned to this forum can check here and move the articles to the appropriate subforum.

Because of #2, a namespace root could never be a vBulletin Category and must be open to new posts - when the user creates a new article via a red link they type in the whole article, hit submit, and get "This forum is not accepting any new posts" which would extremely tick them off.

A change to this would have widespread implications about what constitutes a "namespace", so this confusion will not be sorted out until the 3.x series.

Reply
May 20, 2009 12:10 PM

tommythejoat

Regular Member

Thank you. I was concerned there was a "catch 22" that I had not discovered.

Our users are just beginning to understand what the Wiki is and can do, so we have not had any red link incidents that I am aware of. i.e. there have been no complaints.

I will reopen Default for posting and try to document the behavior (and set up a routine to move the articles.)

In our usage, it would not be impossible for the red links to be resolved since the name of the forum containing the red link would be the same as the article space (subforum) where the article should be created. I like our bookshelf approach to organizing the primary content articles and we will just work around this issue for now.

Reply
May 20, 2009 12:45 PM

pegasus

VaultWiki Team

If that's the case, you should encourage your users to click "Post New Article" from the article CONTAINING the red link, rather than following the link.

Reply
May 20, 2009 4:38 PM

tommythejoat

Regular Member

The users are not posting articles but rather normal posts in non-Wiki forums. I think they will continue to carry on conversations there as your users do here.

Aha, I see you are talking about the Vault drop down menu, not the post new thread button.

Some of them may get accustomed to moving to the article space to post their more serious items.

I have put in links to function as navigation buttons in the header of each forum and each name space. I don't think anyone is really using them. I have not figured out how to make them seem natural or how best to label them. I will keep working on that to make it more intuitive.

What I would consider really elegant for V3 would be the presence of a second "new" button that said New Article along with the one that says New Thread. That with the thread post icon being the Vault Icon rather than the standard set of post icons. Then the Articles with their discussions and the regular threads with their discussions could be intermingled. There could be an option to sort the two types of postings within any given forum or to leave them in the normal default sort order.

Reply
May 24, 2009 1:19 AM

tommythejoat

Regular Member

I opened the top level default forum for posting as directed and one of my users posted an article there. I then moved the article to a subforum of default which appeared to work as expected.

However, when I came back later, the article still appeared in the listing for Default and also appeared in the listing for the subforum. When one clicks on the top level listing you see http://mb.nawcc.org/showwiki.php?title=&goto=newpost

When you click on the listing in the subforum it says the article is empty.

The original contents appear to be lost.

The article title is "Mentoring."

Reply
May 24, 2009 1:57 AM

pegasus

VaultWiki Team

Which method was used to move the article - was it moved via forumdisplay (inline moderation), via the "Move" tab, or via the "Thread Tools" menu (on the Discussion tab), or via a Mass Move Threads (in the AdminCP)?

I have only ever had this problem moderating articles if a parse error interrupted the move action. Update to 2.3.0 Patch Level 1 to make sure the problem wasn't fixed in the patch. Then, you should be able to get the article back by rebuilding the namespace.

Reply
May 24, 2009 9:34 AM

tommythejoat

Regular Member

I moved the article with the move tab. The move appeared to work in that I could read the article in the new location immediately afterr the move.

If I click on the article in the target subforum location, it generates the top level url and says it is empty. The link I posted is what you get if you click on it in the top level forum. By the way, the vault image that displays is quite nice I think.

I will install pl1 later today.

Reply
May 25, 2009 12:07 AM

tommythejoat

Regular Member

I now have pl1 installed, but the behavior remains peculiar for the subdivided Default namespace. I am getting ready to write the Readers Manual for Vault Wiki on our site and I was reviewing the Special Pages.

In particular the http://mb.nawcc.org/showwiki.php?tit...al:Wantedpages report is badly messed up. It lists every article/page that is in my subforums of Default except that it lists them as being wanted in the top level of Default. This listing also includes those pages that are in the Protected Titles. I am afraid this will be too confusing to document until it can be straightened out.

I like the idea of the child forums of Default having names to mirror my long established Forum names, but nearly 50% of the effort on this project is going into trying to repair and work through the results of this structure.

Please help me straighten this out. I really wanted to roll Vault Wiki out for everyone with some good documentation in the next two weeks.

Reply

May 25, 2009 9:37 AM

pegasus

VaultWiki Team

For Wantedpages, before creating the article, your users should click the (X links) part to see what pages are looking for that article. This will give them a better idea for the context. You had mentioned that usually in your setup, an article is only linked to from within the forum it will be created anyway. In that case, users can look up what forum is requesting the article in this way.

In the interest of avoiding a full table scan and crashing one's server, a Protected Titles check for Wantedpages would have to be case sensitive.

You can add the integration by replacing the two queries in vault/extensions/xpages/special_wantedpages.php. For the first one, use instead:

Code:

	$wantednames = $db->query_first("
		SELECT COUNT(DISTINCT(LOWER(link.title))) AS rowcount
		FROM " . TABLE_PREFIX . "vault_link AS link
		LEFT JOIN " . TABLE_PREFIX . "vault_protect AS protect ON (link.title = protect.title AND link.namespace = protect.namespaceid AND protect.options = 4)
		WHERE namespace = " . intval($checkid) . "
			AND targetid = 0
			AND templateusage = 0
			AND protect.protectid IS NULL
	");

For the second one, use instead:

Code:

	$alllinks = $db->query_read("
		SELECT COUNT(title_lower) AS number, link.title
		FROM " . TABLE_PREFIX . "vault_link AS link
		LEFT JOIN " . TABLE_PREFIX . "vault_protect AS protect ON (link.title = protect.title AND link.namespace = protect.namespaceid AND protect.options = 4)
		WHERE namespace = " . intval($checkid) . "
			AND targetid = 0
			AND templateusage = 0
			AND protect.protectid IS NULL
		GROUP BY title_lower
		ORDER BY number DESC, title_lower ASC
		LIMIT $limitlower,$limit
	");

May 25, 2009 11:36 PM

tommythejoat tommythejoat is offline

Regular Member

Thanks, that got rid of the banned titles. Redirects are still behaving strangely, but it is not a big problem.

When I follow the links where it says there are many, I generally see no links. I am not sure how to interpret that.

While I was editing the wanted pages file, I made a typo trying to enter a comment and ended up looking at my php error log. I found these entries that may be useful to you.

HTML Code:

[25-May-2009 13:08:37] PHP Fatal error:  Call to a member function shutdown_query() on a non-object in /var/www/html/vault/special_plugins_showpost.php on line 104
[25-May-2009 13:13:14] PHP Fatal error:  Call to undefined function  special_hook() in /var/www/html/vault/special_class_postbit.php on line 1328
[25-May-2009 13:13:27] PHP Fatal error:  Call to undefined function  special_hook() in /var/www/html/vault/special_class_postbit.php on line 1328
[25-May-2009 13:13:45] PHP Fatal error:  Call to undefined function  special_hook() in /var/www/html/vault/special_class_postbit.php on line 1328
[25-May-2009 13:28:19] PHP Fatal error:  Call to undefined function  special_hook() in /var/www/html/vault/special_class_postbit.php on line 1328
[25-May-2009 13:28:46] PHP Fatal error:  Call to undefined function  special_hook() in /var/www/html/vault/special_class_postbit.php on line 1328

The repeated line is repeated about 15 or so more times than shown.

I will start monitoring php errors and report them to you when they are in Vault Wiki code.

May 25, 2009 11:46 PM
pegasus

VaultWiki Team
In vault/special_class_postbit.php, find:

Code:

$hook = special_hook('vault_wikipost_attachment')) ? eval($hook) : false;

Replace with:

Code:

if (function_exists('special_hook')) { ($hook = special_hook('vault_wikipost_attachment')) ? eval($hook) : false; } else { ($hook = vBulletinHook::fetch_hook('vault_wikipost_attachment')) ? eval($hook) : false; }

In vault/special_plugins_showpost.php, find:

PHP Code:

$db->shutdown_query("

Add above:

PHP Code:

global $db;

Please start new issues when you find anything else. Putting multiple bugs in one report makes it very difficult for us to track the status of each one individually (for example, this issue is already marked "Not a Bug").
Reply

+ Reply

All times are GMT -4. The time now is 12:48 AM.

This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.

Learn more… Accept Remind me later

Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

Issue: Subdividing Default Namespace

Issue Tools