Jump to content

Moving the vendor folder outside of public_html folders?


Inxentas
 Share

Recommended Posts

Hello guys, I've started to implement Composer in my workflow more seriously and I'm looking for the best way to include more then just ProcessWire. We often use a few extra bits and bobs (such as PHPMailer) and I'm not sure how to best treat PW as a Composer package and how to get the vendor folder outside of the public folder. Now whether I do composer require or composer create project, I get PW as a full project including it's own composer.json and .lock files with it's vendor folder sitting next to the wire and site folders. Now I've done some experiments, such as moving the folder manually and changing the require statement in index.php, but that feels messy to me. I've also created a new empty project with my own folder structure, and then copied vendor/processwire/processwire into the public folder for installation, but I still need to faff around with PW's actual code. Is there a neat way to create a Composer project (or inherit the existing one) and use Composer commands to somehow get the vendor folder to sit once directory up from it's default directory?

Link to comment
Share on other sites

  • 3 weeks later...

Thank you, I found that article already though, and I found it to be a little messy of a process as well. On top of that I would like to use autoloaded stuff in my modules so that approach isn't super suitable for me. I have decided that for now, I'll just modify the existing index.php as that file won't change too often.

Link to comment
Share on other sites

45 minutes ago, bernhard said:

Would be curious why you prefer PHPMailer over WireMail?

I took a look at the WireMail class and what I miss is SMTP support (although I might be wrong here, I simply didn't see anything in the docs that implies SMTP is supported out of the box). I could also use the module named WireMailSMTP for example, but no matter how you cut it that would involve installing the module manually for each website. It's preferable to me to manage dependencies with Composer and reuse our existing mail scripts, then installing PW modules manually for each project. 

  • Like 1
Link to comment
Share on other sites

To guard against execution of scripts inside vendor folder there seem to be 2 common approaches.

  1. move vendor outside webroot
  2. protect vendor folder with a .htaccess file

I 'm just wondering if option 2 might be the better in our case because it doesn't involve changing core index.php

Other CMS include a .htaccess inside vendor. Drupal for example does it like this with following content in vendor/.htaccess

# Deny all requests from Apache 2.4+.
<IfModule mod_authz_core.c>
  Require all denied
</IfModule>

# Deny all requests from Apache 2.0-2.2.
<IfModule !mod_authz_core.c>
  Deny from all
</IfModule>

# Turn off all options we don't need.
Options -Indexes -ExecCGI -Includes -MultiViews

# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
<Files *>
  # Override the handler again if we're run later in the evaluation list.
  SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
</Files>

# If we know how to do it safely, disable the PHP engine entirely.
<IfModule mod_php.c>
  php_flag engine off
</IfModule>

Other suggestions from SO for .htaccess are:

Order allow,deny
Deny from all

Problem with this apporach seems to be that the .htaccess gets lost when you remove vendor and do a composer install for whatever reason.

But this could be solved with composer scripts inside composer.json. For example a simple script that places an .htaccess file inside vendor after composer install is finished using the post-install-cmd event.
 In https://github.com/processwire/processwire/blob/master/composer.json after line 22 we could add

,
    "scripts": {
        "post-install-cmd": "echo $'Order allow,deny\nDeny from all' > vendor/.htaccess"
    }

Just tested this and it works.

13 hours ago, bernhard said:

Didn't think of SMTP as I try to avoid it

This is off topic but would you mind explaining why you are trying to avoid SMTP and what your preferred alternative is?

  • Like 2
Link to comment
Share on other sites

5 hours ago, gebeer said:

But this could be solved with composer scripts inside composer.json. For example a simple script that places an .htaccess file inside vendor after composer install is finished using the post-install-cmd event.
 In https://github.com/processwire/processwire/blob/master/composer.json after line 22 we could add

,
    "scripts": {
        "post-install-cmd": "echo $'Order allow,deny\nDeny from all' > vendor/.htaccess"
    }

Just tested this and it works.

Not exactly my strength but looks like a worthwhile addition to me 🙂 

5 hours ago, gebeer said:
19 hours ago, bernhard said:

Didn't think of SMTP as I try to avoid it

This is off topic but would you mind explaining why you are trying to avoid SMTP and what your preferred alternative is?

I just found it really cumbersome to setup all the time. And complicated to use. And a pain to switch between live and development.

I'm just setting um my server correctly to get 10/10 on mail-tester using plain WireMail() without installing any additional libraries. Then sending an email ist just 5 lines of code away and it works well on DDEV (gets caught by mailcatcher) and once pushed to live it sends real emails without changing anything.

  • Like 2
Link to comment
Share on other sites

For me the SMTP thing is not really negotiable, sometimes companies use some mail setup that requires it. I've used both PHPMailer and the module, and sometimes the module even wins out. Thanks for the "post-install-cmd" tip, that might work well for my situation... being that moving the vendor folder outside of the webroot isn't mission critical. I'm in that situation where I can do whatever I want, but I do have to work with 101 different mail clients and shared hosts so I prefer to add my most used packages to a new project by default.  Thanks everyone!

  • Like 2
Link to comment
Share on other sites

  • 1 year later...

Just to add a caveat to blocking vendor/ - this sometimes leads to unservable asset issues (such as JS/fonts/images/styles) if the composer package includes such things. YMMV with this approach, but the inspector in the browser can help tracking these down.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...