BoldMinded

Publisher does not support the Fluid field type. Please do not contact asking when support will be available.

If you purchased an add-on from expressionengine.com, be sure to visit boldminded.com/claim to add the license to your account here on boldminded.com.

Ticket: Channel Form with Multiple Category Groups

Status Resolved
Add-on / Version Publisher 3.5.1
Severity
EE Version 6.2.7

Mighty Citizen

Mar 15, 2022

- Create a channel with multiple category groups and a relationship field
- Create a channel form with category group fields assigned using category[] as field name (I did this with separate dropdowns split up into category groups but also a general categories field with all groups as seen below; both had issues)

{category_menu}
  <label for="categories">Categories</label>
  <select name="category[]" id="categories" size="4" multiple="multiple">
    {select_options}
  </select>
{/category_menu}

- Submit the form on the English version of the page, the categories and relationship fields get assigned properly
- Submit the form on the Spanish version of the page, the categories and relationship fields aren’t being assigned at all

It seems like the issue stems from when there is a category provided from at least two different category groups

#1

BoldMinded (Brian)

Hi there. This one could take a little time to sort out. The way categories save in newer versions of EE is a bit different, and apparently untested with Channel:Form & Publisher.

Note to self: relevant core code

// Structure category data the way the ChannelEntry model expects it
        $cat_groups = explode('|', (string) $this->entry->Channel->cat_group);
        if (! empty($cat_groups) && isset($_POST['category'])) {
            $_POST['categories'] = array('cat_group_id_' . $cat_groups[0] => (is_array($_POST['category'])) ? $_POST['category'] : [$_POST['category']]);
        }
#2

Mighty Citizen

Thanks for the response Brian - do you happen to have a ballpark timeline? Just need an idea to send to the client

#3

BoldMinded (Brian)

Sometime within the next week or so? First I have to replicate it, and then hope the fix is easy 😊

#4

Mighty Citizen

Sounds good - thanks Brian!

#5

BoldMinded (Brian)

What does your template code look like for selecting and saving a relationship?

#6

Mighty Citizen

I’ve tried with both the default field tag

{field:resource_diagnoses}

and this hardcoded version

<select id="resource_diagnoses" name="resource_diagnoses[data][]" multiple>
 <option value=""></option>
{exp:channel:entries channel="diagnoses" order="title" sort="asc" dynamic="no" limit="250" disable="categories|pagination|member_data|custom_fields"}
 <option value="{entry_id}">{title}</option>
{/exp:channel:entries}
</select>
#7

BoldMinded (Brian)

Question about the Relationship field. Do you have Persistent Relationships enabled? Because if you do (it’s the default setting) then Relationship field are working as expected in Channel:Form tags. The next comment will include a link to a build to fix the category saving.

#8

BoldMinded (Brian)

Comment has been marked private.

#9

Mighty Citizen

Aha that makes sense, will check and give that a shot on Monday! Thank you!

#10

Mighty Citizen

Haven’t given that build a shot yet but will in a second.

Re: the persistent relationship field bit. I was thinking about it more today and while we do have persistent relationships enabled and it makes sense that it wouldn’t update relationships for the Spanish draft if the English draft existed with relationship data, in our case the relationship field data isn’t being saved anywhere since there isn’t an English draft yet since it’s a completely new entry.

I see that we have the following:

<input name="lang_id" value="1" type="hidden">

Which seems like something we did in the past to just create the English entry whether the user is on the English or Spanish version of the site, which should theoretically save the relationship data properly so maybe our issue is that the lang_id field isn’t working as expected.

#11

BoldMinded (Brian)

Try publisher_lang_id or no language field at all. I wasn’t using one and it saved correctly. It’s probably using the session language if it’s not defined explicitly in the form.

#12

Mighty Citizen

The categories seem to be saving in the different category groups now!

I still can’t seem to get any relationship field data to save (unless I’m on the English side and it saves an English entry then it saves properly). I tried lang_id and publisher_lang_id set to 1 to at least get it to save as an English entry but it always still saves as Spanish. I also tried not including the lang_id, which just seems to default it to Spanish if I’m on the Spanish side.

Are you able to override the language ID from a hidden field?

#13

BoldMinded (Brian)

You can try “site_language” as the hidden field name.

#14

Mighty Citizen

Nope, still showing up as a Spanish entry

#15

BoldMinded (Brian)

On line 652 of Session.php is this

if (ee()->input->get(‘lang_id’)) {

Change it to

if (ee()->input->get_post(‘lang_id’)) {

and add a hidden input with lang_id as the field name, and see if it saves correctly.

#16

Mighty Citizen

Yeah, that saves the entry correctly but it also changes the current session language to English (which makes sense based on the code change) but we would like for the session language to not be changed and just the submitted entry’s language to be overridden.

The ultimate goal though is for the relationship data to be saved when on the Spanish version of the Channel form - saving as an English entry was just a workaround for the issue where the relationship data wasn’t being saved for Spanish entries when persistent relationships are enabled.

#17

BoldMinded (Brian)

Ok, coming back to this again with a fresh take. So you want to keep persistent relationships enabled? If so then it appears to be working as expected for me. If persistence is enabled, and you’re saving a non-default language, it will still keep the value as the default language, not the value of anything selected in the form when viewing the Spanish page. Your best bet is to set the form field to disabled when editing it in Spanish. I don’t think there are any additional changes I can make here b/c it’s working as intended.

#18

Mighty Citizen

We do want to keep persistent relationships enabled. It sounds like you are saving the non-default language for a Spanish entry that already has an English entry so it makes sense that it isn’t saving relationship data for Spanish. Our scenario is that we don’t have an English (i.e. default) entry - this is a completely new entry and it would only have Spanish content and we need relationship data saved.

#19

BoldMinded (Brian)

That kind of goes against the concept of persistence. I’m hesitant to make a code change to support this because I don’t know what cascading effects it might have.

#20

Mighty Citizen

It makes sense to not attach just relationship field data to the Spanish entry for the reason you stated - it probably makes more sense for an English entry to also be created that has the relationship field data that defaults to the Spanish content. Or alternatively, go down the pathway we were trying to go down where the entry was just created as an English entry, which would be completely fine too.

Let me know if that all makes sense!

#21

BoldMinded (Brian)

I think I’d have to lean towards creating the English entry first if you want to keep persistence enabled, otherwise that just kind of goes against what Publisher, and the persistence setting, is built to do. You could create the English version first as a Draft, then it’ll be hidden content, then create the Spanish version.

#22

Mighty Citizen

Gotcha - that’s completely fine. if you recall earlier in this thread, the solution we were comfortable with was just creating an English entry while on the Spanish side of the site (i.e. no Spanish draft is created), but none of the fields to try to override the lang id were working for us without forcing the user to switch language in the session.

Just want to confirm, was this working for you? To be clear about the request: - User is on the Spanish side of the site - User submits a completely new entry via Channel form - Code in the form overrides the language to English - Keep user on the Spanish side of the site - In CP, confirm that the entry is submitted in English, which allows relationship field data to be saved

#23

BoldMinded (Brian)

If the user is viewing the Spanish site, they should be saving the entry in Spanish. I reviewed the code and it was never intended to be viewing the site in language A, but be able to save the data in language B. It only works to save as Draft if viewing Published, or save as Published if viewing Draft.

Login to reply