Many issues with File::exists() and folder::exist

Hi Nicolas,

Thank you for the detailed report and for taking the time to investigate the issue.

What you are experiencing is related to changes in the Joomla core between versions 5.3 and 5.4.

In Joomla 5.3, certain filesystem helper methods (including File::exists()) were temporarily removed/refactored, which caused this fatal error in Showtime 1.10.1 when running on that specific Joomla version.

In Joomla 5.4, these filesystem methods are available again, and the issue is fully resolved without any code changes.

So to clarify:

• Updating to Joomla 5.4 fixes the problem
• It is not a PHP issue (PHP 8.1 / 8.4 is fine)
• No manual file edits are required once Joomla is updated

After upgrading to Joomla 5.4, you should be able to run Showtime normally without any further action.

If anything persists after the upgrade, please let me know.

Best regards,
Lefteris

You’re absolutely right that using native PHP functions like is_dir() and is_file() is a perfectly valid (and future-proof) approach.

In the latest versions of Showtime, however, we are already using the new Joomla namespaces:

use Joomla\Filesystem\File;
use Joomla\Filesystem\Folder;

The exists() wrapper methods provided by Joomla are currently back in the core, work correctly in Joomla 5.4+, and are not marked as deprecated. Because of that, we can safely continue using them without compatibility issues.

That said, your suggestion makes sense from a defensive-coding point of view, especially considering the temporary regression in Joomla 5.3. I’ll keep this in mind for future refactoring so we can better guard against similar core changes.

Thanks again for the constructive feedback and for taking the time to share your workaround — it’s appreciated.

Best regards,
Lefteris

Thank you for bringing this up — that’s a very valid point, and I completely understand the frustration this can cause.

Currently, Showtime’s uninstall process performs a full cleanup (database tables and media folders). This is intentional and follows the default Joomla component behavior, ensuring that no orphaned data or files are left behind when a user explicitly uninstalls the extension.

That said, you are absolutely right that this can be problematic in troubleshooting scenarios, where the goal is to reset the extension code rather than permanently remove the content.

Your suggestions are very sensible:

• An option to keep data on uninstall
• A gallery export / backup package (database + files) for migration or safe reinstallation

Both are good ideas and align well with real-world usage. While Joomla does not natively provide an uninstall “keep data” prompt, this can be implemented at the extension level, and I agree it would be a valuable improvement.

I can’t promise an immediate change, but I’ll seriously consider adding:

• a “Preserve data on uninstall” option, and/or
• a backup/export tool inside the component for safe migration and recovery

In the meantime, for future reference, when the goal is to fix a technical issue, I strongly recommend disabling the component or reinstalling over the existing version, rather than uninstalling, to avoid data loss.

Thank you again for the constructive feedback — it’s exactly this kind of input that helps improve the extension in meaningful ways.

Best regards,
Lefteris