[4.0] Library installer runs manifest uninstall sql file when updating

[teflonmann]

Steps to reproduce the issue

Updating a library - as a single entity or as part of a package - whose library manifest.xml includes an uninstall-sql-markup. I used drag & drop file upload and install from a folder.

Example of a manifest xml for a library, that leads to the problem:

<?xml version="1.0" encoding="utf-8"?>
<extension version="3.0" type="library" method="upgrade">
	<name>lib_testlib</name>
	<libraryname>testlib</libraryname>
	<author>Foo</author>
	<creationDate>10.09.2020</creationDate>
	<copyright>Copyright (C) 2021 Foo Bar Inc.</copyright>
	<license>GNU General Public License version 2 or later</license>
	<version>1.0.0</version>
	<description>Testlib description</description>
	<files>
		<folder>sql</folder>
	</files>
	<install> <!-- Runs on install -->
	    <sql>
	      <file driver="mysql" charset="utf8">sql/install.mysql.utf8.sql</file>
	    </sql>
	</install>
	<uninstall> <!-- Runs on uninstall -->
	    <sql>
	      <file driver="mysql" charset="utf8">sql/uninstall.mysql.utf8.sql</file>
	    </sql>
  	</uninstall>
	<config />
</extension>

Expected result

The uninstall sql file content should not be executed at all when updating the library. Only when uninstalling it.

Actual result

The uninstall sql script is executed, and leads in our case to a "drop table" because the statement is written in there.

System information (as much as possible)

Joomla 4.0 RC 5

Additional comments

In Joomla 3.9.28 the update is not executing the uninstall sql file. What is correct. But the unintall sql script is not called when uninstalling the library either. This would become a different ticket I suppose.

[brianteeman]

This is an bug in the installer for libraries in all versions of Joomla. You can work around it by changing it to type=file. I dont know if it has ever been reported as a bug

<!--
A legitimate question among developers reading this file may be why we are using a "files" extension type instead of the
"library" type which, on the face of it, seems more appropriate.

We have not lost our mind. We are working around the adverse effects of the very different way Joomla treats "library"
packages than any other package type.

When applying an update to a library package Joomla! will uninstall it BEFORE it executes the installation script's
preflight event. This means that any checks made there to prevent the installation of the library in an incompatible
environment (e.g. wrong PHP or Joomla! version, or even preventing an accidental downgrade) results in the library files
being UNINSTALLED.

This is really bad for anyone who tries to install a library package on an unsupported environment. If the library
package runs no checks the installed library version causes the extensions that depend on it to crash, taking down the
site. If the library package runs checks in the earliest available point in time (preflight) you end up with the old
library files having been uninstalled which again causes the extensions that depend on it to crash, taking down the
site. No matter what you do, the very action of TRYING to install an unsupported library version KILLS THE SITE. This is
madness. Worse than that, this is a known issue in Joomla since ~2017 but nobody will fix it until a new major version.
Since this doesn't look likely in Joomla 4.0 we are talking about Joomla 5 which could be anywhere from two to ten years
into the future. Clearly this doesn't cut it for us: we don't want trying to install our software causing sites to stop
working!

The only thing we can do to prevent your sites from crashing to the ground if you try to install a version of our
software which does not support your PHP and/or Joomla! versions is to deliver our library as a *files* package. This
is nonsensical, it is 100% architecturally wrong BUT it is also the only way we can apply pre-installation checks which
fail gracefully instead of causing your site to crash and burn.
-->

[counterpoint]

Sadly, I don't find it funny. The mechanism used to upgrade libraries actually makes it near impossible to have an installation script at all. The problem being that the script is loaded twice, once for the uninstall and once for the install. Because it is loaded from different places, PHP doesn't recognise it as the same thing. Consequently there is a compile error because of the duplicate declaration of the installation script class. In the absence of almost any documentation, I'm not clear how a "file" extension is a viable alternative. Does any relevant documentation exist?

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35083.}