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.
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.
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.
Labels |
Added:
?
|
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
@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?
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/
@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.
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.
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
Status | New | ⇒ | Needs Review |
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.)
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
Category | ⇒ | SQL |
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).
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.
Status | Needs Review | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-05-07 12:56:49 |
Closed_By | ⇒ | chrisdavenport |
Set to "closed" on behalf of @chrisdavenport by The JTracker Application at issues.joomla.org/joomla-cms/8691
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