[TH] Custom Fields [Deleted]

I've replicated your first issue, but still struggling to replicate the second -- I don't think it is the old debug mode bug after all (although it will only appear in debug mode).

Is there anything unusual about how you set it up? What settings do you have for the custom field?
 
Ok thanks for you feedback. I'll post screens of my configuration tomorrow but it is really basic params because I set this up quickly to demonstrate the first issue.
 
Hi @Waindigo,

There are some issues with the "Article discussion link" custom field used with the Library add-on.

First, each time I edit an article with an existing link, the combo boxes come up empty (ie the existing content is not set, but nodes and threads are present and selectable). When clicking on the Save button, the link is lost.
View attachment 60163View attachment 60164
To fix this, in library/Waindigo/Library/ControllerPublic/Article.php, replace line 207:
PHP:
list($article, $library) = $laapHelper->assertArticleValidAndViewable($articleId);
with:
PHP:
$fetchOptions['join'] = Waindigo_Library_Model_Article::FETCH_FORUM_ID;
list($article, $library) = $laapHelper->assertArticleValidAndViewable($articleId, $fetchOptions);

Also, when browsing the threads list, the threads are ordered by thread_id although it used to be ordered by title (if I remember correctly). This makes the above bug even more painful when you have to look for the thread name each time you edit the article.
I believe it is ordered by most recent post date. This is deliberate, because it is assumed that you will want to associate with a thread that has been recently created. Obviously with this bug it becomes less likely, but I'm not going to change it because of a bug (that is now fixed).
 
I confirm the fix is working. Thank you very much for this.

About the alphabetical order, no worries, this was probably one of my own mod that got broken. This is to cover my very specific requirements, I'll do without it.

Thanks again.
 
Hi @Waindigo,

Here are the captures from my configuration. You'll see there is an error that popped in there too.

My staff escalated an issue related to the first one: now when editing a thread, the linked article combo boxes are well initialized, but the link is lost whenever they save their changes (even when leaving the link selection untouched).
 

Attachments

  • WL0.webp
    WL0.webp
    51.9 KB · Views: 18
  • WL1.webp
    WL1.webp
    50.8 KB · Views: 19
  • WL2.webp
    WL2.webp
    21.9 KB · Views: 20
Hi @Waindigo,

My staff escalated an issue related to the first one: now when editing a thread, the linked article combo boxes are well initialized, but the link is lost whenever they save their changes (even when leaving the link selection untouched).

About this bug, I've found out that, in Waindigo_Library_Extend_XenForo_DataWriter_Discussion_Thread_Base::_discussionPreSave(), in library/Waindigo/Library/Extend/XenForo/DataWriter/Discussion/Thread.php on line 64,
Rich (BB code):
if (isset($this->_updateCustomFields['waindigo_select_library']['content_id'])) {
                    $this->set('article_id', $this->_updateCustomFields['waindigo_select_library']['content_id']);
                } else {
                    $this->set('article_id', '');
                }
The article_id field is reseted because the $this->_updateCustomFields['waindigo_select_library'] field is still serialized (so ['content_id'] is not set).

Hope this helps you fix this bug.
 
Last edited:
I created a custom field with the id "rating" to node 3 (belongs to your library addon).

I have added
1 - {$customFields.rating}

to the template header_node.3


But nothing is displaying. Am I overlooking something?
 
Hi @Waindigo,



About this bug, I've found out that, in Waindigo_Library_Extend_XenForo_DataWriter_Discussion_Thread_Base::_discussionPreSave(), in library/Waindigo/Library/Extend/XenForo/DataWriter/Discussion/Thread.php on line 64,
Rich (BB code):
if (isset($this->_updateCustomFields['waindigo_select_library']['content_id'])) {
                    $this->set('article_id', $this->_updateCustomFields['waindigo_select_library']['content_id']);
                } else {
                    $this->set('article_id', '');
                }
The article_id field is reseted because the $this->_updateCustomFields['waindigo_select_library'] field is still serialized (so ['content_id'] is not set).

Hope this helps you fix this bug.
Hi @Waindigo,

About this issue, I've managed to get it to work by modifying Waindigo_CustomFields_Extend_XenForo_DataWriter_Discussion_Thread_Base::setCustomFields(). On line 172, add the red following code:
Rich (BB code):
            if ($value !== $existingValue) {
                $finalValues[$fieldId] = unserialize($value);
            }

Could you confirm this should not break anything else, please?

EDIT : Well, it does.
unserialize() expects parameter 1 to be string, array given

  1. XenForo_Application::handlePhpError()
  2. unserialize() in Waindigo/CustomFields/Extend/XenForo/DataWriter/Discussion/Thread.php at line 173
  3. Waindigo_CustomFields_Extend_XenForo_DataWriter_Discussion_Thread_Base->setCustomFields() in Waindigo/CustomFields/Extend/XenForo/DataWriter/Discussion/Thread.php at line 80
  4. Waindigo_CustomFields_Extend_XenForo_DataWriter_Discussion_Thread_Base->_discussionPreSave() in Waindigo/Library/Extend/XenForo/DataWriter/Discussion/Thread.php at line 60
  5. Waindigo_Library_Extend_XenForo_DataWriter_Discussion_Thread_Base->_discussionPreSave() in XenForo/DataWriter/Discussion.php at line 308
  6. XenForo_DataWriter_Discussion->_preSave() in XenForo/DataWriter.php at line 1434
  7. XenForo_DataWriter->preSave() in XenForo/DataWriter.php at line 1373
  8. XenForo_DataWriter->save() in XenForo/ControllerPublic/Thread.php at line 945
  9. XenForo_ControllerPublic_Thread->actionSave() in Waindigo/CustomFields/Extend/XenForo/ControllerPublic/Thread.php at line 234
  10. Waindigo_CustomFields_Extend_XenForo_ControllerPublic_Thread->actionSave() in XenForo/FrontController.php at line 337
  11. XenForo_FrontController->dispatch() in XenForo/FrontController.php at line 134
  12. XenForo_FrontController->run() in D:/xampp/htdocs/xenforo/index.php at line 13
Got this error when modifying another custom field. Still looking for how to fix this...
 
Yer, that won't work. I think the custom field just needs completely re-writing. This is a bug with the library custom field, not with this add-on.
 
Does the contents of the template show when you edit the library node?

upload_2013-11-4_11-24-13.webp

Does this error have anything to do with whats happening?

Where when editing the library node should the template contents be displayed? If I edit the actual article in the library node, yes - the information is displayed. So it is being saved.
 
This is unrelated.


When you edit the node in the Admin Control Panel.

upload_2013-11-4_12-40-0.webp

Thats what I have right now. Do I need to add that directly to the template too? Because with it in the template it doesn't work, nor does it work with a stock unedited template.
 
I've gotten it working. It was my mistake. Awesome modification as always, Waindigo.
 
Did you basically turn off everything for the resource manager in this mod? I just realized that since the update non of the fields I created, prior to the update, with this mod show up in the sidebar anymore. Nor is there any option to do so with the XF settings? Can we get this fixed? It kind of broke my entire project. :(
 
Did you follow the instructions and rebuild the caches? If you don't then it won't work.

The show in sidebar option is still in the same place on the last tab.
 
Back
Top Bottom