UI: Headline Markup

[nilshoerrmann]

This issue summarises the decisions of the UI discussion at the Symposium in Cologne.

The markup of the h2 at the top of the backend should be changed in 2.4, Symphony 2.3 should prepare everything for that markup change (deprecate the old one, presenting the new one)

[designermonkey]

This is a little vague for those that weren't involved. Can you give a little more info on what this is about?

Thankies!

[designermonkey]

This is a little vague for those that weren't involved. Can you give a little more info on what this is about?

Thankies!

[nilshoerrmann]

Sure. The idea is to make the current h2 (the headline displaying section and entry titles) more semantic: it currently contains the buttons on the right as well and the hierarchy is not that clear between h1 and h2. So we'd like to add a wrapping div containing the headline and the buttons that can be used for the new Drawer plugin that will be used for filter interfaces (more on that in another issue soon).

The idea is to not change the markup in 2.3 yet but to deprecate the current implementation and publish the new markup as an information to developers with the release of 2.3. 2.4 will then introduce the new markup and remove the old one.

Does that help?

[nilshoerrmann]

Sure. The idea is to make the current h2 (the headline displaying section and entry titles) more semantic: it currently contains the buttons on the right as well and the hierarchy is not that clear between h1 and h2. So we'd like to add a wrapping div containing the headline and the buttons that can be used for the new Drawer plugin that will be used for filter interfaces (more on that in another issue soon).

The idea is to not change the markup in 2.3 yet but to deprecate the current implementation and publish the new markup as an information to developers with the release of 2.3. 2.4 will then introduce the new markup and remove the old one.

Does that help?

[designermonkey]

Yes, I understand now, and agree. :o)

[designermonkey]

Yes, I understand now, and agree. :o)

[DavidOliver]

It looks like the backend is already using HTML5, so maybe this preparation in 2.3 might be a good time to also look at including the header and footer tags (as opposed to just divs with those ids). It wouldn't make much odds either way for most users, but if it doesn't hurt anyone it might conceivably help certain screen readers regarding accessibility, perhaps more so in the future.

[DavidOliver]

It looks like the backend is already using HTML5, so maybe this preparation in 2.3 might be a good time to also look at including the header and footer tags (as opposed to just divs with those ids). It wouldn't make much odds either way for most users, but if it doesn't hurt anyone it might conceivably help certain screen readers regarding accessibility, perhaps more so in the future.

[nilshoerrmann]

The idea was to not change the backend markup drastically – and this is a quite huge change. So I'm not sure about this idea.

[nilshoerrmann]

The idea was to not change the backend markup drastically – and this is a quite huge change. So I'm not sure about this idea.

[designermonkey]

This is more of a 2.4 idea, and worth considering for then.

Question: is the footer removal due for 2.3?

[designermonkey]

This is more of a 2.4 idea, and worth considering for then.

Question: is the footer removal due for 2.3?

[nilshoerrmann]

Yes, I thought so. Otherwise the navigation changes won't make sense.

(I hear you saying: "Why don't we do all changes now?")

[nilshoerrmann]

Yes, I thought so. Otherwise the navigation changes won't make sense.

(I hear you saying: "Why don't we do all changes now?")

[DavidOliver]

@nilshoerrmann, I've had a quick look at the markup and styling of the header and footer, and I don't think it would have any impact on the styling. It could be as simple as wrapping what is now the header div in a header tag (if the footer is going), so if you think it would be a good thing to do in general I'd recommend thinking about doing it at the same time as you change other semantics of the backend. But in reality I don't see it actually making much difference to (m)any users.

[DavidOliver]

@nilshoerrmann, I've had a quick look at the markup and styling of the header and footer, and I don't think it would have any impact on the styling. It could be as simple as wrapping what is now the header div in a header tag (if the footer is going), so if you think it would be a good thing to do in general I'd recommend thinking about doing it at the same time as you change other semantics of the backend. But in reality I don't see it actually making much difference to (m)any users.

[nilshoerrmann]

It's not about the styling, it's about extensions that rely on the current markup to add other UI elements on the fly.

[nilshoerrmann]

It's not about the styling, it's about extensions that rely on the current markup to add other UI elements on the fly.

[DavidOliver]

I wondered about that - so some extensions use the header?

[DavidOliver]

I wondered about that - so some extensions use the header?

[brendo]

Is it worthwhile finding those extensions that use the Header markup and chatting with the Authors to ensure a smooth transition to 2.3? The less cruft/old stuff in the core the better, and we are doing a major release :)

Bluntly, most extension developers are going to have to update their extension for 2.3 anyway ($this->_Parent is gone, jQuery is updated to 1.6.4 - hopefully 1.7.., new extension metadata etc.), so I don't think it's that big of a problem.

[brendo]

Is it worthwhile finding those extensions that use the Header markup and chatting with the Authors to ensure a smooth transition to 2.3? The less cruft/old stuff in the core the better, and we are doing a major release :)

Bluntly, most extension developers are going to have to update their extension for 2.3 anyway ($this->_Parent is gone, jQuery is updated to 1.6.4 - hopefully 1.7.., new extension metadata etc.), so I don't think it's that big of a problem.

[nilshoerrmann]

So you say we should just break the markup compatibility (again) now?

[nilshoerrmann]

So you say we should just break the markup compatibility (again) now?

[brendo]

Yes.

When did we break it in the first place?

I just feel it's only the Header markup, so it's not going to affect the majority of extensions anyway (but that I mean field extensions).

Do we have a list of extensions that will be affected or is it hypothetical?

[brendo]

Yes.

When did we break it in the first place?

I just feel it's only the Header markup, so it's not going to affect the majority of extensions anyway (but that I mean field extensions).

Do we have a list of extensions that will be affected or is it hypothetical?

[nilshoerrmann]

Keep in mind that the main point of this ussue is to change headlines and headline structure. I'm not sure if these should be changed without notification and so I'm not sure about the other changes. The conclusion in Cologne was to publish the desired future markup as a preview for developers alongside 2.3 but to first implement it in 2.4.

The last time we broke markup support without notification was 2.1. The problem is that I guess most extensions relying on the markup are not published publicly because they were made for special client sites. So we don't have numbers.

That said, I would love to change things now but I'm not sure if it was bad practice. How do frameworks like jQuery handle this kind of fundamental implementation changes?

[nilshoerrmann]

Keep in mind that the main point of this ussue is to change headlines and headline structure. I'm not sure if these should be changed without notification and so I'm not sure about the other changes. The conclusion in Cologne was to publish the desired future markup as a preview for developers alongside 2.3 but to first implement it in 2.4.

The last time we broke markup support without notification was 2.1. The problem is that I guess most extensions relying on the markup are not published publicly because they were made for special client sites. So we don't have numbers.

That said, I would love to change things now but I'm not sure if it was bad practice. How do frameworks like jQuery handle this kind of fundamental implementation changes?

[brendo]

How do frameworks like jQuery handle this kind of fundamental implementation changes?

Through beta's and RC's. Symphony 2.3 isn't launched yet, not even a beta, so we are pretty flexible at the moment.

Again, how many extensions will this affect? That's the single biggest thing that should decide if this is going to be deprecated or just fixed. If it's going to be break 100 extensions, deprecate, if it's going to break 10, just do it. We have Dev Notes and can make noise/contact extension developers directly so they can update their extensions.

[brendo]

How do frameworks like jQuery handle this kind of fundamental implementation changes?

Through beta's and RC's. Symphony 2.3 isn't launched yet, not even a beta, so we are pretty flexible at the moment.

Again, how many extensions will this affect? That's the single biggest thing that should decide if this is going to be deprecated or just fixed. If it's going to be break 100 extensions, deprecate, if it's going to break 10, just do it. We have Dev Notes and can make noise/contact extension developers directly so they can update their extensions.

[nilshoerrmann]

@nickdunn: Mr Dunn, what do you think?

[nilshoerrmann]

@nickdunn: Mr Dunn, what do you think?

[DavidOliver]

Just to clarify the HTML5 header tag part, the safest way to change might be from:

<div id="header">
    <h1>....</h1>
    <ul>....</ul>
</div>

to

<header>
    <div id="header">
        <h1>....</h1>
        <nav>
            <ul>....</ul>
        </nav>
    </div>
</header>

(Note: optional nav tag included - another non-essential HTML5 tag that theoretically improves semantics in the header area.)

The div#header only contains the h1 and nav (not the h2 which I expect more extensions do use). So I imagine it wouldn't affect many extensions at all?

Again, while header and nav might be nice to have at some point, I don't think including them would actually benefit (m)any users, so I wouldn't say they are an important/urgent inclusion. But if it is safe to do so, then it would be a good thing to do with a view to future browsers that may actually do something useful with those tags for users.

[DavidOliver]

Just to clarify the HTML5 header tag part, the safest way to change might be from:

<div id="header">
    <h1>....</h1>
    <ul>....</ul>
</div>

to

<header>
    <div id="header">
        <h1>....</h1>
        <nav>
            <ul>....</ul>
        </nav>
    </div>
</header>

(Note: optional nav tag included - another non-essential HTML5 tag that theoretically improves semantics in the header area.)

The div#header only contains the h1 and nav (not the h2 which I expect more extensions do use). So I imagine it wouldn't affect many extensions at all?

Again, while header and nav might be nice to have at some point, I don't think including them would actually benefit (m)any users, so I wouldn't say they are an important/urgent inclusion. But if it is safe to do so, then it would be a good thing to do with a view to future browsers that may actually do something useful with those tags for users.

[nickdunn]

Thanks David, this looks like a good suggestion to me.

[brendan] Do we have a list of extensions that will be affected or is it hypothetical?

For definite:

These extensions hook for the presence of an h2 and append their shit around it:

• Publish Filtering
• Publish Tabs
• Order Entries

These extensions rely on specific markup to modify the view with CSS

• Subsection Manager (CSS hiding?)
• Modal Editing (not fully released, minor extension)
• Minimal Backend

However because Symphony bastardises the h2 by appending the "Create New" button into the heading directly, any other extensions that add buttons will need amending. More importantly, any extension that implements its own buttons or backend content pages will need amending. These include:

• Dashboard
• Search Index
• XML Importer
• Import/Export CSV
• Backend Views
• Tracker
• Email Template Manager
• Email Template Filter
• Publish Shortcuts
• Author Roles
• Documenter

I'm sure there are more if we search hard enough.

Changing the order of this heading markup isn't too bad — pages that use the appendSubheading method (which I'm optimistically guessing that 100% do) don't care if we add a wrapper or change the position of the heading in the DOM (or even if it's an H1 or an H2). So the two problems that exist:

1. The selector for this area will change. The few that use this with JavaScript will need to be updated regardless. Not a massive issue as the three I know of are mine anyway. (Oops.)
2. Buttons really shouldn't be appended to the heading itself, but this is how all extensions do it. I really think we shouldn't break backwards compatibility for this, as some of the biggest extensions use this, and will be a pain to upgrade.

That is not to say we shouldn't try and fix this. Buttons should not be appended to the heading, and so in the core they should not be. It should set the example. But we need to ensure that the existing method (h2 > a.button) still works, or doesn't break extensions horribly. We can then fully deprecate in a future version.

To this end, we need to figure out what the new markup is going to be for this page title/buttons/drawer area, then add new methods similar to appendSubheading for appending buttons.

[nickdunn]

Thanks David, this looks like a good suggestion to me.

[brendan] Do we have a list of extensions that will be affected or is it hypothetical?

For definite:

These extensions hook for the presence of an h2 and append their shit around it:

• Publish Filtering
• Publish Tabs
• Order Entries

These extensions rely on specific markup to modify the view with CSS

• Subsection Manager (CSS hiding?)
• Modal Editing (not fully released, minor extension)
• Minimal Backend

However because Symphony bastardises the h2 by appending the "Create New" button into the heading directly, any other extensions that add buttons will need amending. More importantly, any extension that implements its own buttons or backend content pages will need amending. These include:

• Dashboard
• Search Index
• XML Importer
• Import/Export CSV
• Backend Views
• Tracker
• Email Template Manager
• Email Template Filter
• Publish Shortcuts
• Author Roles
• Documenter

I'm sure there are more if we search hard enough.

Changing the order of this heading markup isn't too bad — pages that use the appendSubheading method (which I'm optimistically guessing that 100% do) don't care if we add a wrapper or change the position of the heading in the DOM (or even if it's an H1 or an H2). So the two problems that exist:

1. The selector for this area will change. The few that use this with JavaScript will need to be updated regardless. Not a massive issue as the three I know of are mine anyway. (Oops.)
2. Buttons really shouldn't be appended to the heading itself, but this is how all extensions do it. I really think we shouldn't break backwards compatibility for this, as some of the biggest extensions use this, and will be a pain to upgrade.

That is not to say we shouldn't try and fix this. Buttons should not be appended to the heading, and so in the core they should not be. It should set the example. But we need to ensure that the existing method (h2 > a.button) still works, or doesn't break extensions horribly. We can then fully deprecate in a future version.

To this end, we need to figure out what the new markup is going to be for this page title/buttons/drawer area, then add new methods similar to appendSubheading for appending buttons.

[nickdunn]

Also forgot to say that extensions implement their breadcrumbs directly into the H2. We've got suggested markup for this elsewhere.

[nickdunn]

Also forgot to say that extensions implement their breadcrumbs directly into the H2. We've got suggested markup for this elsewhere.

[nickdunn]

Something like:

<div id="wrapper">

    <header id="header">
        <span>Site Name</span>
        <nav class="content">
            <ul>...</ul>
        </nav>
        <nav class="structure">
            <ul>...</ul>
        </nav>
    </header>

    <div id="context">
        // if no breadcrumb, no list, just an h1
        <ul class="breadcrumb">
            <li><a href="#">Parent 1</a></li>
            <li><a href="#">Parent2 </a></li>
            <li><h1>Page Title</h1></li>
        </ul>
        <ul class="actions">...</ul>
        // drawers would be added here
    </div>

    <div id="contents">
        // page body (table or form)
    </div>

    // #footer removed

</div>

[nickdunn]

Something like:

<div id="wrapper">

    <header id="header">
        <span>Site Name</span>
        <nav class="content">
            <ul>...</ul>
        </nav>
        <nav class="structure">
            <ul>...</ul>
        </nav>
    </header>

    <div id="context">
        // if no breadcrumb, no list, just an h1
        <ul class="breadcrumb">
            <li><a href="#">Parent 1</a></li>
            <li><a href="#">Parent2 </a></li>
            <li><h1>Page Title</h1></li>
        </ul>
        <ul class="actions">...</ul>
        // drawers would be added here
    </div>

    <div id="contents">
        // page body (table or form)
    </div>

    // #footer removed

</div>

[DavidOliver]

Just in case anyone hasn't already come across it, this is useful for checking the structural outline of HTML5 markup: http://gsnedders.html5.org/outliner/

("Untitled Section" is okay if it's a nav)

[DavidOliver]

Just in case anyone hasn't already come across it, this is useful for checking the structural outline of HTML5 markup: http://gsnedders.html5.org/outliner/

("Untitled Section" is okay if it's a nav)

[nilshoerrmann]

@nickdunn: Are you sure about using a span for the page title?

[nilshoerrmann]

@nickdunn: Are you sure about using a span for the page title?

[nickdunn]

I consider it relatively un-semantic to the rest of the page. What would you suggest?

[nickdunn]

I consider it relatively un-semantic to the rest of the page. What would you suggest?

[nilshoerrmann]

I'll have to think about it for a moment, I guess, but it looks a bit strange to me (in a hierarchical sense). But maybe this (again) reflects that we both value the importance of the page title differently :)

[nilshoerrmann]

I'll have to think about it for a moment, I guess, but it looks a bit strange to me (in a hierarchical sense). But maybe this (again) reflects that we both value the importance of the page title differently :)

[designermonkey]

I'm going to chime in here...

The page title of an 'application' interface doesn't need to follow the same constraints of a 'website' interface. We don't need to worry so much about the SEO benefit of semantics, yes it wold be nice to be fully 'website' semantic, but it doesn't really matter in the long run.

Either way I'd be happy, but it isn't a big deal at all.

[designermonkey]

I'm going to chime in here...

The page title of an 'application' interface doesn't need to follow the same constraints of a 'website' interface. We don't need to worry so much about the SEO benefit of semantics, yes it wold be nice to be fully 'website' semantic, but it doesn't really matter in the long run.

Either way I'd be happy, but it isn't a big deal at all.

[nickdunn]

Ditto, I'm not fussed what it is. Even retaining it as an H1 doesn't bother me that much so let's not spend too long on this one right? ;-)

[nickdunn]

Ditto, I'm not fussed what it is. Even retaining it as an H1 doesn't bother me that much so let's not spend too long on this one right? ;-)

[nilshoerrmann]

As long a we decide to use some kind of markup I'll be fine. But … (okay, I'll stop here)

[nilshoerrmann]

As long a we decide to use some kind of markup I'll be fine. But … (okay, I'll stop here)

[designermonkey]

If it needs changing in the future, then change it, but pro-action first guys ;o)

[designermonkey]

If it needs changing in the future, then change it, but pro-action first guys ;o)

[eKoeS]

I like David' suggestion about making the markup more HTML5-ish. I also like Nick's proposed outline (not sure about having h1 inside a li, but I agree it doesn't matter that much!).

Let's pave the way for a more semantic and accessible backend, if possible.

[eKoeS]

I like David' suggestion about making the markup more HTML5-ish. I also like Nick's proposed outline (not sure about having h1 inside a li, but I agree it doesn't matter that much!).

Let's pave the way for a more semantic and accessible backend, if possible.

[nilshoerrmann]

Yes, of course. But I think we should still be allowed to question things: in my eyes semantic is about content not about SEO so it's not a theoretical question I was raising. I'm just not sure about the logic of the markup. Full stop here :)

Of course Nick's proposal is a good start we could work with immediately but coming back to the main discussion, we currently have two different options and opinions:

• Don't change the markup now, but prepare everything for 2.4.
• Change the markup now and use the betas and release candidates to spread the word about these changes.

We opted for the first idea in Cologne, while most of the participants here seem to like the idea to change the markup now. I think it would be quite strange to change all the rest of the markup (introducing HTML5 elements) and not taking care of the headline and button problem: using header and footer is not a necessity as the current markup isn't illogical. So in my eyes we should opt for the one or the other way – the how can be discussed and changed over time when we decided if we change things now.

So can I have short votes for the one or the other option, please?
Thanks!

[nilshoerrmann]

Yes, of course. But I think we should still be allowed to question things: in my eyes semantic is about content not about SEO so it's not a theoretical question I was raising. I'm just not sure about the logic of the markup. Full stop here :)

Of course Nick's proposal is a good start we could work with immediately but coming back to the main discussion, we currently have two different options and opinions:

• Don't change the markup now, but prepare everything for 2.4.
• Change the markup now and use the betas and release candidates to spread the word about these changes.

We opted for the first idea in Cologne, while most of the participants here seem to like the idea to change the markup now. I think it would be quite strange to change all the rest of the markup (introducing HTML5 elements) and not taking care of the headline and button problem: using header and footer is not a necessity as the current markup isn't illogical. So in my eyes we should opt for the one or the other way – the how can be discussed and changed over time when we decided if we change things now.

So can I have short votes for the one or the other option, please?
Thanks!

[designermonkey]

Perfectly valid markup.

[designermonkey]

Perfectly valid markup.

[nickdunn]

I vote #2 (change markup in 2.3), but as I described above, ensure the CSS still works for the old markup, so that extensions that implement their own pages with buttons inside H2s still work without any change.

[nickdunn]

I vote #2 (change markup in 2.3), but as I described above, ensure the CSS still works for the old markup, so that extensions that implement their own pages with buttons inside H2s still work without any change.

[DavidOliver]

If the markup is going to be changed, it should be valid, semantic and accurately outline the content.

I very much agree with Simone and Nils that this is about usability and accessibility, not SEO.

I like Nick's proposal.

[DavidOliver]

If the markup is going to be changed, it should be valid, semantic and accurately outline the content.

I very much agree with Simone and Nils that this is about usability and accessibility, not SEO.

I like Nick's proposal.

[nilshoerrmann]

Right, in this case we just need to make sure that the old styles will still be applied to buttons inside an h2. I'm just fine with this.

Any objections?

[nilshoerrmann]

Right, in this case we just need to make sure that the old styles will still be applied to buttons inside an h2. I'm just fine with this.

Any objections?

[nilshoerrmann]

I think I just found the reason why the markup was irritating me: the page title should be a link to the front-end and thus there is no need for a span.

[nilshoerrmann]

I think I just found the reason why the markup was irritating me: the page title should be a link to the front-end and thus there is no need for a span.

[nilshoerrmann]

So what about this adjusted markup:

<div id="wrapper">

    <header id="header">
        <a href="/link/to/site">Site Name</a>
        <nav class="content">
            <ul>...</ul>
        </nav>
        <nav class="structure">
            <ul>...</ul>
        </nav>
    </header>

    <div id="context">
        // if no breadcrumb, no list, just an h1
        <ul class="breadcrumb">
            <li><a href="#">Parent 1</a></li>
            <li><a href="#">Parent2 </a></li>
            <li><h1>Page Title</h1></li>
        </ul>
        <ul class="actions">...</ul>
        // drawers would be added here
    </div>

    <div id="contents">
        // page body (table or form)
    </div>

    // #footer removed

</div>

[nilshoerrmann]

So what about this adjusted markup:

<div id="wrapper">

    <header id="header">
        <a href="/link/to/site">Site Name</a>
        <nav class="content">
            <ul>...</ul>
        </nav>
        <nav class="structure">
            <ul>...</ul>
        </nav>
    </header>

    <div id="context">
        // if no breadcrumb, no list, just an h1
        <ul class="breadcrumb">
            <li><a href="#">Parent 1</a></li>
            <li><a href="#">Parent2 </a></li>
            <li><h1>Page Title</h1></li>
        </ul>
        <ul class="actions">...</ul>
        // drawers would be added here
    </div>

    <div id="contents">
        // page body (table or form)
    </div>

    // #footer removed

</div>

[eKoeS]

as I described above, ensure the CSS still works for the old markup, so that extensions that implement their own pages with buttons inside H2s still work without any change.

Right, in this case we just need to make sure that the old styles will still be applied to buttons inside an h2.

No problem.

Any objections?

Well, since it seems like everybody agrees on the markup, let's roll it into Symphony 2.3. No objections from me.

[eKoeS]

as I described above, ensure the CSS still works for the old markup, so that extensions that implement their own pages with buttons inside H2s still work without any change.

Right, in this case we just need to make sure that the old styles will still be applied to buttons inside an h2.

No problem.

Any objections?

Well, since it seems like everybody agrees on the markup, let's roll it into Symphony 2.3. No objections from me.

[nickdunn]

the page title should be a link to the front-end

Kapow! Of course :-)

[nickdunn]

the page title should be a link to the front-end

Kapow! Of course :-)

[eKoeS]

Two thoughts:

• I think that the two nav elements in #header can be merged into one, with the two ul having different IDs/classes.
• In my opinion, breadcrumbs are a navigation element, so I'd make it nav

[eKoeS]

Two thoughts:

• I think that the two nav elements in #header can be merged into one, with the two ul having different IDs/classes.
• In my opinion, breadcrumbs are a navigation element, so I'd make it nav

[eKoeS]

Do we have a method of dynamically adding content into that area with PHP? I know we can with js using .appendTo(). Maybe a delegate?

That would be as easy as:

$this->Context->appendChild(new XMLElement('div', NULL, array('class' => 'drawer'));

even if I think it's better to do that via JS.

[eKoeS]

Do we have a method of dynamically adding content into that area with PHP? I know we can with js using .appendTo(). Maybe a delegate?

That would be as easy as:

$this->Context->appendChild(new XMLElement('div', NULL, array('class' => 'drawer'));

even if I think it's better to do that via JS.

[designermonkey]

Just checking, you never know what ext devs want to do ;o)

[designermonkey]

Just checking, you never know what ext devs want to do ;o)

[eKoeS]

eheh, no worries ;)

[eKoeS]

eheh, no worries ;)

[eKoeS]

Found another unlucky delegate that is not going to have any place in the new world: AppendElementBelowView. Same question: what shall we do with it?

[eKoeS]

Found another unlucky delegate that is not going to have any place in the new world: AppendElementBelowView. Same question: what shall we do with it?

[eKoeS]

If you want to take a look at my branch, here's the first commit:

eKoeS/symphony-2@90b8100

[eKoeS]

If you want to take a look at my branch, here's the first commit:

eKoeS/symphony-2@90b8100

[nickdunn]

a. Extension-specific items added to the navigation.

I say let the developer chose which group works better. Essential, depending on different use cases. Is the extension modifying content tasks or structural tasks? Maybe administration or developer is a better name than structure.

b. How do we deal with the AddElementToFooter delegate? Do we rename it something like AddElementToUserLinks instead?

How many extensions use it. Can it be removed entirely now there is no footer?

c. If I got it right, the drawer div will be dynamically appended to the page when needed.

Correct. I am exploring ways to do this, so leave for now.

d. AppendElementBelowView

We need to see how extensions are using it. I've found searching on Github to be useful to do this.

[nickdunn]

a. Extension-specific items added to the navigation.

I say let the developer chose which group works better. Essential, depending on different use cases. Is the extension modifying content tasks or structural tasks? Maybe administration or developer is a better name than structure.

b. How do we deal with the AddElementToFooter delegate? Do we rename it something like AddElementToUserLinks instead?

How many extensions use it. Can it be removed entirely now there is no footer?

c. If I got it right, the drawer div will be dynamically appended to the page when needed.

Correct. I am exploring ways to do this, so leave for now.

d. AppendElementBelowView

We need to see how extensions are using it. I've found searching on Github to be useful to do this.

[eKoeS]

AddElementToFooter

• No extensions (except an old one by @nils-werner that is no longer available, version_info)

AppendElementBelowView

• @czheng's ui_navexpander: https://github.com/czheng/symphony-2/blob/f86d73bd52d59b0cb213885a01cda491ec166a4b/extensions/ui_navexpander/extension.driver.php
• @nickdunn's order_entries: https://github.com/nickdunn/order_entries/blob/5d8ad2c98536b3a6cc19fc2f5740ab116a128509/extension.driver.php
• @czheng's documenter: https://github.com/czheng/documenter/blob/ee1fd91a2eb1d2c3baac785a483bfa87a865dedd/extension.driver.php
• @ahwayakchih's translationmanager: https://github.com/ahwayakchih/translationmanager/blob/99645ec181c3b1cef0051ed3201548ae819668af/extension.driver.php

[eKoeS]

AddElementToFooter

• No extensions (except an old one by @nils-werner that is no longer available, version_info)

AppendElementBelowView

• @czheng's ui_navexpander: https://github.com/czheng/symphony-2/blob/f86d73bd52d59b0cb213885a01cda491ec166a4b/extensions/ui_navexpander/extension.driver.php
• @nickdunn's order_entries: https://github.com/nickdunn/order_entries/blob/5d8ad2c98536b3a6cc19fc2f5740ab116a128509/extension.driver.php
• @czheng's documenter: https://github.com/czheng/documenter/blob/ee1fd91a2eb1d2c3baac785a483bfa87a865dedd/extension.driver.php
• @ahwayakchih's translationmanager: https://github.com/ahwayakchih/translationmanager/blob/99645ec181c3b1cef0051ed3201548ae819668af/extension.driver.php

[brendo]

Let's remove AddElementToFooter, it doesn't make sense when no footer exists, so it would be an oddly named delegate anyway.

• Order Entries actually doesn't use AppendElementBelowView since version 1.9, so that's fine.
• Am I right in saying that Translation Manager has been replaced by Localisation Manager?
• @czheng's extensions still use AppendElementBelowView though.

[brendo]

Let's remove AddElementToFooter, it doesn't make sense when no footer exists, so it would be an oddly named delegate anyway.

• Order Entries actually doesn't use AppendElementBelowView since version 1.9, so that's fine.
• Am I right in saying that Translation Manager has been replaced by Localisation Manager?
• @czheng's extensions still use AppendElementBelowView though.

[eKoeS]

Am I right in saying that Translation Manager has been replaced by Localisation Manager?

I think so, yes.

@czheng's extensions still use AppendElementBelowView delegate though.

It shouldn't be a big issue to move the Documenter contents to a different part of the page. @czheng, is that okay for you?

@brendo: Any opinions about the navigation problem?

[eKoeS]

Am I right in saying that Translation Manager has been replaced by Localisation Manager?

I think so, yes.

@czheng's extensions still use AppendElementBelowView delegate though.

It shouldn't be a big issue to move the Documenter contents to a different part of the page. @czheng, is that okay for you?

@brendo: Any opinions about the navigation problem?

[nilshoerrmann]

As we will have a new Drawer plugin, I think the Documenter implementation is likely to change alongside Symphony 2.3 so I think we don't have to care too much about it now. I we do it right, there will the an official hook for the extension to populate a drawer in the sidebar.

[nilshoerrmann]

As we will have a new Drawer plugin, I think the Documenter implementation is likely to change alongside Symphony 2.3 so I think we don't have to care too much about it now. I we do it right, there will the an official hook for the extension to populate a drawer in the sidebar.

[nilshoerrmann]

Do we let the developer chose which group works better?

It should always be up to the developers in my eyes.

[nilshoerrmann]

Do we let the developer chose which group works better?

It should always be up to the developers in my eyes.

[eKoeS]

It should always be up to the developers in my eyes.

Fine for me. It would be as easy as having a new key in the array like:

...
'type' => 'content',
...

If none is specified, it could be structure by default.

[eKoeS]

It should always be up to the developers in my eyes.

Fine for me. It would be as easy as having a new key in the array like:

...
'type' => 'content',
...

If none is specified, it could be structure by default.

[nilshoerrmann]

Sounds good to me.

[nilshoerrmann]

Sounds good to me.

[brendo]

@brendo: Any opinions about the navigation problem?

I think they can sit inside .structure without issue. The Navigation rendering logic is separate to the delegates so developers don't really have a choice other then what top level navigation item they will sit under.

[brendo]

@brendo: Any opinions about the navigation problem?

I think they can sit inside .structure without issue. The Navigation rendering logic is separate to the delegates so developers don't really have a choice other then what top level navigation item they will sit under.

[eKoeS]

So, here's what I've done so far:

• appendFooter has been renamed to appendUserLinks and the version number has been removed (will be probably included in the Preferences page as explained somewhere else here on GitHub...)
• There's no longer $this->Footer while a new element is now accessible called $this->Context, containing the breadcrumbs, the page title and the Drawer
• The signature of appendSubheading has been updated to reflect the changes to the markup. The old $html variable is now called $actions and is supposed to be an array of either XMLElements or strings. However, in order to maintain the backward compatibility, it is still possible to pass a single XMLElement object (this feature will be removed in Symphony 2.4)
• A new method has been created called insertBreadcrumbs that accepts an array of XMLElements and/or strings. Basically, it adds the breadcrumbs before the page title. If a path already exists, the new items are appended to the rightmost part of the breadcrumbs.
• AddElementToFooter has been removed.
• Stylesheets have been updated to reflect the changes in the markup.

[eKoeS]

So, here's what I've done so far:

• appendFooter has been renamed to appendUserLinks and the version number has been removed (will be probably included in the Preferences page as explained somewhere else here on GitHub...)
• There's no longer $this->Footer while a new element is now accessible called $this->Context, containing the breadcrumbs, the page title and the Drawer
• The signature of appendSubheading has been updated to reflect the changes to the markup. The old $html variable is now called $actions and is supposed to be an array of either XMLElements or strings. However, in order to maintain the backward compatibility, it is still possible to pass a single XMLElement object (this feature will be removed in Symphony 2.4)
• A new method has been created called insertBreadcrumbs that accepts an array of XMLElements and/or strings. Basically, it adds the breadcrumbs before the page title. If a path already exists, the new items are appended to the rightmost part of the breadcrumbs.
• AddElementToFooter has been removed.
• Stylesheets have been updated to reflect the changes in the markup.

[brendo]

Good work, sounds great :)

[brendo]

Good work, sounds great :)

[eKoeS]

Open questions

• Can developers decide which part of the main navigation they can append items to? (e.g. structure or content)
• Can we get rid of AppendElementBelowView?
• Is the new backend as sexy as Megane Fox?

[eKoeS]

Open questions

• Can developers decide which part of the main navigation they can append items to? (e.g. structure or content)
• Can we get rid of AppendElementBelowView?
• Is the new backend as sexy as Megane Fox?

[eKoeS]

Breadcrumbs for all the standard content pages

See the commit.

Blueprints

• Authors -> $author
• Data Sources -> $datasource
• Events -> $event
• Utilities -> $utility
• Sections -> $section
• Pages -> $page
• Pages -> $page -> $template

Publish area

• $section -> $entry

Extra buttons in the #context div

Sections -> $section

• View Entries: takes you to $section -> entries

$section -> entries

• Edit Configuration: takes you to Sections -> $section

$section -> $entry

• Edit Configuration: takes you to Sections -> $section

[eKoeS]

Breadcrumbs for all the standard content pages

See the commit.

Blueprints

• Authors -> $author
• Data Sources -> $datasource
• Events -> $event
• Utilities -> $utility
• Sections -> $section
• Pages -> $page
• Pages -> $page -> $template

Publish area

• $section -> $entry

Extra buttons in the #context div

Sections -> $section

• View Entries: takes you to $section -> entries

$section -> entries

• Edit Configuration: takes you to Sections -> $section

$section -> $entry

• Edit Configuration: takes you to Sections -> $section

[eKoeS]

[Simone] Can developers decide which part of the main navigation they can append items to? (e.g. structure or content)

[Brendan] I think they can sit inside .structure without issue. The Navigation rendering logic is separate to the delegates so developers don't really have a choice other then what top level navigation item they will sit under.

The current implementation is: let the developer choose. This can be done by setting the type key of the navigation item array to either structure or content. If not present, it's structure by default. By the way, the code is as simple as an inline if/else statement, so it's not a big issue in my opinion.

[Simone] Can we get rid of AppendElementBelowView?

[Nils] As we will have a new Drawer plugin, I think the Documenter implementation is likely to change alongside Symphony 2.3 so I think we don't have to care too much about it now. I we do it right, there will the an official hook for the extension to populate a drawer in the sidebar.

Right, I didn't consider that!

[eKoeS]

[Simone] Can developers decide which part of the main navigation they can append items to? (e.g. structure or content)

[Brendan] I think they can sit inside .structure without issue. The Navigation rendering logic is separate to the delegates so developers don't really have a choice other then what top level navigation item they will sit under.

The current implementation is: let the developer choose. This can be done by setting the type key of the navigation item array to either structure or content. If not present, it's structure by default. By the way, the code is as simple as an inline if/else statement, so it's not a big issue in my opinion.

[Simone] Can we get rid of AppendElementBelowView?

[Nils] As we will have a new Drawer plugin, I think the Documenter implementation is likely to change alongside Symphony 2.3 so I think we don't have to care too much about it now. I we do it right, there will the an official hook for the extension to populate a drawer in the sidebar.

Right, I didn't consider that!

[eKoeS]

#817

[eKoeS]

#817

[brendo]

Big thanks to everyone for discussing this one at length and to @eKoeS for the implementation. Great stuff :)

[brendo]

Big thanks to everyone for discussing this one at length and to @eKoeS for the implementation. Great stuff :)

[nickdunn]

I would like to re-open this because I don't think we discussed, or implemented, anything to do with backwards compatibility. My list above mentions:

• extensions that look for an H2 to append things around it
• extensions that look for an H2 to append things to it (button and breadcrumb)

Are we saying that these are no longer compatible, and we should force these extensions to be updated for S2.3+, or should we try and make their existing markup work with the new styles?

[nickdunn]

I would like to re-open this because I don't think we discussed, or implemented, anything to do with backwards compatibility. My list above mentions:

• extensions that look for an H2 to append things around it
• extensions that look for an H2 to append things to it (button and breadcrumb)

Are we saying that these are no longer compatible, and we should force these extensions to be updated for S2.3+, or should we try and make their existing markup work with the new styles?

[brendo]

Are we saying that these are no longer compatible, and we should force these extensions to be updated for S2.3+, or should we try and make their existing markup work with the new styles?

I think given the list of extensions we should at least investigate what it'd take to support the existing markup, at least so it can be fully deprecated.

[brendo]

Are we saying that these are no longer compatible, and we should force these extensions to be updated for S2.3+, or should we try and make their existing markup work with the new styles?

I think given the list of extensions we should at least investigate what it'd take to support the existing markup, at least so it can be fully deprecated.

[eKoeS]

[OT] I just realized we didn't mention insertBreadcrumbs() in the last Developer Notes. Next episode? [/OT]

[eKoeS]

[OT] I just realized we didn't mention insertBreadcrumbs() in the last Developer Notes. Next episode? [/OT]

[brendo]

Definitely.

[brendo]

Definitely.

[eKoeS]

I'm not sure there's any safe/simple way to maintain markup backward compatible. Perhaps it's not worth the effort. Any ideas?

[eKoeS]

I'm not sure there's any safe/simple way to maintain markup backward compatible. Perhaps it's not worth the effort. Any ideas?

[nilshoerrmann]

Perhaps it's not worth the effort.

Exactly my feeling.

[nilshoerrmann]

Perhaps it's not worth the effort.

Exactly my feeling.

[designermonkey]

I was under the impression that 2.3 would be a 'breaking' release, especially in the eyes of extensions. That way, we can announce very early before release that it will break extensions that edit the UI, and those developers should upgrade the extensions using the beta releases.

We can then see who is and isn't actively maintaining extensions, and which ones should be pulled into Symphonists for future compatibility.

At least that was what I thought...

[designermonkey]

I was under the impression that 2.3 would be a 'breaking' release, especially in the eyes of extensions. That way, we can announce very early before release that it will break extensions that edit the UI, and those developers should upgrade the extensions using the beta releases.

We can then see who is and isn't actively maintaining extensions, and which ones should be pulled into Symphonists for future compatibility.

At least that was what I thought...

[brendo]

If it's not feasible to support both, then lets not.

We will need to show an example showing how to replicate the 2.2 behaviour in 2.3. This should then be added to the Migration Guide

[brendo]

If it's not feasible to support both, then lets not.

We will need to show an example showing how to replicate the 2.2 behaviour in 2.3. This should then be added to the Migration Guide

[nilshoerrmann]

Why don't we just add the new markup to the migration guide?

[nilshoerrmann]

Why don't we just add the new markup to the migration guide?

[eKoeS]

Why don't we just add the new markup to the migration guide?

Yes, it seems like the simplest thing to do.

[eKoeS]

Why don't we just add the new markup to the migration guide?

Yes, it seems like the simplest thing to do.

[eKoeS]

We will need to show an example showing how to replicate the 2.2 behaviour in 2.3. This should then be added to the Migration Guide

See #1016. I'm closing this issue again.

[eKoeS]

We will need to show an example showing how to replicate the 2.2 behaviour in 2.3. This should then be added to the Migration Guide

See #1016. I'm closing this issue again.