Closed farshidhss closed 4 years ago
I appreciate that you edited the text to be less snarky :D
I mount a custom php.ini
config to override that setting. An alternative would be to build an image based on wordpress-starter with the changes you need in php.ini
It is certainly better to be less snarky :D I will mount the php.ini then, as I don't feel comfortable to touch the docker file. Would be nice if you give some explanation on what the docker file is doing on a high level.
Checked into it and it looks like WPEngine and a couple other popular WordPress providers use a default of 50mb for max upload size. So I'll consider bumping it to that. If that sounds acceptable.
Agree that 2mb is not quite enough, but I haven't personally needed it.
Checked into it and it looks like WPEngine and a couple other popular WordPress providers use a default of 50mb for max upload size. So I'll consider bumping it to that. If that sounds acceptable.
Agree that 2mb is not quite enough, but I haven't personally needed it.
My workflow is that I often setup a fresh Wordpress and then use wp-migration to import a large existing Wordpress into the local setup. This makes it very easy to make quick improvements/experiments without actually messing with a live website.
Given that, it would help a lot if this repo already included a large max upload file size by default.
If that's the case, why not just use wp-cli as described in the readme?
You can import a mysql dump or a WXR file, which would arguably be easier than doing it using the frontend interface because it could be automated on build.
If that's the case, why not just use wp-cli as described in the readme?
You can import a mysql dump or a WXR file, which would arguably be easier than doing it using the frontend interface because it could be automated on build.
With wp-migration I can import database, templates, plugins and all uploaded files at the same time. It is very smooth process and takes just a few seconds to get the entire website ready to go. I have never seen another simpler method. This takes basically one click to download the exported file and then one click to import everything and it always worked for all websites that I worked on.
Yep, same with either of the two methods I described.
I do it using the sqldump method and mounting the wp-content/uploads
directory.
But if using WXR is your preferred method (which I assume is what wp-migration does), you can achieve the same thing there using wp-cli's wp import
command.
I should also note that by default, if you have a database export mounted into /data/*.sql
, it'll automatically get imported on build using our orchestration we set up.
Yep, same with either of the two methods I described.
I do it using the sqldump method and mounting the
wp-content/uploads
directory.But if using WXR is your preferred method (which I assume is what wp-migration does), you can achieve the same thing there using wp-cli's
wp import
command.
I don't think wp-migration plugin is creating a WRX format and hence not importable. I even tried to import it using the instructions in the readme and it failed. I see that the command in your instruction is not working:
npm run wp db import /data/backup-20191014-061359-540.wpress
this is the summary of the output:
docker-compose exec wordpress bash "db" "import" "backup-20191014-061359-540.wpress" bash: db: No such file or directory
npm run wp command just calls docker-compose exec wordpress bash
and after that calling db
doesn't do anything, because there is no such command.
if I try to fix it by adding another wp in the command (npm run wp wp db import /data/backup-20191014-061359-540.wpress
then I get:
docker-compose exec wordpress bash "wp" "db" "import" "/data/backup-20191014-061359-540.wpress" /usr/local/bin/wp: line 2: ?php: No such file or directory /usr/local/bin/wp: wp: line 3: syntax error near unexpected token ';' /usr/local/bin/wp: wp: line 3: 'Phar::mapPhar();'
which I suppose indicates that the file is not WRX compatible.
Even if all the above could work magically, I would still have to solve the problem of replacing the domain name with localhost:8080 which adds another unnecessary step. Yes, the instructions says I have to modify the docker-compose and add it there but I don't see why when a simple wp-migration plugin solves it all!? All in all, I tried and wasted a lot of time on this. As I said the workflow of exporting using wp-migration always proved to be the simplest for me and I wished you could at least see the point that it would save people time and make your image more useful but maybe you prefer your ways. It's a pity. I move on.
docker-compose exec wordpress bash "db" "import" "backup-20191014-061359-540.wpress"
If this is what the readme says, it's incorrect.. It needs to be...
$ docker-compose exec wordpress wp db import <your-sql-export.sql>
# ^^^^^^^^^ name of wordpress service in docker-compose.yml
# ^^ command to run
# ^^^^^^^^^ subcommand
# ^^^^^^^^^^^^^^^^^^^^^ an exported sql file
Even if all the above could work magically,
It does, I can assure you that.
I would still have to solve the problem of replacing the domain name with localhost:8080 which adds another unnecessary step.
Adding a URL_REPLACE
env variable literally does exactly that.
Yes, the instructions says I have to modify the docker-compose and add it there but I don't see why when a simple wp-migration plugin solves it all!?
Because if you add that single line to the docker-compose.yml
file, and follow the rest of the instructions, the import process is 100% fully automated and you don't have to do anything at all, rather than having to export and import a site manually.
All in all, I tried and wasted a lot of time on this. As I said the workflow of exporting using wp-migration always proved to be the simplest for me and I wished you could at least see the point that it would save people time and make your image more useful.
The method you describe is objectively not more useful or simpler. The issue is solely due to the fact that you failed to read and understand the instructions we've written in the readme. Your method would not save people any time. It is not faster. It is not easier.
I agree that it is probably best that you move on.
This is the screenshot of your readme. I simply followed what it says.
Anyway, I fixed it by putting my php.ini settings in the tweaks.ini file. Would helped me a ton if you mentioned that you do have that in place. It is briefly mentioned in another readme inside the example folder. I like your work but would be even better with more clarity.
The first thing I do in wordpress is to upload a file but this image only has maximum file size upload for wordpress set to 2mb! Do I need to mount the config to fix it?