Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

/wpfiles EFS symlink one level too deep? #13

Closed
atomarch opened this issue Sep 21, 2017 · 6 comments
Closed

/wpfiles EFS symlink one level too deep? #13

atomarch opened this issue Sep 21, 2017 · 6 comments

Comments

@atomarch
Copy link

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
Copy link
Contributor

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
Copy link
Author

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

@matthew-socialcore
Copy link

Hi, I hit this issue and after a bunch of investigation came to the conclusion in #13 (comment)

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
Copy link
Contributor

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
Copy link

matthew-socialcore commented Nov 14, 2018

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
Copy link

tunicopp commented Mar 2, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants