You mean existing Articles get a wrong Category or new Articles?

I tested on existing Articles (created before the Menu "Create Article" for a specific Category), no Category was changed.

System information

3.7.3-dev (latest nightly build)
Multilanguage Site
macOS Sierra, 10.12.5
Firefox 53 (64-bit)

MAMP 4.1.1

• PHP 7.0.15
• MySQLi 5.6.35

Existing articles

I can give you a screen capture of this bug of you'd like toch demonstrate the behaviour

"Franz Wohlkönig" notifications@github.com schreef op 10 juni 2017 21:18:09 CEST:

You mean existing Articles get a wrong Category or new Articles?

I tested on existing Articles (created before the Menu "Create Article"
for a specific Category), no Category was changed.

--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#16612 (comment)

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

No Screencapture necessary, it's about: Is it a Core-Bug or is it caused by another Reason. On a clean 3.7 i can't confirm. Have you asked in the forums?

I have not tested,
but i have taken a quick look at the model code (look at preprocess),

it does not check if article is new or an existing one

thus (i am guessing here),
when it happens (because of routing) that the currently selected -active- menu item is the submit menu item,
then you could get this issue,
It seems easy to fix (i can make a PR)

@markjansennl

Can you check the URL that you have during editing the article

Does the menu alias of the "Create article" menu item appear in the URL ?

@franz-wohlkoenig
can you add &Itemid=NNN
to your edit URL ?

to replicate the "Create article" menu item being selected

@ggppdk i add Menu-Item-Id to edit-Url and save Article > no Change of Category (Article-Category was a different one then from Menu).

@franz-wohlkoenig
when you added
&Itemid=NNN (NNN of create article menu item) was the "Create" menu item shown as active ?

"Create Article"-Menu isn't shown as active. I append &Itemid=Nr-of-Menu on different Positions of Url.

Sounds the same as #12687

@Bakual

yes exactly it seems to be of same reason,
remebering that issue i looked to find similar effect and i made the above comment

This my comment on that issue
#12687 (comment)

why the parameters of active menu should be merged and used in a view,
even when the view is of different type ?

e.g. this case it is edit article but the menu item is for creating article

The view is the same for both new and edit, and the router only checks the view. The bug is that the router should distinguish between "new" and "edit" (check additionally if the id/a_id has a value or is 0). The menuitem for creating an article isn't a good match for editing an article.

@Bakual

that is another approach to the issue,
i had tried that and abandon it becausing it was getting a little complex and too restrictive

e.g. in the end , you may end up disallowing usage of e.g. menu item parent category for children categories, so that to prevent menu parameters from taking effect

to me it sounds like we will may start adding too complex limitations to the router

but just for this particular case i will agree with you
It is good to put this change into the router !
Selecting create menu item for editing articles is anyway wrong !

e.g. in the end , you may end up disallowing usage of e.g. menu item parent category for children categories, so that to prevent menu parameters from taking effect

You only have to check the id for the menutype "create article" (&view=article&a_id=0). If the URL isn't an exact match to that, then that Itemid isn't appropriate and another one has to be found. It should not have an effect on any other menuitems.

@Bakual , you are right, this is a clear case of wrong selection of menu item, but there can be other cases where menu item is desirable in the Sef url but using its menu parameters are not, and in our extension we have several such cases, current policy of not checking if current menu is appropriate for using its parameters leads to new bugs as new features are added. It is not safe to make assumption that current menu item is always usable. And i dont mean this particular case, i say in general for various view

I'm not sure if I understand all of the above correctly.

First some details:

• the menu item to add content has this URL: https://www.jubalvarsseveld.nl/ledendeel/mededeling-agendamail-toevoegen.html
• the fixed category this front-end edit is set is called 'mededelingen'
• I have another menu item to add content without a fixed category, which has the URL: https://www.jubalvarsseveld.nl/ledendeel/nieuws-of-ander-artikel-toevoegen.html

If I click the edit button in the front-end, the URL is like this: https://www.jubalvarsseveld.nl/ledendeel/mededeling-agendamail-toevoegen.html?view=form&a_id=1207&return=aHR0cHM6******

So for some reason, any front-edit edit gets redirected to the menu-item with the fixed category.

Should I change any of the names of the menus?

Some background: The router determines which menu item is "best match" when a given link is generated. In your case it sees that you want to build a link for the article form. Now it looks in the available menuitems and finds two entries which are for the article form. The router now just takes the first one (should be the one with the lower ID).

For you, you could actually delete the "mededeling-agendamail-toevoegen" and recreate it so it gets a higher ID. Then it likely will work for you.

But the source of the problem is that the router takes that menuitem which is for a NEW article and applies it to EDIT an article. Which just isn't the same thing.

Recreating the menu (including clearing the cache) didn't make any difference (I simply saved a copy of the current menu item, deleted the old one, cleared the recycle bin and renamed the new to the old).

Changing the order of the menu which contains both edit forms (one with the fixed category, one with the flexible category) however did help. I moved the item with the flexible category above the one with the fixed category. Currently when I click the edit button, I get redirected to a URL which contains the link to the flexible edit screen (e.g. https://www.jubalvarsseveld.nl/ledendeel/nieuws-of-ander-artikel-toevoegen.html?view=form&a_id=473&return=aHR0**********).

Many thanks!

(though I still believe this to be a bug)

Ah then it is based on the order, not the ID ?

This to me seems like a bug. You shouldn't have to adjust the menu item order to 'fix' the issue.

If a user is able to edit articles in a specific category, when they are editing an article, the article should NEVER be 'switched' into another category.

When will this be fixed?

Other users are experiencing the same issues:
https://forum.joomla.org/viewtopic.php?f=706&t=950209&p=3479231#p3479231

thanks,
Laura

When will this be fixed?

When someone has created a PR and the PR has two successful tests. Then it will be merged into the next release.

Robert,
Thanks for your quick response!
-- Laura

Following, because of the same issue.

Yes same issue here!
I fixed it by adding a new article menu-item without fixed categorie above the one with the fixed category.
Then if you do not want to show that to the customer you can use css on that item with display:none :-D

Its not a bug fix but a work-around so the customer can go on without the problem.

This workaround doesn´t work here unfortunately... :/

1. Create a menu item that is new article restricted to a specific category
2. Make sure there are no other menu items that create a new article that
   are not restricted.
3. Go into an article on the front end not in that category m, edit i4.
   After the save notice that the article is now in that ormther category.

On Jun 15, 2017 7:02 AM, "Thomas Hunziker" notifications@github.com wrote:

I tried to reproduce it in current beta, but apparently missed something.
I can reproduce taking the wrong menuitem and thus making the category
readonly. But it didn't change the category in my case, I just wasn't able
to select a different one.

So if someone can provide exact steps to reproduce the category changing
issue on a clean 3.7.3 beta, I would appreciate that.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#16612 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARCLYAOQ5nNnQ8TAEzozh2k19ieUH2xdks5sEQ85gaJpZM4N2HPb
.

@rytechsites Can you try this on a Joomla 3.7.3 Beta site? You could download the beta here: https://github.com/joomla/joomla-cms/releases/tag/3.7.3-beta1

Because I can't reproduce it with the beta. So maybe something changed which fixed that.
The URL I get in the edit view is http://localhost/joomla/index.php/create-article?view=form&a_id=10&catid=8&return=aHR0cDovL2xvY2FsaG9zdC9qb29tbGEvaW5kZXgucGhwL2ZlYXR1cmVk

As you see it takes the "create-article" menuitem, which by itself is a bug and it forces the category to be readonly. But since it also has the "&catid=8" parameter in it, the category is set to the correct category and doesn't change after saving.

@Bakual i just tested with the nightly build 3.7.3-dev and the issue is still there. Maybe we can meet for a screensharing?

I'm at work, screensharing will likely not work with out Firewalls.
But another thought comes to mind: Are you using some custom ACL settings or the default ones (I think I tested with default "Publisher" group)? Because I could imagine an issue if the user doesn't have the permission to create items in said category. There was a change related to ACL and categoryselect. I'd have to check that but would be great to know if that could be the cause.

It was a special group, yes - i switched it to "Special" and tested with "Super User" now - same issue.

In another news the Nightly build broke my Home Item and the Menus :-D i´ll investigate in this too...

It would be great if someone can reproduce it on a clean Joomla (3.7.3 beta) installation then, and give exact steps to reproduce it. I'm out of ideas now and apparently miss a setting or something.

Hi @Bakual installed clean 3.7.3 beta.

• Cant´reproduce with protostar
  BUT
• Can reproduce the issue with the customer template on a clean beta

I see the customer template has an override of the form » edit.php file - by deactivating it the issue is gone - so there might be a change in this file that causes a "B/C break" ?

There were several changes to that file, but nothing jumps out regarding category except #14094, but that one should create such issues.
The rest is related to com_fields and the new calendar and some codestyle stuff.

Would be interesting to see that override. Maybe I can figure out something from it.

Thanks to the override file from @coolcat-creations I found the culprit for this specific issue.
With #8521 we removed a duplicated hidden catid field from the core layout. If the overrides are based on a core version before 3.6.0 and never updated afterwards, then that line is still present and will override the catid from the article with the one set in the menuitem.

Deleting that line in your override will solve this specific issue of the category magically changing.
It would be great if that could be confirmed.

Now to the question why it worked before 3.7.0. That is now exactly the issue with the router taking an inappropriate menu item and applying the menu params from the "Create Article" menutype to the "Edit Article" view. That changed to my knowledge with 3.7.0.

Thank you @Bakual for your top-investigator work. I confirm that deleting that line solved the issue

<?php if ($this->params->get('enable_category', 0) == 1) :?>
	<input type="hidden" name="jform[catid]" value="<?php echo $this->params->get('catid', 1); ?>" />
<?php endif; ?>

Can you test #16756 ?
That should fix the issue even with those lines present in the override.

Closing as there is a PR

I understand this is closed, but will it be fixed in the next release of
joomla?

I do not want to create any overrides to give a bandaid to fix.

Thanks
Laura

On Jun 18, 2017 5:39 PM, "Thomas Hunziker" notifications@github.com wrote:

Can you test #16756 #16756 ?
That should fix the issue even with those lines present in the override.

Closing as there is a PR

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16612 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARCLYGINbxUFRzwAaY-dicbuytinPeXsks5sFZj_gaJpZM4N2HPb
.

If the referenced PR gets tested in time, there is a chance it could be included into 3.7.3. However since 3.7.3 is supposed to be released next week, there is no promise it will be included.

Thank you.