Can be pre-configured FTP server for wordpress container/image?
OleksandrKucherenko
All 22 comments
or make wp-content folder writeable for wp instance.
OleksandrKucherenko
on 11 Nov 2014
This should be fixed in #26. It seems the chown to www-data was failing, so the wp-content directory was unwritable.
yosifkit
on 12 Nov 2014
Can be FTP created as a shared extension to wordpress like mysql? that even will be more great than just embedding the things inside the image.
OleksandrKucherenko
on 15 Nov 2014
PHP does not have an FTP server extension, only an FTP client extension.
You might want to investigate using a separate container running an FTP server and sharing /var/www/html/wp-content as a volume.
md5
on 15 Nov 2014
That is exactly what I mean: create another image that will run ftp server, link wordpress with that image for making possible FTP access... sounds like a good plan
OleksandrKucherenko
on 15 Nov 2014
I'd be extremely surprised if something like that became an official image. It's easy enough to make your own if that's what you want.
Why do you want to use FTP anyways? It isn't a particularly secure way to transfer files.
md5
on 16 Nov 2014
why not?! at least one case maybe interesting: backup of the wordpress instance... common way is to do that over FTP. but i agree that today available hundred of other ways how to achieve that.
In my case I use wordpress image you provide for plugin development. So case of installing new plugin on WP image was important.
second case was: enabling xdebug for wordpress.
third case: update sources of the plugin without version up and re-installation.
OleksandrKucherenko
on 16 Nov 2014
@yosifkit : Could you please clarify how to fix wp-content unwritable?
trungtv
on 17 Nov 2014
If you're running Docker 1.3 or later, you can run docker exec
CONTAINER_NAME chown -R www-data:www-data /var/www/html. For earlier
versions, you should be able to do the equivalent with docker-enter.
Also, upgrading to the latest version of the wordpress image should also
fix this since the same chown is done in its entrypoint, but be careful
to do so in a way that preserves your Wordpress installation.
md5
on 17 Nov 2014
@trungtv: @md5 has the correct answers for fixing the wp-content being unwriteable. :+1: There were some issues with switching to the base php image that have been resolved (mostly missing dependencies and somehow the chown not working on btrfs or device mapper but still working on aufs).
yosifkit
on 17 Nov 2014
Cant we just add define('FS_METHOD', 'direct'); to wp-config.php?, that way we should be able to install without a hassle...
leon
on 29 Jan 2015
The docs on FS_METHOD are interesting:
(Primary Preference) "direct" forces it to use Direct File I/O requests from within PHP, this is fraught with opening up security issues on poorly configured hosts, This is chosen automatically when appropriate.
I wonder what "when appropriate" means. If we could get the normal Wordpress install to think it's "appropriate" to use FS_METHOD=direct during the install, that seems preferable to modifying FS_METHOD in the conf file directly.
md5
on 29 Jan 2015
++ @md5
tianon
on 29 Jan 2015
another way we could do it is include an optional config file for when you want to overwrite or change some wp-config.php settings. that way you wouldn't have to overwrite the whole file.
if(file_exists('wp-config-ext.php')){
include_once 'wp-config-ext.php';
}
This would appear to be the relevant code: https://github.com/WordPress/WordPress/blob/eeda68bbda104c5f4f1c837c6bf2288c84027a1d/wp-admin/includes/file.php#L926
As the docs state, direct is actually the preferred method. Wordpress does a check to see if a temp file written in the "context" directory (e.g. wp-content/plugins in the case of plugin installs) has the same ownership as wp-admin/includes/file.php. Since that file is owned by www-data:www-data and Apache is running as www-data, I'd assume that the direct method is actually what this container currently defaults to.
The main case I can think of where it would not allow direct as the method is when you've bind mounted in a wp-content/plugins or other "context" directory that is not writable by the www-data user.
md5
on 29 Jan 2015
Can we close this issue about FTP? I think the purpose of these images is to be as small as possible. For exotic configuration, you can base you work from this image.
pierreozoux
on 19 Jul 2015
I'm having issues when trying to use the Wordpress importer and using volumes to copy over themes. To get the wp importer plugin installed I need to use the chown to prevent the request that I use ftp. However when I mount the Volume to my local file system to copy over a plugin and theme the permissions are changed. When I unmount the volume the permissions can be chowned back but I no longer see the theme or plugin! Something is not functioning between the two, I'm not sure what it is. I was attempting to see if it is possible to ssh into the container to see in detail but was not sure where I find the default information for the container, I'm new to using docker so please point me to the correct location if this is general information not continer specific!
nigel-daniels
on 24 Aug 2015
@nigel-daniels please open another issue with the right request and ping me, I'll be glad to help (your issue is about rights and not ftp).
To further investigate, you can 'enter' the container by:
docker exec -it container_name bash, this will open a bash inside the container (ls -lat will probably give you the anser).
@OleksandrKucherenko can you please close the issue, there will never be an ftp service inside this image. If you want ftp, just start an ftp container on the side, and mount wp volumes. Thanks.
pierreozoux
on 25 Aug 2015
@pierreozoux thanks for your advice. I opened #97 to flag the rights issue.
nigel-daniels
on 25 Aug 2015
Why do you want to use FTP anyways? It isn't a particularly secure way to transfer files.
One reason would be so that it was easy to update plugins using the wordpress UI
simonh1000
on 5 Nov 2017
The default image configuration should have permissions set so that
WordPress can simply do that properly out-of-the-box, as it prefers to do.
tianon
on 8 Nov 2017
Yes I discovered that pleasant surprise shortly afterwards
On 8 Nov 2017 05:59, "Tianon Gravi" notifications@github.com wrote:
The default image configuration should have permissions set so that
WordPress can simply do that properly out-of-the-box, as it prefers to do.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/docker-library/wordpress/issues/24#issuecomment-342711311,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFA2FF-Cf9yBl2Ch2-G-y4n3IyJL2bmcks5s0TUjgaJpZM4C5jeZ
.
simonh1000
on 8 Nov 2017
Related issues
chrissound
·
5Comments
uda
·
4Comments
myuseringithub
·
5Comments
TeachMeHowToUse2FA
·
4Comments
etc0de
·
4Comments
Most helpful comment
If you're running Docker 1.3 or later, you can run
docker exec CONTAINER_NAME chown -R www-data:www-data /var/www/html. For earlierversions, you should be able to do the equivalent with
docker-enter.Also, upgrading to the latest version of the
wordpressimage should alsofix this since the same
chownis done in its entrypoint, but be carefulto do so in a way that preserves your Wordpress installation.