THEN the modified date left unmodified (which is wrong).
Why? I would argue that changing a article's state is not modifying the article itself. That's why this is not a bug, at least for me.

In my opinion the article state and modified time are two different things. "Last modified" is about the article text itself. Unpublished and publish are for the state of the article, and when set an article on publish the article itself isn't modified.

Moving to Needs Review so a Maintainer / PLT can take the decision what is wrong or not. Thanks.

Then why when you change the status from inside (on edit) and save the article the modified date IS changed?
Definitely there is an inconsistency here.

In my opinion the correct action (no matter from where you change the status) is to update the modified date.
Let me stand my opinion with a real example on my custom component.

"I have created a complete REST based API wrapper on my component based on a controller that returns data in JSON format. One of the methods in the controller is called getModified(timestamp) that returns all modified records from a certain timestamp and beyond.
Unpublishing an article (or whatever record my/any component uses) will never "catch" the change. Imagine that you want to synchronize your joomla data with let's say a mobile app..."

Hope I make myself clear
Thanks in advance.

In this scenario when you change only status from inside (on edit) it should not change last modified date. This is some kind of inconsistency. It should be same for editing through list view or editing through edit layout.

Would be really nice to let administrators flag this on Options.
Thinking forward, this feature (updating the date on publish/un-publish) is of HIGH IMPORTANCE when dealing with REST API and you try to synchronize your data with external apps (say for example a mobile application)

Please think twice. Thank you in advance

We are hitting this issue.

I would prefer if the modified date was also a reflection of status changes, as well as content text changes.

Our use case is API related too, particularly related to generating "HTTP/1.1 304 Not Modified" responses for a set of articles.

The inconsistency is also a problem really. I noticed if you change an article's category from the view at /administrator/index.php?option=com_content&view=articles it updates the "modified" date, but if you update the status from that view, then it doesn't.

The last modified field is intended for users to know when something relevant to them has changed in the article. It is not intended for technical use in generating an API. There is an inconsistency between the different views which should be fixed. However, using the last modified field to generate an HTTP Last-Modified: header is not an appropriate use for that field. You might consider storing a separate field in a linked table for that purpose.

When considering a PR to fix the inconsistency, consideration should be given as to whether the last modified date should be changed when the article is trashed. If the article is subsequently un-trashed, should it retain the original last modified date, or the date it was trashed?

A PR specifically to fix the inconsistency issue would be welcome.

Changing the ordering also updates the modified_date, I think the easiest way to go is to modify the modified_date when an article data is save in whatever way. At some point it must be explained to a user and this should be easy to understand.

I can confirm in Joomla! 3.7.0-staging

I can confirm the problem on Joomla! 3.7.1-dev (nightly Build)

@AlexRed as this is still open then of course nothing has magically changed

Please stop trolling

Please @brianteeman can you tell the same rule also here: 15621#issuecomment-300410530

+1 for changing the modified date when status is changed.

In Content Versioning, the status and modified date change is recorded and compared if another field is modified.

For example, if the Finish Publishing date is changed, a new Item Version is created. Comparing the Item Version to the previous version shows Status as changed, as well as Modified Date.

Why is it important to change Modified Date when Finish Publishing is changed? Yet, when an article is immediately unpublished (or even trashed), it doesn't get recorded. Seems inconsistent at the least.

There are two different kinds of people who see the modification date and both have different needs. One is the Administration who should see that that someone changed the Metadata. The other is the visitor of the site, who wants to see when the information in the article was updated. If i go to wikipedia and see that an article was changed the day before, i would expect that the information are up with current events. So i would use two modified dates one for the backend user and one for the frontend user.

@icampus

Good point

As it relates to change tracking, a record generally only has one updated at or modified timestamp. It is an indicator of when the record (as a whole) was updated. You get into a very fuzzy and borderline confusing data model and UI if you try to implement two updated/modified trackers based on selective criteria (easiest example, I change something in the metadata fields, it's a frontend change but doesn't actually change the page content; which modification timestamp(s) are updated?).

I'm not saying that the arguments for either workflow (only change based on certain fields or always change) are invalid, in the end it all boils down to user preference. But ultimately, in the context of Joomla it should be consistent one way, and we need to decide what way that should be that way it can be explained to users and the underlying API behaviors updated to match that definition.

Status is set on "Needs Review".

I agree this should update the modified status. However I would say that the correct way to do this is to instead of building up a custom db query in publish method is to loop through load and call the store function in the publish method. https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Table/Table.php#L1568-L1636

That way components store logic will be called (which in our case will save the modified date). I would suggest just in case of any b/c minor issues doing this in the 4.x branch and accepting this behaviour in 3.x

@wilsonge Are there any scope on fixing this issue?

I confirm that the issue still exists

please test #38783

Reopen because PR #38783 has been closed.

The last modified field is intended for users to comprehend when something of interest to them has altered in the article. It is not intended for technical use in producing an API. There is a disparity between the various perspectives which should be rectified. However, capitalizing on the last modified field to make an HTTP Last-Modified: header is not a suitable usage for that field. You should think about stashing a separate field in a linked table for that intent.When evaluating a PR to correct the discrepancy, thought should be given to whether the last modified date should be amended when the article is discarded. Should the article be un-trashed subsequently, should it maintain the initial last modified date, or the time it was trashed?

A PR particularly addressing the inconsistency issue would be appreciated.

With regards to the 'last modified' field, this is intended for users to understand when relevant information has been changed in the article - not for technical use to create an API. Consequently, an inconsistency between views should be resolved. Utilizing the 'last modified' field to construct a HTTP Last-Modified: header is not suitable for this purpose. A different field in an associated table should be considered for that purpose.For the PR in order to resolve the inconsistency, thought should be given to whether the last modified date should be modified when the article is trashed. In the event the article is then unbanned, should the original last modified date be maintained, or the date it was trashed?

A PR purely to fix the inconsistency problem is appreciated.

The last modified field is meant for users to be aware of any alterations to the article that concern them. It is not intended for the development of an API. There is a difference in the views which should be corrected. The use of the last modified field to create an HTTP Last Modified: header is not suitable for the field. It might be a good idea to have a distinct field in an associated table for this purpose.When considering a PR to fix the inconsistency, it should be taken into account if the last modified date should be changed when the article is put in the trash. If the article is then un-trashed, should the original last modified date be kept or should it be the date it was trashed?

A PR specifically to resolve the inconsistency problem would be appreciated.

Whoa there, no reason to spam with identical comments.

@richard67 @Quy not sure if you're the right people to tag but those last three comments are spam, check out the hidden unrelated links.

This issue could only be solved without b/c break if we add two new fields into tables: state_modified and state_modified_by or with special flags - but all in combinqtion with database changes, changes in models and layouts.