Fixing issue described in bug #33347, related to JTable (libraries/joomla/table/table.php)
The publish-function must take care for the field to use for its task. While today it is not only the 'published' field that holds a row's state, but also a field named 'state' (e.g. content-table), it must be taken care of which field to use. For that reason i added a first check for the field's general availability and a second check for the mentioned fields giving the most commonly use one - 'published' - priority. Also the query and value re-assignment were fixed to reference the field from the variable that holds the detected field name. This allows for more flexibility and less unchanged rows.
This is an interesting method. But i'm afraid i don't see how it would make my solution obsolete as in either way it is required to find out from the table which field holds the state value.
Maybe you can be more detailed? How do you see it involved compared to my solution?
Let's take the content table as an example because it already has a state field for holding the published value.
There is 1 file that we need to change for testing. This is the file libraries/legacy/table/content.php. First of all disable the publish() method by renaming it to publishX(). This we need to do to make sure the JTable::publish() is being used.
Second step is to tell JTable that the content table has a field called state and not published. This we do by adding this line into the constructor:
$this->setColumnAlias('published', 'state');
Now when you publish a content article the database query will look like this:
As you can see not the field published is set but the state field is set here. That is why I think this change is not needed.
Anyone using the state field rather than the published field will need to include the column alias in their table constructor, unless they override the publish method.
Ok, now i got it. That makes absolutely sense! I just wonder if we should consider developers are not aware of this method and wonder why publishing might fail. What do you think? Should we leave this issue completely to the developers or should we consider that and build kind of a combination of both the check for the correct state-field and involving the mentioned method?
@itbra I think we should keep the code as it is now. Rather than coding a fallback, developers should read the code and documentation. Clearly the documentation is missing so let's take an opportunity to document this feature:
@itbra I think this PR is not needed as we can set a column alias in JTable. See this method: https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/table/table.php#L1666
What do you think?