?
Referenced as Duplicate of: # 8739 # 9543
avatar photodude
photodude
15 Dec 2015

The Extensions→manage→Database "fix" has a fit if com_banners is removed.

Replication steps"
1. Remove com_banners from a Joomla install
2. check the database to insure that the #__banners_* tables are no longer in the database
3. Go to Extensions→manage→Database (see errors about Database table structure not up to date missing columns)
4. Press "Fix" (get more errors about missing table)

Expected results:
If com_banners (or any other decoupled extension) is no longer included in the joomla install, the database fix method shouldn't have a fit about missing columns and missing tables as these should be expected to be missing as they were removed (or never installed). The database should still be considered "up to date" if decoupled extensions are uninstalled or even never installed.

Votes

# of Users Experiencing Issue
1/1
Average Importance Score
3.00

avatar photodude photodude - open - 15 Dec 2015
avatar brianteeman
brianteeman - comment - 15 Dec 2015

I can confirm your findings but not your expected results
com_banners is not decoupled -

The only extension that has been decoupled is com_weblinks and based on the PLT roadmap the concept of decoupling extensions has been put on hold

avatar photodude
photodude - comment - 15 Dec 2015

Whether com_banners is, or even if it won't be decoupled, should we really expect "errors" when a non-protected core extension is removed? I don't think that is proper behavior.

avatar mbabker
mbabker - comment - 15 Dec 2015

As long as the core database schema is managed by raw SQL dumps and not a proper schema based API, the errors are going to exist. Either that or the class chain being used to accomplish this is going to have to start being able to parse SQL strings to match table names and start making decisions on how to act based on what parsing the string finds.

avatar brianteeman brianteeman - change - 16 Dec 2015
Labels Added: ?
avatar ChrisHoefliger
ChrisHoefliger - comment - 17 Dec 2015

File 3.0.0.sql wants to change the type of these tables to INNODB (ALTER TABLE #__banners ENGINE=InnoDB;). There is no (CREATE TABLE IF NOT EXISTS) check to find out whether these tables exist


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8691.

avatar photodude
photodude - comment - 17 Dec 2015

@ChrisHoefliger adding a CREATE TABLE IF NOT EXISTS to the raw SQL should resolve the errors, but if the extension was intentionally removed; do we really want to create a table that should no longer exist in the database?

avatar brianteeman
brianteeman - comment - 17 Dec 2015

It will come back on an update

On 17 December 2015 at 16:33, photodude notifications@github.com wrote:

@ChrisHoefliger https://github.com/ChrisHoefliger adding a CREATE TABLE
IF NOT EXISTS to the raw SQL should resolve the errors, but if the
extension was intentionally removed; do we really want to create a table
that should no longer exist in the database?


Reply to this email directly or view it on GitHub
#8691 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

avatar Bakual
Bakual - comment - 17 Dec 2015

@photodude That's exactly why we wanted to decouple the extensions initially. Currently, extension files will come back after an upgrade and you get exactly issues like that one mentioned here that some queries may fail if you uninstall a core extension.
Better just disable them instead of uninstalling.

"Create table if not exist" would solve that particular issue, but may introduce other issues in future if the table SQL isn't identical to the original one or when trying to reinstall the extension. Ideally, the query would only run if the table exists, doing nothing when it doesn't.

avatar mbabker
mbabker - comment - 17 Dec 2015

It will come back on an update

The extension's code will return, but the database won't get repopulated automagically.

Like I said, programmatically the issue ultimately boils down to using raw SQL dumps because there's only so much you can do for sanity checks in those. More of this schema processing should be done in a proper PHP API with full environmental awareness.

As for protected/unprotected extensions, right now unprotected extensions are basically things the CMS will function OK without installed whereas protected extensions if uninstalled cause catastrophic failure. That isn't a sign of something being decoupled.

avatar brianteeman
brianteeman - comment - 1 Feb 2016

While it is a value issue - is it even possible to fix it under the current architecture?

Setting to needs review - no point in keeping this open if nothing is going to happen


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8691.

avatar brianteeman brianteeman - change - 1 Feb 2016
Status New Needs Review
avatar sscotti
sscotti - comment - 17 Feb 2016

Similar Issues after uninstalling newsfeeds. Is there a way to reinstall that and fix the issue. Did not realize it was coupled.

Table 'sds_newsfeeds' should not have column 'filename'. (From file 3.0.0.sql.)
Table 'sds_newsfeeds' does not have column 'description'. (From file 3.0.0.sql.)
Table 'sds_newsfeeds' does not have column 'version'. (From file 3.0.0.sql.)
Table 'sds_newsfeeds' does not have column 'hits'. (From file 3.0.0.sql.)
Table 'sds_newsfeeds' does not have column 'images'. (From file 3.0.0.sql.)

avatar alex0703
alex0703 - comment - 22 Mar 2016

Similar Issues after uninstalling newsfeeds.

5 Database Problems Found:
Table 'vupm_newsfeeds' should not have column 'filename'. (From file 3.0.0.sql.)
Table 'vupm_newsfeeds' does not have column 'description'. (From file 3.0.0.sql.)
Table 'vupm_newsfeeds' does not have column 'version'. (From file 3.0.0.sql.)
Table 'vupm_newsfeeds' does not have column 'hits'. (From file 3.0.0.sql.)
Table 'vupm_newsfeeds' does not have column 'images'. (From file 3.0.0.sql.)

Is there a way to reinstall newsfeeds and fix the issue?

Joomla! 3.4.8 Stable [ Ember ] 24-December-2015 19:30 GMT

avatar photodude
photodude - comment - 26 Mar 2016

@sscotti @alex0703 if your comfortable with direct SQL edits, you could do as @mbabker suggested and put the table back, information in #9543

avatar brianteeman brianteeman - change - 5 Apr 2016
Category SQL
avatar eSilverStrike
eSilverStrike - comment - 12 Apr 2016

I was really surprised (the hard way) to see that these components are not decoupled from Joomla. Why allow them to be uninstalled in the first place then? If uninstalling these components create problems then the option to uninstall them should be disabled, at the VERY least there should be a message why you shouldn't uninstall them (and just disable them instead).

avatar chrisdavenport
chrisdavenport - comment - 7 May 2016

Uninstalling any core extension other than weblinks is not currently supported. A PR to prevent uninstallation would be considered. Decoupling
further core extensions is not simple, as we discovered with weblinks, but would be considered in the longer term. In the absence of either of those PRs, I'm closing this issue.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8691.

avatar joomla-cms-bot joomla-cms-bot - close - 7 May 2016
avatar joomla-cms-bot joomla-cms-bot - close - 7 May 2016
avatar chrisdavenport chrisdavenport - change - 7 May 2016
Status Needs Review Closed
Closed_Date 0000-00-00 00:00:00 2016-05-07 12:56:49
Closed_By chrisdavenport
avatar chrisdavenport
chrisdavenport - comment - 7 May 2016

Add a Comment

Login with GitHub to post a comment