RM 1.2 yet another can't select automatic prefix thread

electrogypsy

Well-known member
So it seems that I cannot assign an automatic thread prefix to a category in the resource manager:

nobueno.webp

Yes, I have thread prefixes assigned to that forum section (furry nomads). And yes, i've created several thread prefixes in the resource manager and assigned them to all the categories in the resource manager.

i'm still getting the above screen shot and can't assign a thread prefix to be assigned to the thread that gets created when adding a resource.
 
I don't think the select menu should ever actually disappear here. Can you confirm the XF and RM versions you're running? I would also recommend disabling other add-ons you have to confirm, especially if they're at all related to the prefix system.
 
hmm... i'm using xf 1.4.10 and RM 1.1.6. i disabled all the plugins via my config.php, but the RM categories page looks exactly the same as it does in my screen shot.

what should i do next?
 
Can you open up a browser console before you load the page? Do you see any errors?

Have you installed any add-ons that are related to prefixes?
 
Can you open up a browser console before you load the page? Do you see any errors?

strangely enough, i don't see any errors:

Code:
XenForo.activate(#document)
xenforo.js?_v=1b5ec4d8:353 Title Element: [h1, prevObject: e.fn.init[1], context: document]
xenforo.js?_v=1b5ec4d8:209 XenForo.init() 212ms. jQuery 1.11.0/1.2.8-dev

Have you installed any add-ons that are related to prefixes?

If I did, wouldn't they not cause the problem if I turn off all plugins in the config.php? I have three plugins installed that are related to prefixes:

Prefix Forum Listing
User Profile - Prefixed Threads 1.0.1 | XenMods
Multi Prefix 1.3.0 | XenMods

the middle one i had @Daniel Hood design for me, so I'm going to have him look this over as well.
 
Multi Prefix changes how prefixes are stored internally, doesn't it? That could be relevant and could survive disabling them.

If you submit a ticket with ACP login details (to see the problem/network trace first hand), we can take a look.
 
Multi Prefix changes how prefixes are stored internally, doesn't it? That could be relevant and could survive disabling them.
Correct. However it doesn't edit the admin template and I don't see any way it'd prevent the list from being generated there. It does not modify the xf_thread_prefix table nor the model. It just allows the thread table to store comma separated values comparable to the xf_user.secondary_group_ids column (not sure that's the right name, just woke up and I'm on my phone).
 
I have had a look for you.

The prefix selector is being hidden by CSS, specifically the same CSS we use on the front end to hide the boring select element and replace it with the pretty prefix selector that you see when creating a thread.

The css.php URL is loading:
Rich (BB code):
&css=devkit%2Cpublic%3Athread_prefixes%2Cpublic%3Atitle_prefix_edit%2Cwaindigo_outdated_addons_installupgrade&dir=LTR&d=1439249927

I suspect including public:title_prefix_edit.css is the problem.

This appears to be coming from the Multi Prefix add-on @Daniel Hood. When I disabled the add-on properly, the above CSS wasn't loaded. I'm not 100% sure how that CSS is being injected into that page but I can confirm that disabling event listeners doesn't prevent it happening. It could be a template mod but I can't see a template mod anywhere for the resource_category_edit template.
 
Very interesting. It might be related to a greedy modification that was pointed out recently. I did not think that this was going to be a css issue. My mistake for dismissing it, sorry. It is the template modification on the template: title_prefix_edit.css
 
Alright, open the template modification for title_prefix_edit.css under "Multi Prefix". Change the replace textarea from

Code:
select.textCtrl.TitlePrefix
{
    display: none;
}

to

Code:
select[name="prefix_id[]"].textCtrl.TitlePrefix
{
    display: none;
}

and that should work.
 
Top Bottom