Change "protect" state of Plugin editors-xtd "Button - Article"

[pe7er]

with this update for existing Joomla installations using PostgreSQL

See issue: http://issues.joomla.org/tracker/joomla-cms/4875

[waader]

@Bakual How can I test this with current staging?

I failed doing it the following ways:

a) Fresh install of current staging including the new update file. Result: the plugin is still protected.

b) Fresh install of current staging. Afterwards I put the update file in the respective directory. In the Extension-Manager -> Database I see this line:
"Database schema version (None) does not match CMS version (3.4.0-2014-12-03)."

[Bakual]

If you click the "fix" button in the view, it should apply the SQL file and fix it. If not, it's a fail and something in the query is wrong.

[waader]

Thanks! That´s what I though should happen. Will have to find out later that week.

[sovainfo]

Wrong answer!

Extension manager->Database is not designed to Fix this. That is why you don't see the statement in the report. It only detects there is a later change not applied.
Haven't tried the statement, but suspect there is nothing wrong with it. It happens to be an UPDATE statement, which is a DML and not DDL statement. Only certain known DDL statements are considered for Fix.

You can apply the statement with phpPgAdmin to verify the statement itself. Don't think you need to test the update mechanism, we know that works. But if you want to, you need to start with j336 and update to 337 after having renamed the file to 3.3.7-2014-xx-xx.

You need to apply the PR that changes joomla.sql before you install to check whether installation will install it as unprotected.

[waader]

@sovainfo Thanks for your tip. I did the following:

• take the 3.3.6 installation files
• add pe7er´s sql update file
• switch to the test update channel and
• do the update
• look for the result

It did function for mysql, but not for postgresql. This is what was display on the database tab:
Table 'efp8m_associations' does not have column 'id' with type integer. (From file 3.0.3.sql.)
Table 'efp8m_contentitem_tag_map' does not have index 'efp8m_contentitem_tag_map_idx_tag_name'. (From file 3.1.0.sql.)
Table 'efp8m_updates' does not have column 'version' with type varchar. (From file 3.2.2-2014-01-18.sql.)
Table 'efp8m_user_profiles' does not have column 'profile_value' with type TEXT. (From file 3.3.4-2014-08-03.sql.)
Table 'efp8m_redirect_links' does not have column 'header'. (From file 3.4.0-2014-09-16.sql.)
Table 'efp8m_content' does not have column 'images' with type IS NOT NULL. (From file 3.4.0-2014-12-02.sql.)
Table 'efp8m_content' does not have column 'urls' with type IS NOT NULL. (From file 3.4.0-2014-12-02.sql.)
Table 'efp8m_content' does not have column 'attribs' with type IS NOT NULL. (From file 3.4.0-2014-12-02.sql.)
Table 'efp8m_content' does not have column 'metadata' with type IS NOT NULL. (From file 3.4.0-2014-12-02.sql.)

3.4.0-2014-12-03.sql was not in that list, but wasn´t applied. So I execute the update sql in phppgadmin and that worked. Probably the update mechanism is not very robust from the moment on it encounters a problem in on sql file.
Note: fix solves the problem for all but 2 entries we now from #5186

[sovainfo]

That is not what I suggested earlier. Obviously the update failed. And as I always ask on the forum: What does logs/joomla_update.php say?

[waader]

@sovainfo Thank you for pointing me to the log-file. I was not aware of the existence of such a file.

But as I wrote: the described procedure worked well with mysql.

The only deviation from your suggestion that I could see - maybe I have missread or missed something than please correct me - is that I renamed the file to 3.4.0-xxxx-xx-xx instead of 3.3.7.-xxxx-xx-xx. The reason for this is simple. When I turned the update channel to "testing" joomla made the update to 3.4.0-dev. And I didn´t know how to change that to 3.3.7.

I will repeat my test with progresql tomorrow and have a look into the log file.

[sovainfo]

Considering the amount of PR's related on PostgreSQL, I am not sure what would be the correct setup with 336.
The first couple of differences should not appear. They are alterations of versions before 336,

Don't like the update channel test because it is a moving target. Only suggested to update to 337 because that is a limited update, not introducing more issues than it fixes.

[waader]

I don´t know how to update from 3.3.6 to 3.3.7 and I am curious how to do that.

[sovainfo]

Looks like it is not possible anymore.