Symphony.

@nickdunn: Here the javascript error shown in Safari:

TypeError: Result of expression 'q' [null] is not an object.

@guillem_l unfortunately I never found a fix, though refreshing the page a couple of times generally got the tabs to render correctly.

More concerning was that sometimes it duplicated the subsection managers, so one one page where I have 2 Subsection Manager fields, it rendered 4, but only in Chrome ( never tested in safari )… madness.

I couldn’t reproduce it effectively though, and never got js error so hopefully yours will shed some light on it.

@Ryu: I have this same issue in Chrome. In other browsers it renders fine, but in Chrome it renders the ‘Browse…’-field twice. They both are functional. However, when I refresh the page, it renders correctly, so this only happens if I click on an entry and come in the edit-screen (or create new-screen).

Is this a bug of Publish tabs? Of Subsection manager? Or Chrome perhaps?

Attachments:

SS-2010-11-29_10.45.48.png

@kanduvisla: The same in Safari, javascript error it’s what I post in #41. There are something in one of this 2 extension that cause a conflict in jquery in WebKit browsers.

@Nick, one small issue.

I’ve changed the 414 line as in Link14.08 and Link26.08 but it doesn’t work (Symphony 2.1.2). I get the Publish Tab named “Persoana de Contact” as a single field after the other fields. See image in attachment.

Any ideas? Muchas gracias :)

P.S. You should update in Extension’s Description and in GitGub repo the fix link from Link14.08 to the more recent Link26.08.

EDIT: Issue solved. There must be at least one other field after a Publish Tab in order to activate the tab, else the Publish Tab will default to simple field.

Attachments:

publish_tabs_issue.png

Concerning the javascript error in webkit browsers (Safari, Chrome) when use this extension with subsectionmanager field I use a quick fix that seems that solve the problem.

Replace:

PublishTabs.init()

With:

setTimeout('PublishTabs.init()', 100);

With this modification publishTabs are initialized after all other fields are loaded, and avoid the conflict with subsectionmanager.

Publish Tabs updated to version 0.9.3 on 5th of February 2011

Publish Tabs updated to version 1.0 on 7th of February 2011

Great stuff, Nickdunn.

My input for the possible future:

1. Small usability improvement - it could stay on the same tab, when reloading page after saving.
2. Option to tab only sidebar. Or vice versa.. or both sides independently :)

Hi Nick, I'm using this for a site in 3 languages, so i set up a tab for each language fieldset, This makes it well organized, nice extension! After saving the page it switches back to the first tab. this is a bit confusing when your working in one language fieldset and after saving you're in another as they're all set up similar.

So a cookie saving the tab state would be a nice addition i suggest.

That's two consecutive requests for tab state persistence. I have some installs where I always want it to return to the first tab on save, so perhaps this will need to be an option on the tab. Or something.

Would be very nice! :)

Is there scope to escape the tabs like a clear:both sort of function that could be added? What I have is 2 tabs - 1 for each language and then generic data that can be used in both tabs/languages.

Does Publish Tabs understand content I don't want in tabs? The publish checkbox and dates etc.. should ideally be outside of the tabs in some situations no?

Does Publish Tabs understand content I don't want in tabs?

Nope, it's all or nothing. Fields that aren't explicitly in a tab presently go into an "Untitled" tab if I remember correctly.

The publish checkbox and dates etc.. should ideally be outside of the tabs in some situations no?

Could these go into a third "General" tab? Do you have a mockup of how you might expect non-tabbed content to work alongside tabs?

General Tab is a good idea. Tabs don't seem to kick in on 2.2.1 install at present either (chrome browser).. looking at CSS and js loading or not.. I guess if there is a Tab in Sidebar that is for general fields that would work... just thinking of things like imagecropper (nice big editing space) that isn't needed to be tababble.. thinking about nested tabs to achieve this layout, possible?

EDIT

Re installed/ FTP'd js and css, all is well. :)

Attachments:

no_tabs.jpg

@nickdunn: Why did you use a field ? Wouldn't it work without a field ? Simply by-prefixing entries with a constant ? (i.e tab-1, tab-2) Or work at the section level ? Because Field are supposed to store DATA not how to display it. I would like to have your thoughts on this. Thanks.

Because Field are supposed to store DATA not how to display it

Yes and no. Many fields are named according to how they are rendered, rather than the data they store, such as the Map Location Field. It just stores latitude/longitude pairs, but it is rendered as a Google Map. So I think of fields not as database columns, but as widgets. In this way, my mental model when adding fields through the section editor isn't as a database developer adding columns to a database table, but as a UI designer arranging input elements on a form.

A "Select Box Link" field is actually a link table to allow one-to-many and many-to-many relationships, but when you create the field you think "select box" or "dropdown" and not "link table".

It makes sense for the tabs to be configured in the section editor as they are direct actors on the fields within, and share the same properties as fields (they exist in the publish form like fields, they can be dragged to re-order like fields, they have labels like fields). I did consider naming conventions, but this becomes unsustainable. What happens if you need to rearrange tabs at a later date and don't have the luxury of renaming fields across the site? Before settling with a field I had tabs configured in a JSON file. The developer would add a new object to an array, specifying the section and field handles for each tab. It's neat, but completely breaks workflow by introducing a non-standard step.

There are many fields that exist not for data input: filter field, reflection field, publish tabs, search index, HTML panel etc. Think of them as UI components and not database columns :-)

@nickdunn: Wow thanks for this neat response. I like you approach and will try it in my next Data Modeling (oups..) UI Modeling activities!

BTW, your extensions works flawlessly in 2.2.1

Please update this extensions. It has some issues with the current Symphony (2.2.5) :(

I get this error:

Fatal error: Call to a member function appendChild() on a non-object in /Users/luglio7/Sites/webbergate/plus_plus/symphony/extensions/publishfiltering/extension.driver.php on line 78