The issue is that the edit form should be open in a modal according to the URL (&layout=modal&tmpl=component). But it opens in a new tab instead. At least for me.

However I get the "Version Note" field as well in the modal layout when following the edit link from the menuitem. So I can't confirm the missing field but I can confirm that it doesn't work as I would expect.

Yes the edit form opens in a new tab.
But i have no possibility in the new tab, to edit the item version history.
That is what i miss, and i must explain customers that its not possible to edit here.
They must got to the article manager. i think this is a missing function at this point.

sorry my fault i mean the button not the field

When you click on the versions button AND you have not yet made any edits to the article then the popup will not have any versions to show as there are no versions yet

If you edit the article and save it and then click on the versions button it will show the versions.

Can you confirm that please - that is the intended behaviour and is exactly the same as in the article manager

you are right in editing article in the content article manager.

But if you edit the article in the menu items, you doesn't have the button versions.

The display of an edit of the article from the Edit button in menu item was an unexpected new feature (but nice one) of the multilanguage associations edit associated article.

It was chosen at the time to display it in a new browser tab instead of a modal for good reasons:
we had problems displaying a modal over a modal when, for example, clicking on the Image or Article buttons at the bottom of the textearea. The modals were overlapping and all...

Thanks for the screenshot - from your description I thought you were
talking about front end editing.

I have to be honest and say that I never even saw that button before

On 29 January 2015 at 12:20, infograf768 notifications@github.com wrote:

The display of an edit of the article from the Edit button in menu item
was an unexpected new feature (but nice one) of the multilanguage
associations edit associated article.

It was chosen at the time to display it in a new browser tab instead of a
modal for good reasons:
we had problems displaying a modal over a modal when, for example,
clicking on the Image or Article buttons at the bottom of the textearea.
The modals were overlapping and all...

—
Reply to this email directly or view it on GitHub
#5919 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

I never saw it myself as well but JM already explained why

Imho, opening the modal layout in a new tab doesn't make much sense to me. The expected buttons are missing then.
Wouldn't it make more sense to open a full regular page in the new tab instead then? Or just redirect the current window to the edit form?
The current way sure is confusing.

@infograf768 Do you happen to remember the PR where this was introduced?

The advantage of a new tab is that you are redirected immediately to the original article from which you fetched the associated article after clicking on save and close or cancel. It took time to think and implement and I am not in favor of changing this friendly process.
It do not find this confusing at all personally.

I would suggest, instead, —if absolutely necessary...— to add the Versions button in the "fake modal" (tab).
As it is added as a JToolbar specific call in the view.html.php for the "normal" Edit:

if ($this->state->params->get('save_history', 0) && $canDo->get('core.edit'))
            {
                JToolbarHelper::versions('com_content.article', $this->item->id);
            }

I did not find the way to add it in the tab display where we use for the buttons:

<div class="pull-right">
    <button class="btn btn-primary" type="button" onclick="Joomla.submitbutton('article.apply');"><?php echo JText::_('JTOOLBAR_APPLY') ?></button>
    <button class="btn btn-primary" type="button" onclick="Joomla.submitbutton('article.save');"><?php echo JText::_('JTOOLBAR_SAVE') ?></button>
    <button class="btn" type="button" onclick="Joomla.submitbutton('article.cancel');"><?php echo JText::_('JCANCEL') ?></button>
</div>

It is only not confusing for you because you were part of the original proposal.
It sure is confusing for anyone else.

What was the reason to not just create a new tab with a regular edit form (without &template=component&layout=modal)? We don't need a special redirect at all. The page where the user came from is still there in the other tab, going back to it is no problem at all and every user knows how tabs work.

Looks like we disagree.

It sounds like you are "disagreeing" not about it being a new tab but about
it being a new tab with limited options (fake modal) because of the desire
for it to be closed automatically on save - is that correct?

For the sake of not losing expected functionality (as reported by the OP)
it would make sense to just have a regular new tab.
We have this behaviour elsewhere in Joomla already with the "old" front end
module editing and the "current" front end menu editing. Both of those open
a new tab with a complete admin instance and when saved the tab does not
automatically close. So it is actually not consistent, and unexpected,
behaviour in the UI that this feature currently works the way it does.

Would it be better if it we could have a "fake modal" tab that
automatically closes on save - yes - but if that means, as it currently
does, a loss of expected functionality then no. And creating a different
layout of the screen and button positions really isnt a solution either as
that is also not consistent andhas potential issues with maintainability.

On 31 January 2015 at 10:27, infograf768 notifications@github.com wrote:

Looks like we disagree.

—
Reply to this email directly or view it on GitHub
#5919 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

...

It sounds like you are "disagreeing" not about it being a new tab but about it being a new tab with limited options (fake modal)

Indeed.
I don't see a reason to load a modal layout with limited options (&layout=modal) and removing the menu and modules (&template=component) when you load the page in a full browser window anyway.
I agree it being loaded in a new tab. It most likely would not be fun to edit an article in a modal, and you don't want to get redirected from a menu item form or another modal. So opening in a new tab is perfectly fine for me.

I just wonder what the reason was to load it as a modal. And which PR that was so I could read the discussion back then. Unfortunately I didn't found it yet.

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31190&start=0

July 2013.... almost 2 years ago. Nobody ever complained.

Sadly Joomlacode doesnt open
On 31 Jan 2015 17:27, "infograf768" notifications@github.com wrote:

http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31190&start=0

—
Reply to this email directly or view it on GitHub
#5919 (comment).

For reference: Actual PR which was implemented was #1412.
As for nobody ever complained: I cite from JoomlaCode (Marc Studer):

2) the ergonmy of a modal window in a non-modal context is not very suitable (button on the top-right, no admin header).

You told him it's by design and that's it.

From what I understand the reason is that on "Saving and Close" (and probably "Cancel") the window would close automatically.
That could actually be achieved also with a regular window without any problems. It's just a few lines of JavaScript in the Joomla.submitbutton function. One could for example add those lines dynamically in the regular edit form based on an URL parameter you pass. Like "&autoclose=1" or something.
If it's indeed needed. Imho it's not really needed and bad practice but that's surely a subjective statement. I hate pages which autoclose. After all I have to confirm the closing anyway, thus don't even save a single click

Hi @asysta! You created this issue sometime ago but have not provided any code for people to evaluate. As no one else has shown any interest in providing the code and you have not then I am closing this issue at this time. If code is provided (a pull request) it can always be re-examined.