[TH] Library [Deleted]

[Kim]

You can link a thread to an article by using Waindigo's Custom Fields add-on on top of this Library add-on.

Hello, thank you, but what do you mean by link a thread?

So you have to manually start a thread, then link it? In which case what does the Custom fields add on do in this instance?

:S

 

[ManOnDaMoon]

The Custom Fields addon basically creates a link between a library article and a forum thread. It adds tabs to each view in order to navigate from the article to the thread and back. It also gives the ability to manually create a thread from within the article edition page.

I do not have a working default example ATM, but you should just have a go and try it : http://xenforo.com/community/resources/custom-fields-by-waindigo.885/

 

[Kim]

Ahhh I see, well thank you I will investigate that mod.

Interestingly I would never have looked at a mod titled "custom fields" thinking it would be to do with custom user profile fields >_<

 

[ManOnDaMoon]

It actually does much more, by adding any type of field to an article, not only threads.

 

[Morgain]

Linking a selected thread to the Article is a standard feature.
This has to be an existing thread.

If you want a second thread though you'd need Custom Fields and possibly a little help from Jon or a coder.

 

[Jon W]

Linking a selected thread to the Article is a standard feature.

No it's not. You need the Custom Fields add-on even for one thread.

 

[Morgain]

Oh I guess you spoile d me and put it on mine Thank you.

 

[Coolhaus]

No it's not. You need the Custom Fields add-on even for one thread.

I currently have a couple of library articles linked to their own threads in the forum yet I only have your Library add-on installed. Did it used to be a feature and would the links have remained from an old version? Pretty sure I have the latest version of your Library...

 

[Morgain]

Well that's what I thought - link to thread was always in the original plan and I remember it being added. I don't remember it being a separate addon but I might be mistaken on that.

However it's a little bit incomplete. The article links to a thread but the thread doesn't link to the Article. Should be mutual navig.
All navig on the Article should be topped and tailed - pagination, and link to discussion.

NOT those HORRIBLE tabs please. And NOT that tiny weeny font you don't notice cant find and some of us cant read when we do!
Buttons for pref on same row as the pagination. Thats logical. Keeps the navig all together.
Read Article "[Title of Article]"

I have money at the moment Jon just itching to fly to you.

I also want Edit Article / Edit Page/ Create Page to come out of that pestiferour dropdown - BUTTONS!

 

[Coolhaus]

Version 1.3.0 released

New features:

• Added support for Thread Thumbnails by Waindigo add-on (requires v1.3.0+).
• Added support for thread prefixes.
• Added ability to create new thread on article creation.
• Added ability to move articles.

I am sure there were reasons for the feature being removed but it did exist in a previous version and I wasn't imagining things But out of curiosity it is no no longer in the updated version - there is no longer an option to create a linked thread (even though previous links still function correctly).

On the few articles I have that do link to threads there is mutual navigation via tabs - I agree some kind of button would look better and I imagine that could be implemented to visually align with the page numbers.

 

[Morgain]

Glad you too like buttons.
Jon knows I can do them by template edits but I don't want to do that on 4 different boards, posibly a 5th on the way. I want the addon to have it.

Hmm I have a very recent install last November and it does not have mutual links. Whats going on?
After all I'm the prima donna of this addon - my dream for years.

Dearest sweetest magical Jon whats up withy thread links? Mutual links?

And pretty please BUTTONS!
<----- button fetishist

 

[Jon W]

I think Version 1.3.1 moved the feature to the Custom Fields add-on. If you upgrade to the latest version, it should fix any problems you are having with mutual tabs. You may have to rebuild the library cache after upgrading.

 

[Morgain]

Please sir ... TMS?

The 5th board will only duplicate things.

 

[Jon W]

http://xenforo.com/community/resources/template-modification-system-tms.293/

 

[ManOnDaMoon]

Hi Waindigo,

I need some help identifying a bug or compatibility issue that, I believe, is javascript related. And I'm no good when it comes to javascript.

I have the BBCodeManager addon installed, and with it comes some BBCodes like Spoiler that use javascript.
In normal times it looks like this :

​

But when I edit an article page and save it inline, it seems that the BBCM javascript is not called up again for the modified content. The resulting content is using a "no javascript" version, see below:

​

I investigated a bit the error, and it seems that in the JS function XenForo.UpdateArticlePage you simply modify the innerHTML content of the article page.

document.getElementById('messageParsed').innerHTML = e.ajaxData.result;

I also noticed that the BBCM spoilers are displayed very well within standard forum messages, even after inline edition. I had a look at the XF javascript source for XenForo.InlineMessageEditor (in discussion.js, line 205). It uses a custom function instead of modifying the innerHTML attribute, line 227:

XenForo.showMessages(e.ajaxData, overlay.getTrigger(), 'instant');

and... this goes beyons my abilities.


Starting with the info I collected, could you have a look at this, please?

 

[ManOnDaMoon]

More info from the Firebug console.

The console output when editing an article page:


The same output when editing a thread post:


Notice there is an additional call to XenForo.activate on a message selector in the latter. Hope this helps!

 

[Jon W]

Hi Waindigo,

I need some help identifying a bug or compatibility issue that, I believe, is javascript related. And I'm no good when it comes to javascript.

I have the BBCodeManager addon installed, and with it comes some BBCodes like Spoiler that use javascript.
In normal times it looks like this :

View attachment 40114​

But when I edit an article page and save it inline, it seems that the BBCM javascript is not called up again for the modified content. The resulting content is using a "no javascript" version, see below:

View attachment 40115​

I investigated a bit the error, and it seems that in the JS function XenForo.UpdateArticlePage you simply modify the innerHTML content of the article page.

document.getElementById('messageParsed').innerHTML = e.ajaxData.result;

I also noticed that the BBCM spoilers are displayed very well within standard forum messages, even after inline edition. I had a look at the XF javascript source forXenForo.InlineMessageEditor (in discussion.js, line 205). It uses a custom function instead of modifying the innerHTML attribute, line 227:

XenForo.showMessages(e.ajaxData, overlay.getTrigger(), 'instant');

and... this goes beyons my abilities.


Starting with the info I collected, could you have a look at this, please?

Javascript is not my favourite either (which is probably why I initially replaced the above code with my own line). I've just had a little play, and you can make the replacement above, provided you make the following replacements.

First, add the following to the top of the template waindigo_article_container_library:

<xen:require js="js/xenforo/discussion.js" />

so that you can use the above function that you mentioned.

In the same template, find the line:

data-href="{xen:link article-pages/edit-inline, $articlePage}" data-overlayOptions="{"fixed":false}"

and replace with:

data-href="{xen:link article-pages/edit-inline, $articlePage}" data-overlayOptions="{"fixed":false}" data-messageSelector="#messageParsed"

as this is needed by the above function.

Then you need to replace the following line in the template library/Waindigo/Library/ViewPublic/ArticlePage/View.php:

$output['result'] = new XenForo_BbCode_TextWrapper($this->_params['articlePage']['message'], $bbCodeParser, $extraStates);

with

$output['templateHtml'] = '<div id="messageParsed">' . new XenForo_BbCode_TextWrapper($this->_params['articlePage']['message'], $bbCodeParser, $extraStates) . '</div>';

It's a bit of a hack for now (really I should replace a few more lines to do it properly), so if it works I'll do it properly for the next update.

 

[ManOnDaMoon]

The hack works with the following additional manipulation in the JS source: test for e.ajaxData.templateHtml instead of e.ajaxData.result.
I replaced the red lines with the green ones in the code:

AutoValidationComplete: function(e)
{
	var overlay = $form.closest('div.xenOverlay').data('overlay'),
		target = overlay.getTrigger().data('target');

	//if (e.ajaxData.result)
	if (XenForo.hasTemplateHtml(e.ajaxData))
	{
		e.preventDefault();
		overlay.close().getTrigger().data('XenForo.OverlayTrigger').deCache();

               	//document.getElementById('messageParsed').innerHTML = e.ajaxData.result;
		XenForo.showMessages(e.ajaxData, overlay.getTrigger(), 'instant');
	}
	else
	{
		console.warn('No template HTML!');
	}
}

Works like a charm! Thank you very much!

 

[Jon W]

The hack works with the following additional manipulation in the JS source: test for e.ajaxData.templateHtml instead of e.ajaxData.result.
I replaced the red lines with the green ones in the code:

AutoValidationComplete: function(e)
{
var overlay = $form.closest('div.xenOverlay').data('overlay'),
target = overlay.getTrigger().data('target');
 
//if (e.ajaxData.result)
if (XenForo.hasTemplateHtml(e.ajaxData))
{
e.preventDefault();
overlay.close().getTrigger().data('XenForo.OverlayTrigger').deCache();
 
              //document.getElementById('messageParsed').innerHTML = e.ajaxData.result;
XenForo.showMessages(e.ajaxData, overlay.getTrigger(), 'instant');
}
else
{
console.warn('No template HTML!');
}
}

Oops. Sorry. Forgot that I made that change too. Glad you caught it.

 

[ManOnDaMoon]

Just FYI, in template waindigo_article_page_edit_library, inside the <xen:title> tags, there is a lonely closing </em>.