FoF Upload Installation Perfect but Cannot Be Activated - Complete Analysis

Forogramero

Hi, it's me again. Hope everything goes well.

Problem Summary

FoF Upload appears to be perfectly installed but cannot be activated in the Admin panel, and when manually enabled via database, it shows "File type not allowed" errors.

_Technical Environment
Flarum Version: 1.8.4

FoF Upload Version: 1.8.4

Hosting: Hostinger Shared Hosting

PHP: 8.1+

Structure: Mixed public_html with assets in root_

What WORKS ✅

# Images are physically stored and accessible
ls -la assets/files/
# Output: Directories with dated images

# URLs are accessible via direct links
curl -I https://fictograma.com/assets/files/2025-10-20/1760963059-432467-ai-generated-8891427-960-720.jpg
# HTTP/2 200 - Image loads perfectly

# External image links work in Flarum Discussion Cards
![alt](https://external-image.com/image.jpg)

What DOESN'T WORK ❌
❌ FoF Upload cannot be activated in Admin panel

❌ When manually enabled via DB, shows "No se permite subir archivos de este tipo"

❌ FoF User Bio profile images don't display

❌ Any feature depending on FoF Upload fails

Complete Diagnostic Results

Installation Verification
composer show fof/upload

Output: Perfect installation, all dependencies met, version 1.8.4

File Structure Verification
ls vendor/fof/upload/src/ | head -10

Output:

Access
Adapters
Api
Commands
Console
Contracts
Data
Downloader
Download.php
Events

Autoloader Status
ls -la vendor/autoload.php

Output: -rw-r--r-- 1 user group 748 Oct 28 23:51 vendor/autoload.php

Database Configuration

-- Manual activation attempted
UPDATE fg_settings SET value = '["...","fof-upload"]' WHERE `key` = 'extensions_enabled';

The Core Problem

Despite perfect technical installation, FoF Upload has fundamental compatibility issues with this specific server configuration. The extension loads but cannot initialize properly.

Attempted Solutions (All Failed)
✅ Complete reinstall (composer remove fof/upload && composer require fof/upload)

✅ Database cleanup (removed all fof-upload.% settings)

✅ Cache clearing (rm -rf storage/cache/*)

✅ Autoload regeneration (composer dump-autoload --optimize)

✅ Permission fixes (chmod 755 storage/private-shared/files)

✅ MIME type configuration variations

Workaround Solution
Using external image hosting services:

Users upload to Imgur, PostImage, etc.

Paste direct links in posts

Flarum Discussion Cards works perfectly with external image links

Less technical overhead

Questions for Flarum Community
Has anyone experienced similar FoF Upload activation issues on Hostinger?

Are there known compatibility issues with mixed directory structures?

Any alternative upload extensions that work where FoF Upload fails?

How to debug why an extension installs but won't activate?

Current Status
The forum functions perfectly except for native file uploads. External image links provide adequate functionality with Flarum Discussion Cards working as expected.

Server Directory Structure Terminology:

public_html]$ ls
assets         config.php   extend.php  LICENSE      site.php        votar_php
CHANGELOG.md   cookies.txt  extensions  public       sitio_original  web.config
composer.json  default.php  flarum      README.md    storage
composer.lock  error_log    index.php   sitemap.xml  vendor

-------- cd public
-bash: cd: public: No such file or directory
[u148719152@fr-int-web1904 vendor]$ ls
afrux            dragonmantank  ianm            middlewares      serakoi
archlinux-de     ecnu-im        illuminate      migratetoflarum  softcreatr
askvortsov       egulias        intervention    mobiledetect     staudenmeir
autoload.php     enshrined      isaced          monolog          swiftmailer
axy              fgribreau      jaybizzle       nearata          sycho
bin              fig            jenssegers      neoncube         symfony
brick            filp           justoverclock   nesbot           tecnickcom
capybash         firebase       laminas         nette            tijsverkoyen
carbonphp        flamarkt       laravel         nikic            v17development
clarkwinkelmann  flarum         league          opis             voku
components       flarum-lang    litalino        psr              walsgit
composer         fof            maicol07        pusher           webmozart
datlechin        franzl         malago          ralouphie        wikimedia
dflydev          guzzlehttp     matthiasmullie  ramsey
doctrine         huseyinfiliz   michaelbelgium  s9e
[u148719152@fr-int-web1904 vendor]$ cd ..
[u148719152@fr-int-web1904 public_html]$ cd public
[u148719152@fr-int-web1904 public]$ ls
assets
[u148719152@fr-int-web1904 public]$ cd assets
[u148719152@fr-int-web1904 assets]$ ls
admin.css        admin.js.map  forum.css        forum.js.map
admin-dark.css   avatars       forum-dark.css   rev-manifest.json
admin-es.js      covers        forum-es.js
admin-es.js.map  files         forum-es.js.map
admin.js         fonts         forum.js

Migration Background
Before Migration:

✅ Subdomain: forograma.fictograma.com with FoF Upload WORKING

✅ Location: /home/u148719152/domains/fictograma.com/public_html/forograma/

✅ FoF Upload: Fully functional on subdomain

After Migration:

✅ New Domain: fictograma.com (main domain)

❌ FoF Upload: Stopped working immediately after migration

✅ Other Features: All other Flarum functions work perfectly

Migration Process Used

 1. Copied Flarum files from subdomain to main domain
cp -r forograma/public/* ./
cp -r forograma/vendor ./
cp -r forograma/storage ./

 2. Updated config.php
'url' => 'https://fictograma.com',

 3. Created .htaccess in old subdomain to redirect
echo "RewriteEngine On" > forograma/.htaccess
echo "RewriteRule ^(.*)$ https://fictograma.com/\$1 [R=301,L]" >> forograma/.htaccess

The Critical Clue
FoF Upload worked perfectly on the subdomain but broke immediately when moved to the main domain, suggesting:

Path-related issues in FoF Upload configuration

Database references still pointing to old subdomain paths

Cached configuration from the subdomain installation

Permission inheritance problems during migration

Additional Diagnostic Info
The mixed directory structure (some files in root, some in public/) might be a result of the migration process rather than the original installation method.

Current Theory
The migration from subdomain to main domain created path resolution conflicts that FoF Upload cannot handle, while other Flarum components adapted successfully.

The problem is likely in FoF Upload's path handling during domain changes, not in the basic installation or server configuration.

clarkwinkelmann

Forogramero are there any error messages in Flarum's or PHP's log files?

If you enable debug mode in config.php then try to enable the extension, there should definitely be an error message.

Forogramero

clarkwinkelmann I'll give you an update very soon.

Forogramero

clarkwinkelmann

Update.

Problem Summary and How we solved it

After migrating from subdomain to main domain, FoF Upload and features like image profile and cover phpto stopped working completely while all other Flarum functions worked perfectly. The issue was misunderstanding Flarum's directory structure requirements.

The Directory Structure Myth We Discovered ---I'm hosting in Hostinger.com---

Myth: "Flarum must run from public_html/public/"
Reality: Flarum can run from ANY directory as long as paths are correctly configured

Our Final Working Structure

public_html/ # ← Document Root
├── index.php # ← Flarum entry point
├── assets/ # ← Web-accessible assets
├── config.php # ← Flarum configuration
├── extend.php # ← Extensions file
├── vendor/ # ← Composer dependencies
├── storage/ # ← Flarum storage
└── public/ # ← ❌ UNUSED/EMPTY directory (by default: assets/covers/avatars/ etc...
Configuration Files That Made It Work

config.php

php
<?php
return array(
    // Activar debug para desarrollo (cambia a false en producción)
    'debug' => false,  // ✅ Cambiar a true para ver errores

    // Configuración de la base de datos
    'database' => array(
        'driver' => 'mysql',
        'host' => 'localhost',
        'port' => 3306,
        'database' => 'u148719-----------a',
        'username' => 'u148719152_f------------0',
        'password' => '-------------',
        'charset' => 'utf8mb4',
        'collation' => 'utf8mb4_unicode_ci',
        'prefix' => 'fg_',
        'strict' => false,
        'engine' => 'InnoDB',
        'prefix_indexes' => true,
    ),

    // URL base del foro - ✅ CORRECTA
    'url' => 'https://fictograma.com',
    
    // ✅ CONFIGURACIÓN DEL TÍTULO DEL FORO PARA CORREOS
    'forum_title' => 'Fictograma',

    // Rutas internas
    'paths' => array(
        'api' => 'api',
        'admin' => 'admin',
    ),

    // Cabeceras HTTP
    'headers' => array(
        'poweredByHeader' => true,
        'referrerPolicy' => 'same-origin',
    ),

    // ✅ CONFIGURACIÓN DE CORREO CORREGIDA - SMTP REAL
    'mail' => array(
        'driver' => 'smtp',  // ✅ Cambiado de 'array' a 'smtp'
        'host' => 's---------il.com',
        'port' => 5----
        'from' => array(
            'address' => 'fi---------il.com',  // ✅ Email real de Gmail
            'name' => 'For--------SMTP',
        ),
        'encryption' => 'tls',  // ✅ Agregado
        'username' => 'f----------gmail.com',  // ✅ Agregado
        'password' => ---------------',  // ✅ Agregado
    ),
);

site.php (Key to understanding Flarum paths)

<?php

use Flarum\Foundation\Site;

require __DIR__.'/vendor/autoload.php';

return Site::fromPaths([
    'base' => __DIR__,
    'public' => __DIR__, // 
    'storage' => __DIR__.'/storage',
])->extendWith(require __DIR__.'/extend.php');

index.php (in root - not in /public/)

<?php

/*
 * This file is part of Flarum.
 *
 * For detailed copyright and license information, please view the
 * LICENSE file that was distributed with this source code.
 */

$site = require __DIR__.'/site.php';

/*
|-------------------------------------------------------------------------------
| Accept incoming HTTP requests
|-------------------------------------------------------------------------------
|
| Every HTTP request pointed to the web server that cannot be served by simply
| responding with one of the files in the "public" directory will be sent to
| this file. Now is the time to boot up Flarum's internal HTTP server, which
| will try its best to interpret the request and return the appropriate
| response, which could be a JSON document (for API responses) or a lot of HTML.
|
*/

$server = new Flarum\Http\Server($site);
$server->listen();

.htaccess (Standard Flarum - works in root)

<IfModule mod_rewrite.c>
  RewriteEngine on

  # Ensure the Authorization HTTP header is available to PHP
  RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

  # Uncomment the following lines if you are not using a `public` directory
  # to prevent sensitive resources from being exposed.
  # <!-- BEGIN EXPOSED RESOURCES PROTECTION -->
  # RewriteRule /\.git / [F,L]
  # RewriteRule ^auth\.json$ / [F,L]
  # RewriteRule ^composer\.(lock|json)$ / [F,L]
  # RewriteRule ^config.php$ / [F,L]
  # RewriteRule ^flarum$ / [F,L]
  # RewriteRule ^storage/(.*)?$ / [F,L]
  # RewriteRule ^vendor/(.*)?$ / [F,L]
  # <!-- END EXPOSED RESOURCES PROTECTION -->

  # Pass requests that don't refer directly to files in the filesystem to index.php
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^ index.php [QSA,L]
</IfModule>

# Disable directory listings
Options -Indexes

# MultiViews can mess up our rewriting scheme
Options -MultiViews

# The following directives are based on best practices from H5BP Apache Server Configs
# https://github.com/h5bp/server-configs-apache

# Expire rules for static content
<IfModule mod_expires.c>
  ExpiresActive on
  ExpiresDefault                                      "access plus 1 month"
  ExpiresByType text/css                              "access plus 1 year"
  ExpiresByType application/atom+xml                  "access plus 1 hour"
  ExpiresByType application/rdf+xml                   "access plus 1 hour"
  ExpiresByType application/rss+xml                   "access plus 1 hour"
  ExpiresByType application/json                      "access plus 0 seconds"
  ExpiresByType application/ld+json                   "access plus 0 seconds"
  ExpiresByType application/schema+json               "access plus 0 seconds"
  ExpiresByType application/vnd.geo+json              "access plus 0 seconds"
  ExpiresByType application/vnd.api+json              "access plus 0 seconds"
  ExpiresByType application/xml                       "access plus 0 seconds"
  ExpiresByType text/calendar                         "access plus 0 seconds"
  ExpiresByType text/xml                              "access plus 0 seconds"
  ExpiresByType image/vnd.microsoft.icon              "access plus 1 week"
  ExpiresByType image/x-icon                          "access plus 1 week"
  ExpiresByType text/html                             "access plus 0 seconds"
  ExpiresByType application/javascript                "access plus 1 year"
  ExpiresByType application/x-javascript              "access plus 1 year"
  ExpiresByType text/javascript                       "access plus 1 year"
  ExpiresByType application/manifest+json             "access plus 1 week"
  ExpiresByType application/x-web-app-manifest+json   "access plus 0 seconds"
  ExpiresByType text/cache-manifest                   "access plus 0 seconds"
  ExpiresByType text/markdown                         "access plus 0 seconds"
  ExpiresByType audio/ogg                             "access plus 1 month"
  ExpiresByType image/bmp                             "access plus 1 month"
  ExpiresByType image/gif                             "access plus 1 month"
  ExpiresByType image/jpeg                            "access plus 1 month"
  ExpiresByType image/png                             "access plus 1 month"
  ExpiresByType image/svg+xml                         "access plus 1 month"
  ExpiresByType image/webp                            "access plus 1 month"
  ExpiresByType video/mp4                             "access plus 1 month"
  ExpiresByType video/ogg                             "access plus 1 month"
  ExpiresByType video/webm                            "access plus 1 month"
  ExpiresByType application/wasm                      "access plus 1 year"
  ExpiresByType font/collection                       "access plus 1 month"
  ExpiresByType application/vnd.ms-fontobject         "access plus 1 month"
  ExpiresByType font/eot                              "access plus 1 month"
  ExpiresByType font/opentype                         "access plus 1 month"
  ExpiresByType font/otf                              "access plus 1 month"
  ExpiresByType application/x-font-ttf                "access plus 1 month"
  ExpiresByType font/ttf                              "access plus 1 month"
  ExpiresByType application/font-woff                 "access plus 1 month"
  ExpiresByType application/x-font-woff               "access plus 1 month"
  ExpiresByType font/woff                             "access plus 1 month"
  ExpiresByType application/font-woff2                "access plus 1 month"
  ExpiresByType font/woff2                            "access plus 1 month"
  ExpiresByType text/x-cross-domain-policy            "access plus 1 week"
</IfModule>

# Gzip compression
<IfModule mod_deflate.c>
  <IfModule mod_filter.c>
    AddOutputFilterByType DEFLATE "application/atom+xml" \
                                  "application/javascript" \
                                  "application/json" \
                                  "application/ld+json" \
                                  "application/manifest+json" \
                                  "application/rdf+xml" \
                                  "application/rss+xml" \
                                  "application/schema+json" \
                                  "application/vnd.geo+json" \
                                  "application/vnd.ms-fontobject" \
                                  "application/wasm" \
                                  "application/x-font-ttf" \
                                  "application/x-javascript" \
                                  "application/x-web-app-manifest+json" \
                                  "application/xhtml+xml" \
                                  "application/xml" \
                                  "font/collection" \
                                  "font/eot" \
                                  "font/opentype" \
                                  "font/otf" \
                                  "font/ttf" \
                                  "image/bmp" \
                                  "image/svg+xml" \
                                  "image/vnd.microsoft.icon" \
                                  "image/x-icon" \
                                  "text/cache-manifest" \
                                  "text/calendar" \
                                  "text/css" \
                                  "text/html" \
                                  "text/javascript" \
                                  "text/plain" \
                                  "text/markdown" \
                                  "text/vcard" \
                                  "text/vnd.rim.location.xloc" \
                                  "text/vtt" \
                                  "text/x-component" \
                                  "text/x-cross-domain-policy" \
                                  "text/xml"
    </IfModule>
</IfModule>

# Fix for https://httpoxy.org vulnerability
<IfModule mod_headers.c>
  RequestHeader unset Proxy
</IfModule>

The Critical Discovery: Asset Path Problem

What WASN'T Working:
❌ Profile pictures upload

❌ Cover images via SocialProfile

❌ Any FoF Upload functionality

❌ Error: "File type not allowed"

Root Cause:
FoF Upload was saving images to:

What FoF Upload WAS Doing:

bash
# FoF Upload was saving images to WRONG location:

public_html/public/assets/files/          # ← WRONG path (used by uploads)
public_html/public/assets/avatars/        # ← WRONG path  
public_html/public/assets/covers/         # ← WRONG path
What Flarum WAS Looking For:
bash
# But Flarum was correctly looking in:
public_html/assets/files/                 # ← CORRECT path (empty)
public_html/assets/avatars/               # ← CORRECT path (empty)  
public_html/assets/covers/                # ← CORRECT path (empty)

The Evidence

When we checked the directories:

bash
[u148719152@fr-int-web1904 public_html]$ ls -la public/assets/
avatars/ covers/ files/ # ← files uploaded

[u148719152@fr-int-web1904 public_html]$ ls -la assets/
avatars/ covers/ files/ # ← THESE were EMPTY directories

The Path Resolution Confusion

FoF Upload's path resolution was different from core Flarum's path resolution:

FoF Upload Logic:

php
// FoF Upload was using:
$uploadPath = $forum->publicPath() . '/assets/files/';
// Which resolved to: /home/user/domains/fictograma.com/public_html/public/assets/files/

Core Flarum Logic:

php
// Core Flarum was using:  
$assetPath = $forum->url() . '/assets/files/';
// Which resolved to: https://fictograma.com/assets/files/
// Which pointed to: /home/user/domains/fictograma.com/public_html/assets/files/

The Actual Fix Needed

We needed to move the files from the WRONG location to the CORRECT location:

bash
# Move uploaded files to where Flarum expects them
mv public/assets/files/* assets/files/
mv public/assets/avatars/* assets/avatars/ 
mv public/assets/covers/* assets/covers/

Or create symlinks to maintain both paths

ln -s ../assets/files/ public/assets/files
ln -s ../assets/avatars/ public/assets/avatars
ln -s ../assets/covers/ public/assets/covers

Why This Caused Profile & Cover Photo Issues

User uploads profile picture → FoF Upload saves to public/assets/avatars/

Flarum tries to display profile picture → Looks in assets/avatars/ (EMPTY)

Result: Broken image, user thinks upload failed

The Root Cause

FoF Upload and Core Flarum had different understandings of the "public path" due to our non-standard directory structure.

Lesson Learned

The issue wasn't that "Flarum must run from public/", but that extension path resolution must match core Flarum path resolution. When they differ, uploaded files end up in different locations than where Flarum expects to find them.

Questions for Flarum Community

Is this documented anywhere? We couldn't find clear docs on Flarum's directory flexibility

Why does FoF Upload handle paths differently than core Flarum?

Are there other extensions with similar path resolution issues?

Should Flarum's default installation clarify directory structure options?

Conclusion

Flarum is directory-agnostic - it can run from any structure with correct configuration. The "must use public/" convention is a myth that caused our FoF Upload issues. Once we understood Flarum uses the public path from site.php configuration (not a physical /public/ directory), everything worked perfectly.

Pprofile pictures and cover images uploads functioning normally, but no fof uploads because of duplicated tables in db.

Forogramero

clarkwinkelmann Now I need your advice on this situation:

FoF Upload Cannot Enable Due to Duplicate Tables - Need Advice

Current FoF Upload Status

Despite fixing the directory structure issue, FoF Upload still cannot be enabled due to database table conflicts.

The Specific Error

When trying to enable FoF Upload via Admin panel or manually via database, we get database errors related to duplicate tables.

Tables Causing the Conflict

public_html]$ php flarum extension:enable fof-upload
Enabling 'fof-upload' extension...

In Connection.php line 712:
                                                                               
  SQLSTATE[42000]: Syntax error or access violation: 1091 Can't DROP COLUMN `  
  post_id`; check that it exists (SQL: alter table `fg_fof_upload_files` drop  
   `post_id`, drop `discussion_id`)                                            
                                                                               

In Exception.php line 18:
                                                                               
  SQLSTATE[42000]: Syntax error or access violation: 1091 Can't DROP COLUMN `  
  post_id`; check that it exists                                               
                                                                               

In PDOStatement.php line 117:
                                                                               
  SQLSTATE[42000]: Syntax error or access violation: 1091 Can't DROP COLUMN `  
  post_id`; check that it exists                                               
                                                                               

extension:enable [<extension-id>]

[u148719152@fr-int-web1904 public_html]$

The Exact Error

bash
SQLSTATE[42000]: Syntax error or access violation: 1091 
Can't DROP COLUMN `post_id`; check that it exists 
(SQL: alter table `fg_fof_upload_files` drop `post_id`, drop `discussion_id`)

Other Extension Tables That Might Conflict:

sql
fg_fof_user_bio          # User Bio extension
fg_fof_socialprofile     # Social Profile extension  
fg_fof_byobu             # Private Messages
fg_fof_polls             # Polls extension

Our Current Database Situation

We have multiple FoF extensions installed that might be sharing or conflicting with table structures:

fof/user-bio ✅ Working

fof/socialprofile ✅ Working

fof/byobu ✅ Working

fof/polls ✅ Working

fof/upload ❌ Cannot enable

Questions for Flarum Community

1. Safe Table Deletion
sql
-- Are these SAFE to drop if they exist?

DROP TABLE IF EXISTS fg_fof_upload_files;
DROP TABLE IF EXISTS fg_fof_upload_file_tags;
DROP TABLE IF EXISTS fg_fof_upload_mime_types;

2. Table Dependencies

Do other FoF extensions DEPEND on FoF Upload tables?

Will dropping these tables break fof/user-bio or fof/socialprofile?

Are these tables used by multiple extensions or just FoF Upload?

3. Migration Conflicts

Should we run specific migration commands?

Is there a way to reset JUST FoF Upload migrations?

What We've Tried

bash

1. Complete reinstall

composer remove fof/upload
composer require fof/upload

2. Cache clearing

rm -rf storage/cache/*

3. Manual database enabling

UPDATE fg_settings SET value = '["...","fof-upload"]' WHERE key = 'extensions_enabled';

Request for Specific Advice

Which exact tables can we safely drop?

Will this affect other working FoF extensions?

Is there a migration reset command for specific extensions?

Has anyone solved similar FoF extension table conflicts?

Our Concern

We're hesitant to drop tables because:

fof/user-bio works for text biographies

fof/socialprofile works for social links

We don't want to break these working features

We suspect table sharing between FoF extensions

Any guidance on safe table management would be greatly appreciated!

KBExit

On another note, have you tried the "Purge" button?

Forogramero

KBExit Yes, but it was something deeper...

dariomehr

I had similar problem days ago.

I exec composer require fof/upload:"*"
Then I go to the admin panel of the extension, push the button to active it.
But the button didn't work, and there is no record o message of error, even if I activate debug mode in config.php
No log.

But thanks to your post 🙏 I have discovered this command:
--> php flarum extension:enable fof-upload
This command is not in the extension documentation, I would be so useful include it.
@luceos

Output:
SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'fof_upload_file_posts' already exists
(the table was created but it's empty, I guess some incomplete activation attempt)

So I tried:
(againts db) DROP TABLE IF EXISTSfof_upload_file_posts;
and
(console) php flarum extension:enable fof-upload

And now the extension is working!! 😃
Thanks a lot @Forogramero

KBExit

dariomehr I understand the enthusiasm and urgency, but please mind the language here.

Forogramero

dariomehr Oh, so you did drop the tables and have no issues with another tables maybe using fof upload tables? That's what I wanted it to know. I'll give it a try.

But these are not the same duplicated tables that I have:

dariomehr SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'fof_upload_file_posts' already exists

I'll give it a try dropping my duplcated tables....

dariomehr

Forogramero

My solution maybe its not for your case.
I had in common "FoF Upload Installation Perfect but Cannot Be Activated"
My table fof_upload_file_posts existed and was empty.
(0 rows from SELECT * FROM fof_upload_file_posts;)
So that's why I decided trying removing that table, to allow the plugin create it.

Which it makes me think that this failure it is easy to prevent forever.
@luceos Could you remove this check?
SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'fof_upload_file_posts' already exists
I think may be using this:
CREATE TABLE IF NOT EXISTS
instead of
CREATE TABLE
could solve it.

I have found this reference (I am not sure if this is the place where you create the table)
FriendsOfFlarum/uploadblob/master/migrations/2022_06_08_000000_create_file_posts_table.php#L18

According to
https://api.laravel.com/docs/12.x/Illuminate/Database/Schema/Builder.html

this exists: dropIfExists
but not this: createIfExists

but instead of that, may be you can use hasTable has condition to create or omit the table creation 🙂
https://api.laravel.com/docs/12.x/Illuminate/Database/Schema/Builder.html#method_hasTable

Forogramero

dariomehr Thank you. I'll give an update soon (the truth is, the platform is doing well and don't want to mess it up).

I'll take the risk though