docker/wordpress:将默认插件与自己的插件分开 [英] docker/wordpress: seperate default plugins from own plugins

查看:68
本文介绍了docker/wordpress:将默认插件与自己的插件分开的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

让我尝试解释我想要实现的目标:

我正在做wordpress开发,并尝试通过docker很好地进行设置.我有一个包含 themes plugin 的文件夹,我在其中开发插件和主题.该文件夹还包含Docker文件,可以在通过WordPress安装的容器中运行它们.它的泊坞窗图片.到目前为止,一切都很好,但是我无法真正实现我想要的目标,那就是在保持代码更改传播到容器的同时,使我的代码与其他所有代码分开.

使用官方 wordpress 图片(

将下面的代码复制到您的yml配置中...

 版本:"3.7"网络:WordPress的:ipam:配置:-子网:172.25.0.0/16服务:#这是我们的mysql数据库D b:图像:mysql:5.7数量:-./db:/var/lib/mysql:委托端口:-"3306:3306";重启:总是环境:MYSQL_ROOT_PASSWORD:somewordpressMYSQL_DATABASE:wordpressMYSQL_USER:wordpressMYSQL_PASSWORD:wordpress网络:-WordPress的#这是我们的wordpress服务器WordPress的:取决于:- D b图片:wordpress:latest数量:#我们持久的本地数据重新路由-.:/var/www/html/wp-content/themes/testing:delegated-./plugins:/var/www/html/wp-content/plugins-./uploads:/var/www/html/wp-content/uploads-./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini端口:-"80:80";重启:总是网络:-WordPress的环境:#我们当地的开发环境WORDPRESS_DEBUG:1发展:1#docker wp配置设置WORDPRESS_DB_HOST:db:3306WORDPRESS_DB_USER:wordpressWORDPRESS_DB_PASSWORD:wordpressWORDPRESS_DB_NAME:wordpressWORDPRESS_AUTH_KEY:5f6ede1b94d25a2294e29eeba929a8c80a5ac0fbWORDPRESS_SECURE_KEY:5f6ede1b94d25a2294e29eeba929a8c80a5ac0fbWORDPRESS_LOGGED_IN_KEY:5f6ede1b94d25a2294e29eeba929a8c80a5ac0fbWORDPRESS_NONCE_KEY:5f6ede1b94d25a2294e29eeba929a8c80a5ac0fbWORDPRESS_SECURE_AUTH_SALT:5f6ede1b94d25a2294e29eeba929a8c80a5ac0fbWORDPRESS_LOGGED_IN_SALT:5f6ede1b94d25a2294e29eeba929a8c80a5ac0fbWORDPRESS_NONCE_SALT:5f6ede1b94d25a2294e29eeba929a8c80a5ac0fbWORDPRESS_CONFIG_EXTRA:/*开发参数*/define('WP_CACHE',false);define('ENVIRONMENT','local');define('WP_DEBUG',true);/*配置邮件服务器*/define('WORDPRESS_SMTP_AUTH',false);define('WORDPRESS_SMTP_SECURE','');define('WORDPRESS_SMTP_HOST','mailhog');define('WORDPRESS_SMTP_PORT','1025');define('WORDPRESS_SMTP_USERNAME',null);define('WORDPRESS_SMTP_PASSWORD',null);define('WORDPRESS_SMTP_FROM','whoever@example.com');define('WORDPRESS_SMTP_FROM_NAME','Whoever');/*在此处添加更多自定义wp-config定义*/#这是我们的邮件服务器mailhog:图片:mailhog/mailhog:latest端口:-"8025:8025";网络:-WordPress的 

确保您的Docker应用程序是最新的.如果以前有任何docker项目正在运行,请在项目中使用此命令将其关闭...

  docker-compose down 

然后在新项目文件夹中运行此命令以构建新的wordpress网站...

  docker-compose up -d 

现在,这将在您的项目文件夹中建立具有永久文件夹的新安装...

在访问站点之前,您需要使用此配置代码将 uploads.ini 文件夹更新为实际的 uploads.ini 文件...

  file_uploads =开memory_limit = 2000Mupload_max_filesize = 2000Mpost_max_size = 2000Mmax_execution_time = 600 

所以现在您将拥有...

在再次访问该站点之前,最好将一些基本主题文件放入其中,这样您的主题将在您访问该站点并以管理员身份运行时出现.

要让

使用docker工作流在本地部署现有的wp主题...

如果要在本地部署现有主题/项目.获取您现有的主题文件夹和内容,然后在您的操作系统上本地找到它.

请勿尝试在 docker-compose.yml 中映射 themes 文件夹,因此您可以手动添加主题并激活它.不是这样!

基本上(与上面相同),在现有主题的根目录(本地)中创建一个 docker-compose.yml 文件.

如果您不需要任何现有的 db /插件/上载即可运行此主题,则只需简单操作(如上所示)使用 docker-compose up -d 构建全新的wordpress安装,并将持久化的 db / plugins / uploads 映射到此现有的本地主题文件夹.

很显然,如果您现有的主题项目文件夹以前包含任何名为 db / plugins / uploads 的子文件夹,然后尝试使用yml进行重建config(上面提到的)可能会变得很棘手.确保您现有的主题文件夹没有具有这些名称的子文件夹... db /插件/上载.

如果要使用docker部署现有主题/项目,同时保留生产或暂存环境中的 db / plugins / uploads 数据然后...

在现有主题中创建一个名为 docker/db-dumps 的文件夹和子文件夹,以及带有yml配置的 docker-compose.yml 文件(如上所示)

在进行docker启动之前,将 mySql db dump文件(例如 dump.sql )放置在 docker/db-dumps 和所有必需的插件中/uploads在此现有主题的 plugins uploads 文件夹中.这样...

请注意上面的屏幕截图演示中,我没有显示任何内容现有主题文件.如果您尝试此操作,请上面的演示屏幕快照子目录结构将是您的附加现有的主题文件夹文件.

在生产或登台数据库sql dump和插件/上载正确定位的情况下,您唯一需要在 docker-compose.yml 中进行编辑的就是这个...

 #这是我们的mysql数据库D b:图像:mysql:5.7数量:#-./db:/var/lib/mysql:delegated(删除它并在下面添加行)-./docker/db-dumps:/docker-entrypoint-initdb.d:委托 

这意味着当您 docker-compose up -d 时,它将首先运行转储并将生成的转储sql生成到新安装中,并将数据库部署到 db 文件夹.

意思是如果您希望在下一个 docker-compose up -d 中重建此数据,则需要将 docker-compose.yml 还原回我的原始数据 db 卷,以便Docker从您上次中断的地方重建.

Git忽略示例...

如我的高级开发屏幕截图所示,您将看到一个git ignore文件.通常,如果您使用的是我的高级开发者屏幕截图中显示的技术,那么这就是gitignore文件内容的样子……

 /供应商/上传/D b/dist/node_modules/插件/码头工人 

Let me try to explain what i want to achieve:

I am doing wordpress development and and try to set it up nicely via docker. I have a folder with themes and plugin where i my develop plugins and themes in. This folder also contains Docker files to be able to run them i a container where wordpress is installed via its docker image. So far so good, but i cannot really achieve what i want, which is keep my code separate from everything else while maintaining code changes being propagated to the container.

Using the official wordpress image (https://hub.docker.com/_/wordpress/) you should put preinstalled themes and plugins in the respective folders under /var/www/html/wp-content. Using a docker-compose.yml with volume directives i can achieve that.

web:
    image: wordpress
    ports: [...]
    environment:[...]
    volumes:
        - ./plugins:/var/www/html/wp-content/plugins/
        - ./themes:/var/www/html/wp-content/themes/

However in that case when the container is started, wordpress copies itself into the /var/www/html/ folder, also placing default themes and plugins in above folders. And my original structure is "compromised". I do not want that.

The problem is i do not find any way to keep my original plugins and themes structure unaffected while maintaining code changes being instantly propagated to the docker container. I could possibly mount plugin and themes one-by-one but that is also not what i want.

I tried to customize the Dockerfile or a custom entrypoint and fiddle around with symlinking etc. But actually i could not find a way to do that. Probably i am doing it all wrong and should not be doing that anyway. Any suggestions?

解决方案

How the official wordpress docker image works...

Where the docker-compose.yml is located, is the current theme folder!

Attempting to map the themes folder using symlinks is not good idea, because this is where testing theme exists. This will just confuse things which i'm assuming you maybe experiencing from you question.

This is the common thing that I see a lot in noob docker wp devs. They think they have to edit files which docker has built. You never edit or access container files built by docker... because when you docker-compose down, all that data will be deleted.

By default...

Every time you run docker-compose up -d on the folder containing your docker-compose.yml config file, docker will build a brand new wordpress installation every time.

Then when you run docker-compose down it will remove all the containers, deleting database, plugins and uploads data.

So next time when you docker-compose up -d on this project, you will have to re-go through the wordpress install setup, and you will have lost all of your previous development data, plugins and uploads.

Local docker wp handling...

Treat every local wordpress project as its own!

I'm not including child theme usages in this answer, but my methods can be extended to accommodate child themes.

When I say treat each project as it's own. The project folder containing the docker-compose.yml is your git repository! As time goes by you will have a folder for each individual local wp project/site on your OS.

Each of these local folders is the development theme for your current project/site!

Don't try and use a single docker-compose.yml config to handle multiple projects/themes until you understand how docker rebuilds containers based on your configs.

A brand new wordpress theme docker workflow...

Create a new empty local folder/project.

Add docker-compose.yml file to your project..

Copy this code below into your yml config...

version: '3.7'

networks:
  wordpress:
    ipam:
      config:
        - subnet: 172.25.0.0/16

services:

  # here is our mysql database
  db:
    image: mysql:5.7
    volumes:
      - ./db:/var/lib/mysql:delegated
    ports:
      - "3306:3306"
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: somewordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress
    networks:
      - wordpress

  # here is our wordpress server
  wordpress:
    depends_on:
      - db
    image: wordpress:latest
    volumes:
      # our persistent local data re routing
      - .:/var/www/html/wp-content/themes/testing:delegated
      - ./plugins:/var/www/html/wp-content/plugins
      - ./uploads:/var/www/html/wp-content/uploads
      - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
    ports:
      - "80:80"
    restart: always
    networks:
      - wordpress
    environment:
      # our local dev environment
      WORDPRESS_DEBUG: 1
      DEVELOPMENT: 1
      # docker wp config settings
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_AUTH_KEY: 5f6ede1b94d25a2294e29eeba929a8c80a5ac0fb
      WORDPRESS_SECURE_KEY: 5f6ede1b94d25a2294e29eeba929a8c80a5ac0fb
      WORDPRESS_LOGGED_IN_KEY: 5f6ede1b94d25a2294e29eeba929a8c80a5ac0fb
      WORDPRESS_NONCE_KEY: 5f6ede1b94d25a2294e29eeba929a8c80a5ac0fb
      WORDPRESS_SECURE_AUTH_SALT: 5f6ede1b94d25a2294e29eeba929a8c80a5ac0fb
      WORDPRESS_LOGGED_IN_SALT: 5f6ede1b94d25a2294e29eeba929a8c80a5ac0fb
      WORDPRESS_NONCE_SALT: 5f6ede1b94d25a2294e29eeba929a8c80a5ac0fb
      WORDPRESS_CONFIG_EXTRA: |

        /* Development parameters */
        define('WP_CACHE', false);
        define('ENVIRONMENT', 'local');
        define('WP_DEBUG', true);

        /* Configure mail server */
        define('WORDPRESS_SMTP_AUTH', false);
        define('WORDPRESS_SMTP_SECURE', '');
        define('WORDPRESS_SMTP_HOST', 'mailhog');
        define('WORDPRESS_SMTP_PORT', '1025');
        define('WORDPRESS_SMTP_USERNAME', null);
        define('WORDPRESS_SMTP_PASSWORD', null);
        define('WORDPRESS_SMTP_FROM', 'whoever@example.com');
        define('WORDPRESS_SMTP_FROM_NAME', 'Whoever');

        /* add any more custom wp-config defines here */

  # here is our mail hog server
  mailhog:
    image: mailhog/mailhog:latest
    ports:
      - "8025:8025"
    networks:
      - wordpress

Make sure your docker app is up to date. If any previous docker project is running, use this command in project to shut it down...

docker-compose down

Then in your new project folder run this command to build your new wordpress site...

docker-compose up -d

Now this will build a new installation with persistent folders in your project folder...

Before you access the site you need to update the uploads.ini folder to an actual uploads.ini file with this config code...

file_uploads = On
memory_limit = 2000M
upload_max_filesize = 2000M
post_max_size = 2000M
max_execution_time = 600

So now you will have...

Before you access the site again it's probably a good idea to put some basic theme files in so your theme will run when you visit the site and admin.

For mailhog to work and receive outgoing mail from your local wordpress environment you will need to add this to your functions.php...

// add the action
add_action('wp_mail_failed', 'action_wp_mail_failed', 10, 1);

// configure PHPMailer to send through SMTP
add_action('phpmailer_init', function ($phpmailer) {

    $phpmailer->isSMTP();
    // host details
    $phpmailer->SMTPAuth = WORDPRESS_SMTP_AUTH;
    $phpmailer->SMTPSecure = WORDPRESS_SMTP_SECURE;
    $phpmailer->SMTPAutoTLS = false;
    $phpmailer->Host = WORDPRESS_SMTP_HOST;
    $phpmailer->Port = WORDPRESS_SMTP_PORT;
    // from details
    $phpmailer->From = WORDPRESS_SMTP_FROM;
    $phpmailer->FromName = WORDPRESS_SMTP_FROM_NAME;
    // login details
    $phpmailer->Username = WORDPRESS_SMTP_USERNAME;
    $phpmailer->Password = WORDPRESS_SMTP_PASSWORD;

});

Now these urls below will work...

So every time you docker-compose down and docker-compose up -d on this project, your environment will boot up exactly where you left off.

As your project grows, advanced theme development, keeping every single thing consolidated in the project/folder makes managing multiple theme project easier.

Like this for example...

Deploying an existing wp theme locally with docker workflow...

If you want to deploy an existing theme/project locally. Get your existing theme folder and contents, and locate it locally on your OS.

Do not try and map the themes folder in your docker-compose.yml so you can manually add themes and activate it. This is not the way!

Essentially (same as above), create a docker-compose.yml file inside the root of your existing theme (locally).

If you don't require any existing db/plugins/uploads for this theme to run, then simply (as shown above) use docker-compose up -d to build brand new wordpress installation with persistent db/plugins/uploads mapped into this existing local theme folder.

Obviously if your existing theme project folder previously contains any child folders named db/plugins/uploads, then attempting to rebuild using my yml config (mentioned above) will probably go tits up. Make sure your existing theme folder has no child folders with these names... db/plugins/uploads.

If you want to deploy an existing theme/project using docker whilst retaining db/plugins/uploads data from a production or staging environment then...

Create a folder and sub folder called docker/db-dumps in your existing theme along with a docker-compose.yml file with yml configs (as shown above).

Before dockering up, place a mySql db dump file (example dump.sql) in docker/db-dumps and any required plugins/uploads in plugins and uploads folders in this existing theme. Like this...

Please note in the above screenshot demo I am not displaying any existing theme files. If you are attempting this, the above demo screenshot child directory structure would be additional to your existing theme folder files.

With your production or staging database sql dump and plugins/uploads located correctly, the only thing you need to edit in your docker-compose.yml is this...

  # here is our mysql database
  db:
    image: mysql:5.7
    volumes:
#      - ./db:/var/lib/mysql:delegated (remove this and add the line below)
      - ./docker/db-dumps:/docker-entrypoint-initdb.d:delegated

This means when you docker-compose up -d, it will run the dump initially and generate the dumped sql into a new installation, deploying the database to the db folder.

Meaning if you wish to rebuild this data in your next docker-compose up -d, then you need to revert the docker-compose.yml back to my original db volume so docker rebuilds from where you left off.

Git ignore example...

As shown in my advanced dev screenshot, you will see a git ignore file. Generally this is what the git ignore file contents looks like if you are using the tech shown in my advanced dev screenshot...

/vendor
/uploads
/db
/dist
/node_modules
/plugins
/docker

这篇关于docker/wordpress:将默认插件与自己的插件分开的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆