aws-samples / eb-php-wordpress

Configuration files and instructions for installing WordPress securely and running it in a load balanced AWS Elastic Beanstalk environment with an EFS file system for shared assets.
Apache License 2.0
165 stars 95 forks source link

/wpfiles EFS symlink one level too deep? #13

Closed atomarch closed 6 years ago

atomarch commented 6 years ago

Hello,

It appears that the symlink to /wpfiles is one level too deep? I just provisioned a Wordpress environment according to the guide at http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/php-hawordpress-tutorial.html I see /var/app/current/wp-content/uploads/wpfiles is symlinked to /wpfiles

[root@ip-xx-xx-xx-xx uploads]# pwd /var/app/current/wp-content/uploads [root@ip-xx-xx-xx-xx uploads]# ls -l total 0 lrwxrwxrwx 1 webapp webapp 8 Sep 21 23:02 wpfiles -> /wpfiles [root@ip-172-31-32-139 uploads]#

Shouldn't /var/app/current/wp-content/uploads be symlinked to /wpfiles instead?

mwunderl commented 6 years ago

It should. Here's the command that the configuration file runs- sudo -u webapp ln -s /wpfiles wp-content/uploads

If you already have a folder in your source named wp-content/uploads, you would end up with a link named wpfiles inside that folder, instead of a link named uploads in wp-content. Is there an uploads folder in your source bundle? Thanks, -Michael

atomarch commented 6 years ago

Yep, that was it. I deleted wp-content/uploads, re-zipped and re-uploaded to EB. Symlink looks good now. Thanks!

matthew-socialcore commented 5 years ago

Hi, I hit this issue and after a bunch of investigation came to the conclusion in https://github.com/aws-samples/eb-php-wordpress/issues/13#issuecomment-331309498

It seems likely other people will continue to stumble over this.

The eb-php-wordpress template has a wp-config-local.php file which indicates we're encouraged to work locally between deploys to AWS. Along the way invariably a wp-content/uploads folder will be created and checked-in.

The impact to me was that i ran an eb deploy and the checked in wp-content/uploads blew away the wp-content/uploads directory on my instance. 100% WAI, of course - but I had no idea until after the content was gone that the symlink hadn't properly been created.

Maybe use ln -F so that if the target exists and is a directory, it gets removed?

If that seems too destructive, instead fail with an error if the symlink hasn't been created successfully?

mwunderl commented 5 years ago

Hi Matthew, I think we can avoid this by adding a .gitignore file to avoid checking in the uploads directory. What do you think?

Thanks, -MIchael

matthew-socialcore commented 5 years ago

that's a good idea. What about other VCS systems, do they rely on .gitignore files as well?

I like bundling a .gitignore b/c after I've extracted everything I'll see a .gitignore file in my top-level WP dir - which immediately introduces me the notion of Elastic Beanstalk as a version controlled repo (from which you do can only deploy checked-in code).

tunicopp commented 1 year ago

Hello, I'm starting now with Beanstalk that I got this question too.

Would it be possible to mount the instance during deploy in the wordpress /www root folder? This would avoid losing all wordpress core updates and plugins premium as well