I have tested this item successfully on 535436e

Thanks - I should have worked that fix out myself ;)

This PR has received new commits.

CC: @brianteeman

I have tested this item successfully on b059fb1

works as described.

I have tested this item successfully on b059fb1

@polakluk Once Travis is happy this can be made RTC

178 | ERROR | Whitespace found at end of line

travis is already happy

RTC - thanks - travis took a little while to update the issue tracker ;)

This PR has received new commits.

CC: @andrepereiradasilva, @brianteeman, @MATsxm

This PR has received new commits.

CC: @andrepereiradasilva, @brianteeman, @MATsxm

This PR has received new commits.

CC: @andrepereiradasilva, @brianteeman, @MATsxm

I added code that also fixes #9873 to this PR in order to keep it in one place

Now you added new methods ... and i think that means it will go only for 3.6.

I would prefer to keep them separated, this one was already tested and RTC... but, of course, it's your choice.

My intention was to keep merging process simple. Since these changes occur in the same file, it is easier to apply one PR to code base than having to merge 2 separate PR and keeping in mind their order (the second part of this PR reverts the change made in the first commit). I am sorry for committing the code after the original PR was already tested. If it causes more trouble than it fixes, then I can create a separate PR for this.

I didnt know that once new methods are added, the patch will be schedule for the next minor version. If that is indeed true, then I can change the comments

I didnt know that once new methods are added, the patch will be schedule for the next minor version. If that is indeed true, then I can change the comments

I'm not sure that it's how it works? is it? @brianteeman

This PR has received new commits.

CC: @andrepereiradasilva, @brianteeman, @MATsxm

@polakluk I have tested. The expected result is okay, but the create date and the last modify date are always GMT time. Check this, if you change the server time zone. You can this compare with the create date an modify date from article.

@polakluk I have the items trashed and the trash is empty. But the redirect function is still running! The database table is also empty. Is this a cookie problem?

@teccrow
I checked the first one and you're right. The fields always show GTM time, because that's how the time is stored (correctly) in DB. However, this seems to be a behavior that is consistent across all parts of Joomla admin (check Articles for example), so this may be intentional. I would like to hear second opinion on this.

As for your second comment. I am still testing it, because my local Joomla installation is wierdly acting out right now.

@rdeutz i think this one was merged by mistake, the latest big changes were not tested.

let's hope this does not introduces any issue. will test tomorrow.

ups, ok, would be great if you can test, we can revert it if test fail, thanks @andrepereiradasilva

Tested successfully. So it seems it was a good merge :)

@polakluk Correct, the is stored GMT in DB. But, if the Server Time (global Configuration) set for example on 'Berlin' than all Times show in Berlin Time. The form field 'created_date' and 'modify_date' are to be changed.
For example:

    <field 
        name="created_date"
        type="calendar"
        label=""
        description=""
        format="%Y-%m-%d %H:%M:%S"
        size="20"
        readonly="true"
        filter="user_utc" />

Important are the type and the filter!