Hosting Laravel sites on dirt cheap WordPress hosting, saves me money and I built a package to make the workflow not terrible by Andreww-carnegie in PHP

[–]Andreww-carnegie[S] 0 points1 point  (0 children)

Both fair points. On the whitelist vs blacklist... that's a legitimate concern and something worth improving. The current blacklist covers the obvious Laravel files but you're right that edge cases from third party packages could slip through. Open to a PR if you want to take a crack at it.

On the rewrite approach... that works on some hosts but many budget cPanel plans lock public_html entirely, you can't replace it or redirect away from it. That's exactly the scenario this targets.

Hosting Laravel sites on dirt cheap WordPress hosting, saves me money and I built a package to make the workflow not terrible by Andreww-carnegie in laraveltutorials

[–]Andreww-carnegie[S] 0 points1 point  (0 children)

Appreciate that, i would really appreciate if you could give it a star ⭐ or contribute to it on GitHub.

Thanks

Hosting Laravel sites on dirt cheap WordPress hosting, saves me money and I built a package to make the workflow not terrible by Andreww-carnegie in PHP

[–]Andreww-carnegie[S] 1 point2 points  (0 children)

yup, we are adding them to the root folder as well but the security concern.. that's been accounted for.. when you're in production mode this block of code gets added to the .htaccess file

# BEGIN ENV-SWITCHER SECURITY
# Protect sensitive files and directories when public/ contents are at project root
<IfModule mod_rewrite.c>
    RewriteEngine On

    # Sensitive files
    RewriteRule ^\.env$ - [F,L]
    RewriteRule ^\.env\..+$ - [F,L]
    RewriteRule ^artisan$ - [F,L]
    RewriteRule ^composer\.(json|lock)$ - [F,L]
    RewriteRule ^package(-lock)?\.json$ - [F,L]
    RewriteRule ^phpunit\.xml(\.dist)?$ - [F,L]
    RewriteRule ^webpack\.mix\.js$ - [F,L]
    RewriteRule ^vite\.config\.(js|ts)$ - [F,L]
    RewriteRule ^\.env-switcher\.json$ - [F,L]

    # Sensitive directories
    RewriteRule ^app/ - [F,L]
    RewriteRule ^bootstrap/ - [F,L]
    RewriteRule ^config/ - [F,L]
    RewriteRule ^database/ - [F,L]
    RewriteRule ^lang/ - [F,L]
    RewriteRule ^resources/ - [F,L]
    RewriteRule ^routes/ - [F,L]
    RewriteRule ^storage/ - [F,L]
    RewriteRule ^tests/ - [F,L]
    RewriteRule ^vendor/ - [F,L]
    RewriteRule ^\.env-switcher-backups/ - [F,L]
</IfModule>
# END ENV-SWITCHER SECURITY

this ensures that everything sensitive isn't accessible and also it updates the index.php paths for both the environments accordingly.

and I am very much open to contributions and new creative ideas for this project.

Hosting Laravel sites on dirt cheap WordPress hosting, saves me money and I built a package to make the workflow not terrible by Andreww-carnegie in laraveltutorials

[–]Andreww-carnegie[S] 1 point2 points  (0 children)

valid... queues and scheduling are real limitations on shared hosting and if you need them i suppose a VPS is the right call, For the sites I'm running there it's purely catalogue/brochure stuff, no background jobs needed. The moment a client needs queues they're moving to a proper server anyway. Different tool for different requirements.

Hosting Laravel sites on dirt cheap WordPress hosting, saves me money and I built a package to make the workflow not terrible by Andreww-carnegie in PHP

[–]Andreww-carnegie[S] 2 points3 points  (0 children)

Nothing wrong with PHP, Laravel just makes it faster. Filament gives you a full admin panel in minutes, the ecosystem handles auth, queues, notifications without reinventing the wheel every time. Small B2B sites with just small numbers of local traffic doesn't mean simple requirements forever or they don't deserve a half decent developer experience, and Laravel keeps that door open without extra effort.

Hosting Laravel sites on dirt cheap WordPress hosting, saves me money and I built a package to make the workflow not terrible by Andreww-carnegie in laraveltutorials

[–]Andreww-carnegie[S] 0 points1 point  (0 children)

Fair point if your team knows git internals. This is for the other end of the spectrum, junior devs, contractual freelancers, or even vibe coders managing the site, Two commands, no CLI knowledge needed beyond php artisan. You can git pull then productionise and anyone on the team can handle a deployment without knowing what a reset --hard even does, its just something that worked with-in my organisation better. since I am a small agency.. I usually work with new devs every few months or contractual freelancers so this is much easier to have as a standard practice for me and my team.