Custom entry tabs with custom layouts - bug or doing it wrong?

I’m currently having the exact same issue but with the Tag module - see this thread on the Solspace forum.

Removing the Publish Layout fixes the problem, but whenever I change and save a new Publish layout, my Tags tab show up blank (as in your screenshot).

K- with the SEO module? It’s a third party issue. Basically- in tab.dm_seo.php in publish_tabs:

$settings[$field] = array(
'field_id' => 'seo_'.$field,

Try that instead of ‘field_id’ => ‘dm_seo_’.$field.

What was going on- your tab array is:

$tabs['dm_seo'] = array(

            'seo_title'=> array(
                'visible'    => 'true',
                'collapse'    => 'false',
                'htmlbuttons'    => 'false',
                'width'        => '100%'
                ),

EE prefixes the fields to avoid collisions- but it strips the prefix before sending the tab file the data- so you don’t have to muck with it. Anyway- point being- the tab field is seo_title- but in the tab publish_tabs function you were looking for ‘dm_seo_title’. Er- that make sense?

I didn’t poke everything- but just tweaking that got rid of the php errors on the publish screen.

Take another poke around after making those changes and let me know how it goes. I’m going to mark the bug fixed in the tracker because I think core is ok. But if you do run into anything- I’m subscribed to this thread. And if a bug does come up- we can start a fresh bug post. Sound good?

Thanks for looking into this Robin.

I’ve made the suggested change to tab.dm_seo.php::publish_tabs(), but it’s not made any difference.

When I un-install the module, re-install and follow the checklist in the first post of this thread the fields all disappear.

To clarify: I’ve not been getting any php errors - where are you seeing them? Also, the module works exactly as expected when no custom entry form layout is applied. It’s only when a custom layout is applied and the form refreshed the the problem can be seen.

Right- it’s something with the tabs that’s causing the issue. And keep in mind- I am running a new version than the release, so it is possible you’re catching an error that I’m not. (In which case- the next release should clear it up.)

That said- unedited? With a saved layout- I go install the module. Then I go to publish- and in the SEO tab I have a string of errors:

A PHP Error was encountered

Severity: Notice

Message: Undefined index: dm_seo__seo_title

Filename: content/publish.php

Line Number: 141

Loops- basically an error for each field. I make the change above? No error.

Hrm- though it blows errors when I submit:

Severity: Notice

Message: Undefined index: dm_seo_title

Filename: dm_seo/tab.dm_seo.php

Line Number: 97

Looks like a similar issue down there-

'title' => $params['mod_data']['seo_title'],
            'description' => $params['mod_data']['seo_description'],
            'keywords' => $params['mod_data']['seo_keywords'],

That’s post edit- the keys were ‘dm_seo_title’- but again, that’s not the field name from the tab.

And- after that, backend wise it seems to be working fine for me.

Right- it’s something with the tabs that’s causing the issue. And keep in mind- I am running a new version than the release, so it is possible you’re catching an error that I’m not. (In which case- the next release should clear it up.)

I guess that explains my issue with the Tag module tab then, which I mentioned above? If so, I’ll add a note to the Solspace thread to say it’s an EE issue & to wait for the next release.

Thanks.

Well- no, the above issue is definitely a problem with the third party code. It’s possible that there’s a difference in the released code and the dev code that may be a contributing factor. But I definitely can’t say for sure. The test third party module was working fine w/Tabs on the release code.

In short? Two many factors to say for sure right now whether Tag has an issue or not. They definitely want to take a look at it- if it’s an issue in the core code, they’ll note it.

Thanks for confirming Robin. Will leave it with them! 😊

😉 We’re hitting a fast release cycle, so if there is something up in core, it shouldn’t hang them up long. (I did tweak one thing on layouts- the delete_layout_fields function. It was choking on the publish tab array- expecting a simple single dimensional array. Now it should take either. That said- should generally be a moot issue with third party modules as they use delete_layout_tab).

Ahem. Anyway- yep. It definitely needs a closer look before deciding where the problem lies.

Hi Robin

I really wish I could re-create those PHP notices as I’d like to eliminate them from my enquires!

I’ve set my error_reporting to E_ALL, the $debug declaration to 1 in both index.php files and my $config[‘debug’] to 1, but I see nothing.

For info, I’ve traced where the layout issue begins. No data relating to my module submits to EE.publish.save_layout() - captured by /controllers/cp/content_publish.php line 173. Could the PHP notices be related to that?

IMPORTANT UPDATE!

I’ve found the bug - and it really is a bug!

Taken me hours and hours and a few beers but here’s the scoop: A modules tab description in the language file cannot contain spaces. Simple as that.

I’ve attached a simplified module to prove the point. Download and install my “Something” module, go through all the layout adding and you’ll see it works fine. Now un-install and edit the language file to change:

"something" => 'Something'

to

"something" => 'Some Thing'

Re-install the module, go through the same thing and you’ll see the failure. There’s got to be a bug in the layout_publish model or something.

Anyway, apologies if those PHP notices caused confusion but I never thought they were the root of the problem.

Look forward to your response…

I’ve just applied yesterday’s build update and the bug remains.

I’ll give this another day for you to respond and will then re-add to the bug tracker.

For info - an even simpler way to re-create this bug is to take the Ellis Lab sample “Download” module and change the description in the language file to “Down Load” instead of “Download” on line 16

Dang- I didn’t get the subscription notice- likely due to smart notification. I’ll take a look this morning, Darren- let you know what I spot. Thanks for digging deep!

Have submitted a new bug report: https://support.ellislab.com/bugs/detail/13300/

And- I’ll keep the replies there- but this one is fixed up for the next release.