Please provide us with the following information:

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

N/A

Any log messages given by the failure

N/A

Expected/desired behavior

Update image to support PHP 7.4

---

Thanks! We'll be in touch soon.

Please provide us with the following information:

This issue is for a: (mark with an x)

• [X ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

set DATABASE_TYPE to TRUE
Start the App with 0.52 tag

Any log messages given by the failure

2019-02-03T17:22:03.430017148Z INFO: 'mysql' database already exists under /home/data/mysql.
2019-02-03T17:22:13.804524176Z INFO: /run/mysqld not found. creating ...
2019-02-03T17:22:13.808155185Z Setting up MariaDB log dir ...
2019-02-03T17:22:13.899929415Z Starting local MariaDB ...
2019-02-03T17:22:14.898855821Z 2019-02-03 17:22:14 140625703402376 [ERROR] InnoDB: preallocating 50331648 bytes for file ./ib_logfile101 failed with error 95
2019-02-03T17:22:14.899028422Z 2019-02-03 17:22:14 140625703402376 [ERROR] InnoDB: Cannot set log file ./ib_logfile101 size to 50331648 bytes
2019-02-03T17:22:14.899175122Z 2019-02-03 17:22:14 140625703402376 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2019-02-03T17:22:15.404283489Z 2019-02-03 17:22:15 140625703402376 [ERROR] Plugin 'InnoDB' init function returned error.
2019-02-03T17:22:15.404420189Z 2019-02-03 17:22:15 140625703402376 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2019-02-03T17:22:15.566482896Z 2019-02-03 17:22:15 140625703402376 [ERROR] Unknown/unsupported storage engine: InnoDB
2019-02-03T17:22:15.566571496Z 2019-02-03 17:22:15 140625703402376 [ERROR] Aborting
2019-02-03T17:22:15.566580096Z
2019-02-03T17:22:15.654266816Z * Creating a new MySQL database ...
2019-02-03T17:22:15.654352416Z Installation of system tables failed! Examine the logs in
2019-02-03T17:22:15.654441817Z /var/lib/mysql for more information.
2019-02-03T17:22:15.654488317Z
2019-02-03T17:22:15.654557217Z The problem could be conflicting information in an external
2019-02-03T17:22:15.654603417Z my.cnf files. You can ignore these by doing:
2019-02-03T17:22:15.654669517Z
2019-02-03T17:22:15.654764517Z shell> /usr/bin/mysql_install_db --defaults-file=~/.my.cnf
2019-02-03T17:22:15.654815118Z
2019-02-03T17:22:15.654860818Z You can also try to start the mysqld daemon with:
2019-02-03T17:22:15.654915518Z
2019-02-03T17:22:15.654960018Z shell> /usr/bin/mysqld --skip-grant-tables --general-log &

Expected/desired behavior

Access via SSH run TOP:
mysql S 373m 11% 0 0% /usr/bin/mysqld --basedir=/usr --d
Access via azurewebsites.net/phpmyadmin and login with default creds.

---

Thanks! We'll be in touch soon.

This issue is for a:

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

The apache based wordpress-alpine-php images allowed custom site rules per path/url via .htaccess files.
This for example allowed us to whitelist wp-admin for certain IP's.

I'm really happy with the performance improvments in the nginx based images. But .htaccess files not working are a really big downside for us. It would be great if a custom nginx config file could be provided without creating a custom Docker image (like .htaccess allowed us).

One way to accomplish this would be to check for example /home/site/nginx-conf.d/ for config files and use them automatically.

Change made in pages from WordPress admin dashboard are not reflecting on front end.
Changes are visible when I login with the WP admin credentials but are not visible for other user (guest user)

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Run image - watch warnings.

Any log messages given by the failure

WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.

Expected/desired behavior

THP would be disabled or there would be an option to disable it. It says how to do so, but it doesn't work due to being read-only. Is there some other way to disable this permanently for an image?

Please provide us with the following information:

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

I wish I knew... the website/container eventually becomes unresponsive and requests take too long, eventually timing out. Then it starts working again until it stops again.

Any log messages given by the failure

I found the following log message troubleshooting this: ERROR - Container for sitename site sitename is unhealthy, Stopping site. Further investigation, I found a bunch of upstream timed out errors on /LogFiles/nginx/error.log: 2019/01/02 12:11:04 [error] 157#157: *4946 upstream timed out (110: Operation timed out) while reading response header from upstream, client: 172.1 9.0.1, server: _, request: "GET /privacy HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.0-fpm.sock", host: "my.site.com". I'm not sure if the above two are related or not

Expected/desired behavior

Container should be healthy and active

---

Thanks! We'll be in touch soon.

Please provide us with the following information:

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• [X ] feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

These two lines in wp-config.php will allow it to communicate over TLS 1.2 to MySQL.

/* Custom lines for MySQL TLS */
define( 'MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL );
define('MYSQL_SSL_CA_PATH','/');

---

Thanks! We'll be in touch soon.

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Expected/desired behavior

Our Wordpress app showing us critical security required update and it needs PHP 7.4. The latest version is not running PHP 7.4. Is there another version to get the PHP 7.4?

Please provide us with the following information:

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• [x ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Try setting permalinks in WP dashboard and they are overridden by settings from permalinks.txt that are added to wp-settings.php and reset to /%year%/%monthnum%/%day%/%postname%/
If permalink settings are included in a theme in functions.php or a site-functionality plugin the setting in wp-settings.php causes a 500 error

Any log messages given by the failure

PHP Fatal error: Cannot redeclare set_permalink() (previously declared in /home/site/wwwroot/wp-settings.php:507) in /home/site/wwwroot/wp-content/plugins/site-functionality/includes/post-types.php

Expected/desired behavior

Permalink settings should be able to be set via Wordpress dashboard or in functions.php as chosen by the user. wp-settings.php is a core Wordpress file that should not be modified as can cause unexpected behaviour.

---

Thanks! We'll be in touch soon.

Please provide us with the following information:

Hello! I just installed this image on a new Azure App Service and was configuring it for multiple sites.

It works great for my root site. I can add a second site, but unable to access it at all. I get nginx Redirects in my browser.

I have an open issue here:
azureappserviceoss/wordpress-azure#183

But thought maybe I would post in this GitHub as well.

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

1. Create a new App Service in Azure (linux)
2. Login to the site to ensure it works.
3. Open FTP cline and add define('WP_ALLOW_MULTISITE', true); to the wp-config.php.
4. Restart App Service
5. Log back into the site and go to tools -> Network Setup & follow the instructions
6. Added these lines to my wp-config.php:

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
define( 'DOMAIN_CURRENT_SITE', 'mytempsite.azurewebsites.net' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

(above the comment "/* That's all, stop editing! Happy blogging. */")
Note: this was the directory multisite and not the subdomain multisite.
7. Restart App Service again
8. Log in
9. The Network is setup and the second site is available (see below)

10. Clicking on the second site results in the following error:
    

Any log messages given by the failure

No

Expected/desired behavior

Ability to overwrite the Nginx config files for multi-site or that this feature is enabled out of the box.

---

Thanks! We'll be in touch soon.

Please provide us with the following information:

This issue is for a: (mark with an x)

• [x ] bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Not really a bug.

Minimal steps to reproduce

Fresh Install wordpress-alpine-php on Azure.
Finish initial setup.
Visit Site Health Page.

Any log messages given by the failure

Expected/desired behavior

Should include WP recommended PHP modules.

---

Thanks! We'll be in touch soon.

Please provide us with the following information:

This issue is for a: (mark with an x)

• [ x] bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Create an app that creates a new database in an existing 'Azure Database for MySQL server'

Any log messages given by the failure

{"code":"DeploymentFailed","message":"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-debug for usage details.","details":[{"code":"Conflict","message":"{\r\n "Code": "Conflict",\r\n "Message": "Parameter with name DATABASE_HOST already exists.",\r\n "Target": null,\r\n "Details": [\r\n {\r\n "Message": "Parameter with name DATABASE_HOST already exists."\r\n },\r\n {\r\n "Code": "Conflict"\r\n },\r\n {\r\n "ErrorEntity": {\r\n "ExtendedCode": "01013",\r\n "MessageTemplate": "Parameter with name {0} already exists.",\r\n "Parameters": [\r\n "DATABASE_HOST"\r\n ],\r\n "Code": "Conflict",\r\n "Message": "Parameter with name DATABASE_HOST already exists."\r\n }\r\n }\r\n ],\r\n "Innererror": null\r\n}"}]}

Expected/desired behavior

to start a running instance of wordpress.

---

Thanks! We'll be in touch soon.

https://social.msdn.microsoft.com/Forums/en-US/c6c524af-6806-45d1-a131-e6204d6cdc7c/unable-to-use-private-repository-from-docker-hub?forum=windowsazurewebsitespreview

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Any log messages given by the failure

Expected/desired behavior

---

Thanks! We'll be in touch soon.

It is unclear where to file this issue, see also:
Azure/wordpress-linux-appservice#63

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting

Minimal steps to reproduce

I'm using /home/dev/startup.sh to move Wordpress to a subfolder as per these instructions.

#!/bin/bash

logfile="/home/LogFiles/logfile.txt"
# Redirect all subsequent output to logfile
exec >> "$logfile"

echo "Update wp-config.php to include blog directory in WP_HOME"
sed -i "s/define('WP_HOME', \$http_protocol \. \$_SERVER\['HTTP_HOST'\]);/define('WP_HOME', \$http_protocol \. \$_SERVER\['HTTP_HOST'\] \. '\/blog\/');/" /home/site/wwwroot/wp-config.php

echo "create blog directory if it does not exist"
if [ ! -d /home/site/wwwroot/blog ]; then
    mkdir /home/site/wwwroot/blog
fi

echo "move all other files and directories to blog directory"
find /home/site/wwwroot -maxdepth 1 -not \( -name blog -o -name .htaccess -o -name index.php -o -name wwwroot \) -exec mv {} /home/site/wwwroot/blog \;

echo "copy .htaccess and index.php to blog directory"
cp /home/site/wwwroot/.htaccess /home/site/wwwroot/blog/
cp /home/site/wwwroot/index.php /home/site/wwwroot/blog/

# Close logfile
exec >&-

Any log messages given by the failure

N\A

Expected/desired behavior

And it works, for a hot minute, but then something comes along and puts all the files back at /home/site/wwwroot.

Please provide us with the following information:

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• [ x ] feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

1. Navigate to the site's /wp-admin/site-health.php page.
2. Notice the message "The optional module, intl, is not installed, or has been disabled."

The WordPress handbook recommends this module: https://make.wordpress.org/hosting/handbook/server-environment/#php-extensions . See also: https://www.php.net/manual/en/book.intl.php .

Any log messages given by the failure

The optional module, intl, is not installed, or has been disabled.

Expected/desired behavior

Include the module 'intl'.

---

Thanks! We'll be in touch soon.

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Generate high load on the server, may not always happen, I believe it is more easy to trigger when the machine first boots as opcache is not populated yet (will stuck in stat D for longer, see Observations section for more information).

Observations (The section is added by me)

• After analyzing watch-php-fpm.sh, I learnt that the script is for killing php-fpm stuck in stat D, which is probably for killing php-fpm when it is stuck in IO. However, it uses killall on php-fpm, and it is important to note that supervisord is a process manager, it starts php-fpm; php-fpm itself is also a process manager, it starts php pool workers.
• In the logs, the two important time is 04-11 21:02 and 04-12 00:40
• In the first time, from supervisord.log, php-fpm is killed by SIGKILL, presumable by watch-php-fpm.sh, supervisord tried to respawn it 4 times but all failed with error 78, that corresponds to the 4 times the stderr log reading Another FPM instance seems to already listen on /var/run/php/php-fpm.sock (searching "php-fpm error 78" will see people explaining the same about existing processes). However, there is only a small bump in Http 5xx metric, and the site remains running.
• This shows that although supervisord cannot restart php-fpm properly, in fact there is some php-fpm still running (and thus serving new visitors while blocking new php-fpm from starting).
• On the second time, supervisord.log reports nginx is killed by SIGKILL (again presumably that by shell script), this time, nothing related to php-fpm has appeared on either log because supervisord has gave up on starting it.
• But knowing the shell script sends SIGKILL to nginx and php-fpm at the same time, this log item implies that at that point the "ghosted" php-fpm (not sure if it is practically a zombie process) also received a SIGKILL. This time, without supervisord restarting php-fpm, the site is permanently entering 5xx.
• So with all the logs and above articulation, I suspect this is what happened:

1. At 04-11 21:02, watch-php-fpm.sh determined it is time to kill php-fpm and nginx as it saw php-fpm stat D for 15s.
2. In the first 0.12s of 21:02:21, each child/PHP worker process received SIGKILL, but php-fpm rapidly replaced them (thus the lines in stderr log)
3. On exactly 21:02:31,120, php master process received SIGKILL, thus the line in supervisord.log
4. For unknown reason, the master process' death does not kill the new children created in step 2
5. supervisord notice php master process' death and attempts to restart php-fpm
6. Restart of php-fpm failed continuously because the ghost php worker process is holding onto the socket, and the new php-fpm cannot access it. repeat 4 times until supervisord declares FATAL and give up monitoring
7. Site continues to run normally by the ghost php workers
8. At 04-12 00:40, the 15s of stat D happens again, nginx and php-fpm got killed, nginx is restarted by supervisord, but php-fpm is not.
9. Site is dead without php-fpm.

Any log messages given by the failure

(Only relevant section is included)
App Service Http 5xx chart (both timestamp shown by merging screenshot):

/home/LogFiles/supervisor/supervisord.log:

2020-04-11 13:10:00,063 INFO exited: php-fpm (terminated by SIGKILL; not expected)
2020-04-11 13:10:04,609 INFO spawned: 'php-fpm' with pid 71850
2020-04-11 13:10:04,610 INFO exited: nginx (terminated by SIGKILL; not expected)
2020-04-11 13:10:04,773 INFO spawned: 'nginx' with pid 71852
2020-04-11 13:10:05,902 INFO success: php-fpm entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-04-11 13:10:05,903 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-04-11 21:02:31,120 INFO exited: php-fpm (terminated by SIGKILL; not expected)
2020-04-11 21:02:31,131 INFO spawned: 'php-fpm' with pid 61102
2020-04-11 21:02:31,231 INFO exited: nginx (terminated by SIGKILL; not expected)
2020-04-11 21:02:31,253 INFO spawned: 'nginx' with pid 61104
2020-04-11 21:02:31,490 INFO exited: php-fpm (exit status 78; not expected)
2020-04-11 21:02:32,493 INFO spawned: 'php-fpm' with pid 61105
2020-04-11 21:02:32,495 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-04-11 21:02:32,566 INFO exited: php-fpm (exit status 78; not expected)
2020-04-11 21:02:34,702 INFO spawned: 'php-fpm' with pid 61154
2020-04-11 21:02:34,965 INFO exited: php-fpm (exit status 78; not expected)
2020-04-11 21:02:37,972 INFO spawned: 'php-fpm' with pid 61168
2020-04-11 21:02:38,055 INFO exited: php-fpm (exit status 78; not expected)
2020-04-11 21:02:39,058 INFO gave up: php-fpm entered FATAL state, too many start retries too quickly
2020-04-12 00:40:57,178 INFO exited: nginx (terminated by SIGKILL; not expected)
2020-04-12 00:40:57,190 INFO spawned: 'nginx' with pid 116591
2020-04-12 00:40:58,234 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-04-12 08:42:54,067 INFO exited: nginx (terminated by SIGKILL; not expected)
2020-04-12 08:42:54,078 INFO spawned: 'nginx' with pid 108374
2020-04-12 08:42:55,239 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-04-12 08:44:33,657 INFO exited: nginx (terminated by SIGKILL; not expected)
2020-04-12 08:44:33,670 INFO spawned: 'nginx' with pid 108854
2020-04-12 08:44:34,713 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2020-04-12 09:08:35,604 INFO exited: nginx (terminated by SIGKILL; not expected)
2020-04-12 09:08:36,611 INFO spawned: 'nginx' with pid 115132
2020-04-12 09:08:37,659 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

/tmp/php-fpm-stderr---supervisor-PYd1Kb.log:

- -  11/Apr/2020:21:02:12 +0000 "GET /index.php" 200
- -  11/Apr/2020:21:02:12 +0000 "GET /index.php" 200
[11-Apr-2020 21:02:31] WARNING: [pool www] child 61001 exited on signal 9 (SIGKILL) after 20.905322 seconds from start
[11-Apr-2020 21:02:31] NOTICE: [pool www] child 61095 started
[11-Apr-2020 21:02:31] WARNING: [pool www] child 61007 exited on signal 9 (SIGKILL) after 19.935792 seconds from start
[11-Apr-2020 21:02:31] NOTICE: [pool www] child 61096 started
[11-Apr-2020 21:02:31] WARNING: [pool www] child 61011 exited on signal 9 (SIGKILL) after 19.940247 seconds from start
[11-Apr-2020 21:02:31] NOTICE: [pool www] child 61097 started
[11-Apr-2020 21:02:31] WARNING: [pool www] child 61019 exited on signal 9 (SIGKILL) after 18.942026 seconds from start
[11-Apr-2020 21:02:31] NOTICE: [pool www] child 61098 started
[11-Apr-2020 21:02:31] WARNING: [pool www] child 61020 exited on signal 9 (SIGKILL) after 18.943544 seconds from start
[11-Apr-2020 21:02:31] NOTICE: [pool www] child 61099 started
[11-Apr-2020 21:02:31] WARNING: [pool www] child 61021 exited on signal 9 (SIGKILL) after 18.944947 seconds from start
[11-Apr-2020 21:02:31] NOTICE: [pool www] child 61100 started
[11-Apr-2020 21:02:31] ERROR: Another FPM instance seems to already listen on /var/run/php/php-fpm.sock
[11-Apr-2020 21:02:31] ERROR: Another FPM instance seems to already listen on /var/run/php/php-fpm.sock
[11-Apr-2020 21:02:31] ERROR: FPM initialization failed
[11-Apr-2020 21:02:31] ERROR: FPM initialization failed
[11-Apr-2020 21:02:32] ERROR: Another FPM instance seems to already listen on /var/run/php/php-fpm.sock
[11-Apr-2020 21:02:32] ERROR: Another FPM instance seems to already listen on /var/run/php/php-fpm.sock
[11-Apr-2020 21:02:32] ERROR: FPM initialization failed
[11-Apr-2020 21:02:32] ERROR: FPM initialization failed
[11-Apr-2020 21:02:34] ERROR: Another FPM instance seems to already listen on /var/run/php/php-fpm.sock
[11-Apr-2020 21:02:34] ERROR: Another FPM instance seems to already listen on /var/run/php/php-fpm.sock
[11-Apr-2020 21:02:34] ERROR: FPM initialization failed
[11-Apr-2020 21:02:34] ERROR: FPM initialization failed
[11-Apr-2020 21:02:38] ERROR: Another FPM instance seems to already listen on /var/run/php/php-fpm.sock
[11-Apr-2020 21:02:38] ERROR: Another FPM instance seems to already listen on /var/run/php/php-fpm.sock
[11-Apr-2020 21:02:38] ERROR: FPM initialization failed
[11-Apr-2020 21:02:38] ERROR: FPM initialization failed

Expected/desired behavior

(More of proposed solution)
Since php-fpm master process is itself a process manager, the script should not simultaneously kill PHP master and worker process. I believe the better way is to only kill worker, since as mentioned php-fpm is a process manager, so killing children will make master process restart them anyway.

Furthermore, the script is little bit overkill, there is no reason to kill all php-fpm if only one worker process is stuck in stat D, so it would be even better if the script can track worker process individually, and only kill those with stat D (as tested, master process seems will not enter stat D).

Also, Killing nginx seems be unnecessary (correct me if I am wrong)

---

Thanks! We'll be in touch soon.

This issue is for a: (mark with an x)

• [x ] bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

The php.ini contains a comment that uses # instead of ; to start the comment line, which means that php rejects the configuration from the php.ini. You can verify this by calling phpinfo(), and see that upload_max_filesize for example is 2M rather than 20M as specified in the .ini. This is because # is no longer supported as of php 7, so this would have been acceptable in php 5.x

Any log messages given by the failure

Does not throw an error, but phpinfo() will show default settings instead

Expected/desired behavior

upload_max_filesize for example is 20M rather than 2M as specified in the .ini, as with other settings in the .ini

---

Thanks! We'll be in touch soon.

Please provide us with the following information:

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Normal usage. The logs grow to an unbounded size, which eventually causes site slowdown if logs ever grow > 500MB in size. This has been observed by customers with php-error.log files in excess of 500MB.

Any log messages given by the failure

None. Lack of log rotation causes performance slowdown.

Expected/desired behavior

Speedy write to log files all the time.

---

Thanks! We'll be in touch soon.

Update this statement https://github.com/Azure/app-service-quickstart-docker-images/blob/master/wordpress-alpine-php/0.51/Dockerfile#L4
FROM leonzhang77/alpine-php-mysql:0.31

• bug
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Expected/desired behavior

I couldn't see wordpress alpine for PHP 7.4, is there any ticket for this, or am I missing an already in place version?

---

Thanks! We'll be in touch soon.

Please provide us with the following information:

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• [ x ] feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

phpinfo()

Any log messages given by the failure

Expected/desired behavior

The current version of PHP in the image is 8.0.28. Please update to the latest 8.2.

---

Thanks! We'll be in touch soon.

Please provide us with the following information:

Description

The entrypoint.sh#L251 provides a mechanism for overriding the nginx config. However, this seems to require the customer to provide the entire nginx config folder, instead of allowing them to override specific files.

Also, the README mentions something about this, but these changes will be lost when deploying to Azure.

In my opinion, this is difficult to understand and use -- even when building a custom image that uses this as the base.

This is related to #179 and #264.

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Try to load a custom nginx.conf from docker-compose.yml

version: '3'
services:
drupal:
 image: drupal-nginx-fpm:0.51
 volumes:
    - ./nginx.conf:/home/etc/nginx/nginx.conf

Any log messages given by the failure

Docker logs

2019-03-05 18:45:51,243 INFO exited: nginx (exit status 1; not expected)

Testing the nginx.conf file

$ nginx -t -c /etc/nginx/nginx.conf
nginx: [emerg] open() "/etc/nginx/mime.types" failed (2: No such file or directory) in /etc/nginx/nginx.conf:16
nginx: configuration file /etc/nginx/nginx.conf test failed

Expected/desired behavior

Expected behavior: the container runs normally with my custom nginx.conf
Observed behavior: nginx fails to load because of the error above

---

Thanks! We'll be in touch soon.

Please provide us with the following information:

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Can you please update the NGINX and PHP versions. These seem to not have been updated in a while

Minimal steps to reproduce

HTTP header inspection

Any log messages given by the failure

Expected/desired behavior

---

Thanks! We'll be in touch soon.

This issue is for a: (mark with an x)

• [X ] bug report -> please search issues before submitting
• [X ] feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Use the current 0.8 image on Azure

Expected/desired behavior

Should be updated to the latest version of php etc.

Please provide us with the following information:

This issue is for a: (mark with an x)

• [ X] bug report -> please search issues before submitting
• [ X] feature request

Minimal steps to reproduce

Any log messages given by the failure

1. set image to appsvcorg/wordpress-alpine-php:0.9
2. set WEBSITES_ENABLE_APP_SERVICE_STORAGE=TRUE
3. FTP in to storage
4. edit the d.conf
5. SSH in to container and run:
   nginx -s reload
   nginx -T
6. none of the edits from clause 4 are updated .
   I also tried 0.72 and edit the server block to block:
   location /wp-admin/ {
   real_ip_header X-Forwarded-For;
   allow
   real_ip_recursive on;
   set_real_ip_from 0.0.0.0/0;
   deny all;
   include fastcgi.conf;
   fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
   }
   when trying to brows site http://.azurewebsites.net/wp-admin
   I get "file not found" however other IP will get 403 forbidden.
   This suggests that the IP whitelisting is working but another route is preventing me from accessing

Expected/desired behavior

Need to block the wp-admin and wp-login

---

Thanks! We'll be in touch soon.

Please provide us with the following information:

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• [x ] feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)
  drupal-nginx-fpm/0.51

Minimal steps to reproduce

No way of changing varnish header size.Varnish has a max header size of 8kb. If too many blocks are added then this can crash varnish by creating a X varnish block cache header > 8kb. If this many blocks really are needed then http_resp_hdr_len and http_req_hdr_len needs to be boosted in varnish. However there is no way of setting this automatically on container start.

Any log messages given by the failure

Expected/desired behavior

Version - drupal-nginx-fpm/0.51

Should be able to change configuration options by for example passing in a "command" from docker-compose.yml, however currently the provided entrypoint.sh does not wait for commands otherwise could pass in " command: varnishadm param.set http_resp_hdr_len 16kb" etc as well as to override other container settings.

---

Thanks! We'll be in touch soon.

Please provide us with the following information:

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Can you please let me know the steps to update the Drupal core from 8.7.2 to 8.8. The one mentioned in https://github.com/azureappserviceoss/drupalcms-composer-azure#updating-drupal-core contradicts the one mentioned here https://www.drupal.org/docs/8/update/update-core-via-composer#s-special-considerations-for-upgrading-to-drupal-880-and-later (In the official drupal website it is said to remove the webflo/drupal-core-require-dev and there is one code line update in the settings.php). I tried using the steps given here but had issues. Can someone please let me know the exact steps in Azure.

Any log messages given by the failure

One of the error we found is that -

• drupal/core-recommended 8.8.0 requires composer/installers v1.7.0 -> satisfiable by composer/installers[v1.7.0].

Expected/desired behavior

---

Thanks! We'll be in touch soon.

Please provide us with the following information:

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• [X ] feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Expected/desired behavior

Overview of the Issue - request to include letsencrypt / certbot
Version - appsvcorg/wordpress-alpine-php:0.61
Motivation for or Use Case - there seems to be an absence of ability to use certbot with Azure WordPress on Linux service
Browsers and Operating System - N/A
Reproduce the Error - N/A
Related Issues - I have searched archive and found no mention
Suggest a Fix - sorry I don't have the skills to suggest the method of solving this, otherwise I'd have a go myself

---

Thanks! We'll be in touch soon.

Please provide us with the following information:

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Attempting to SSH via Azure webssh into quick start image for multi-container wordpress (appsvcorg/nginx-multi-container:0.1-wordpress-fpm) via docker-compose (with no changes to the given docker-compose template) doesn't work.

Any log messages given by the failure

SSH CONNECTION CLOSE - Error: connect ECONNREFUSED 172.23.0.4:2222

Expected/desired behavior

SSH connections should work out the box for Azure quickstart images

---

Thanks! We'll be in touch soon.

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

Please provide us with the following information:

This issue is for a: (mark with an x)

• [x ] bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

set WEBSITES_ENABLE_APP_SERVICE_STORAGE=true

Any log messages given by the failure

HTTP Error 500 in Browser

Expected/desired behavior

200 OK

Using wordpress-alpine-php version 0.8 but I think same issue is with version 0.9.

Please provide us with the following information:

This issue is for a: (mark with an x)

• [ X] bug report -> please search issues before submitting
• [ X] feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

After the upgrade from 0.3 to 0.52 fileinfo extension no longer included.

Any log messages given by the failure

fileinfo extension isn’t loaded
mime_content_type() function doesn’t exist

Expected/desired behavior

The wordpress-alpine-php 0.3 includes the fileinfo extension of PHP. Because I need the 0.52 (php 7.28 and Apache) I would like to ask if you can add it in the Dockerimage-->0.52.

---

Thanks! We'll be in touch soon.

Image: appsvcorg/wordpress-alpine-php:0.72

bash-4.4# apk update
fetch http://dl-cdn.alpinelinux.org/alpine/v3.8/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.8/community/x86_64/APKINDEX.tar.gz
fetch http://nl.alpinelinux.org/alpine/edge/testing/x86_64/APKINDEX.tar.gz
v3.8.5-66-gccbd6a8ae7 [http://dl-cdn.alpinelinux.org/alpine/v3.8/main]
v3.8.5-66-gccbd6a8ae7 [http://dl-cdn.alpinelinux.org/alpine/v3.8/community]
v20210212-4793-g016d368ff3 [http://nl.alpinelinux.org/alpine/edge/testing]
OK: 14146 distinct packages available
bash-4.4# apk add nginx-mod-http-headers-more
(1/2) Installing nginx (1.14.2-r2)
Executing nginx-1.14.2-r2.pre-install
(2/2) Installing nginx-mod-http-headers-more (1.14.2-r2)
ERROR: Failed to create etc/nginx/modules/http_headers_more.conf: No such file or directory
ERROR: nginx-mod-http-headers-more-1.14.2-r2: failed to rename etc/nginx/modules/.apk.46295575474603d6290409e1105fca8414cb2c4b442d0aaf to etc/nginx/modules/http_headers_more.conf.
Executing busybox-1.28.4-r3.trigger
1 error; 145 MiB in 102 packages
bash-4.4# pwd
/home/etc/nginx
bash-4.4# ls -l modules
lrwxrwxrwx 1 root root 27 Apr 8 12:38 modules -> ../../usr/lib/nginx/modules
bash-4.4# cd modules
bash: cd: modules: No such file or directory

bash-4.4# ls /usr/lib/nginx/modules
ngx_http_geoip_module-debug.so ngx_http_headers_more_filter_module.so ngx_http_image_filter_module.so ngx_http_xslt_filter_module.so ngx_stream_geoip_module.so
ngx_http_geoip_module.so ngx_http_image_filter_module-debug.so ngx_http_xslt_filter_module-debug.so ngx_stream_geoip_module-debug.so

Please provide us with the following information:
Trying to setup webp support with smush pro, it requires nginx settings to be added, /etc/nginx is different from /home/etc/nginx during the startup. Even reloading nginx with the proper settings it doesn't seem to serve the webp files correctly.

#179

block that needs to be added:

# BEGIN SMUSH-WEBP
location ~* "/home/site/wwwroot/wp-content/(uploads/)(.*.(?:png|jpe?g))" {
    add_header Vary Accept;
    set $image_path $2;
    if (-f "/home/site/wwwroot/wp-content/smush-webp/disable_smush_webp") {
        break;
    }
    if ($http_accept !~* "webp") {
        break;
    }
    try_files /home/site/wwwroot/wp-content/smush-webp/$image_path.webp $uri =404;
}
# END SMUSH-WEBP

during the app restart these are removed every time.

This issue is for a: (mark with an x)

• [ x ] bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

during the app restart the files from /home/etc/nginx aren't replacing the ones in /etc/nginx

Any log messages given by the failure

no errors as the config is loaded as expected, but the changes aren't reflected even after validating that /usr/sbin/nginx -T shows the expected settings but the rule still isn't loaded properly

Expected/desired behavior

Nginx custom settings should persist after restart.

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Description
We have deployed a docker container with a FastAPI backend, that uses Azure OpenAI service to generate streaming responses.
It's used as a part of a larger setup with a frontend to enable users to interact with OpenAI LLM's.
When running to FastAPI locally it works as intended and streams the response, but when deploying to Azure Web App it does not.

Minimal steps to reproduce

1. Setup Azure Web App
2. Setup simple FastAPI app with a streamingresponse endpoint
3. Deploy simple FastAPI app in docker container to Azure Web App
4. Send a request to endpoint

Any log messages given by the failure

Logs seem to behave as intended, it looks like it's actually performing the streaming steps, however no payload is returned until it finishes.

Expected/desired behavior

Expects a streaming response, but waits for the entire payload.
Screenshots
Examples of local behavior vs Azure web app:
Local streaming, indicating the number of chunks/elements recieved:

Now using the same request, but sending to the Azure Web App(contains multiple elements, but in one chunk):

Select Web App settings:

"kind": "app,linux,container",
    "siteConfig": {
        "numberOfWorkers": 1,
         "linuxFxVersion": "DOCKER|<REPO>/<IMAGE>",,
        "acrUseManagedIdentityCreds": false,
        "alwaysOn": true,
        "http20Enabled": true,
        "functionAppScaleLimit": 10,
        "minimumElasticInstanceCount": 2
    },

Docker image:

FROM python:3.10-alpine3.19

WORKDIR /app

RUN pip install -U pip setuptools wheel
RUN pip install poetry

COPY ./ /
RUN poetry install --no-dev
ENTRYPOINT ["poetry","run","gunicorn","-w","4","-k","uvicorn.workers.UvicornWorker","--timeout","600","app:app"]

Poetry dependencies:

python = "^3.10"
pytest = "^7.4.3"
azure-identity = "^1.15.0"
openai = "0.28"
asynctest = "^0.13.0"
uvicorn = "^0.24.0.post1"
fastapi = "0.110.1"
httpx = "^0.25.1"
fastapi-azure-auth = "^4.3.0"
pydantic = "^2.5.2"
pydantic-settings = "^2.1.0"
nanoid = "^2.0.0"
tiktoken = "^0.5.1"
python-dotenv = "^1.0.0"
pytest-cov = "^4.1.0"
pytest-azurepipelines = "^1.0.5"
flake8 = "^6.1.0"
autopep8 = "^2.0.4"
azure-cosmos = "^4.5.1"
azure-keyvault-secrets = "^4.7.0"
applicationinsights = "^0.11.10"
pytest-rerunfailures = "^13.0"
cryptography = "42.0.4"
aiohttp = "3.9.4"
idna = "3.7"
gunicorn = "^22.0.0"

---

Thanks! We'll be in touch soon.

Please provide us with the following information:

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Try to SSH to the container

Any log messages given by the failure

docker file missing following step compared to version 0.46

ssh

COPY sshd_config /etc/ssh/

Expected/desired behavior

SSH connection successful

---

Thanks! We'll be in touch soon.

should be /var/run ....

Please provide us with the following information:

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• feature request
• [X ] documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

How to set max_input_vars/php memory limit if php.ini is reset after each reset? Where is the correct places to set these values?

Any log messages given by the failure

limits are not retained and are set to default values.

Expected/desired behavior

WP memory limit updates fine via wp-config, but after restart any configuration changes made in php.ini is reset.

---

Thanks! We'll be in touch soon.

Hey,

I am writing to ask your support regarding your image which is used by me on a WebApp for Containers in Azure. When more than 30 requests arrives to Wordpress you receive the following message: error

The site is not stable. Uptime is around 5% due to nginx issue.

App Service plan (Linux): B1, B2, S1, etc.
Container settings: appsvcorg/wordpress-alpine-php:0.72

This issue is for a: (mark with an x)

• bug report
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

1. When more than 30 requests arrives to Wordpress you receive the following message: error
2. You can find the following lines in "/api/vfs/LogFiles/nginx/php-error.log":

[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 958
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 959
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 960
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 961
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 962
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 965
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 966
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 969
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 970
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 971
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 972
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 975
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 976
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 977
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 978
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 981

Any log messages given by the failure

You can find the following lines in "/api/vfs/LogFiles/nginx/php-error.log":

[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 958
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 959
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 960
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 961
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 962
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 965
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 966
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 969
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 970
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 971
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 972
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 975
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 976
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 977
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 978
[15-Jul-2019 13:48:55 UTC] PHP Warning:  Cannot modify header information - headers already sent in /home/site/wwwroot/wp-includes/pluggable.php on line 981

Expected/desired behavior

WebApp for Container is as stable as than Windows Web App

---

Thanks! We'll be in touch soon.

Container run fails after enabling WEBSITES_ENABLE_APP_SERVICE_STORAGE.
Version: drupal-nginx-fpm/0.6

Please provide us with the following information:

This issue is for a: (mark with an x)

• [ X] bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Deploy app-service-quickstart-docker-images/drupal-nginx-fpm/0.6 and after that enable WEBSITES_ENABLE_APP_SERVICE_STORAGE (true)

Any log messages given by the failure

2019-10-07 23:59:51.788 ERROR - Container drupal-custom-ngnix_0_d6a4a19d for site drupal-custom-ngnix has exited, failing site start
2019-10-07 23:59:51.790 ERROR - Container drupal-custom-ngnix_0_d6a4a19d didn't respond to HTTP pings on port: 80, failing site start. See container logs for debugging.

Expected/desired behavior

Site Deploys

Cause of error:

2019-10-07T23:59:50.902948007Z + mv /home/drupal_prj/home/bak/drupal_prj_bak1570492790
2019-10-07T23:59:50.905188984Z mv: can't rename '/home/drupal_prj': No such file or directory

setup_drupal(){ while test -d "$DRUPAL_PRJ" do echo "INFO: $DRUPAL_PRJ is exist, clean it ..." # mv is faster than rm. mv $DRUPAL_PRJ /home/bak/drupal_prj_bak$(date +%s) done

This assumes '/home/bak' directory exists, but that´s not the case.

else
### drupal isn't installed, fresh start
    echo "Installing Drupal ..."    
    setup_drupal   
fi

A few lines down that directory is created, which really doesn´t make sense, if it doesn´t exist you get an error before reaching this point. The "mkdir -p /home/bak" should be at the begining of the function.

if [ $DATABASE_USERNAME ]; then
        #cd $DRUPAL_PRJ/web/core/lib/Drupal/Core/Database/Installing
        echo "INFO: Setting of DATABASE ..."
        mkdir -p /home/bak

FIX:

setup_drupal(){
    while test -d "$DRUPAL_PRJ"  
    do
        # nothing wrong with mkdir if it hasnt been created
        mkdir -p /home/bak
        echo "INFO: $DRUPAL_PRJ is exist, clean it ..."
        # mv is faster than rm.    
        mv $DRUPAL_PRJ /home/bak/drupal_prj_bak$(date +%s)
    done

Currently the nginx configuration is able to be persisted between server restarts. The php-fpm configuration is not persistent. Is it possible to make the php-fpm configuration persist between restarts of the appservice?

This issue is for a:

• bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

1. Create a new Azure wordpress for Linux web app (and new MySQL database)

2. When the Web App is ready ready open the Site to install wordpress

3. When installation has finished enforce SSL under Web App setting

4. Attempt to login to wp-admin
   Observer: user is redirected back to the login screen instead of the admin page

5. disable enforce SSL

6. Login to wp-admin over http

7. change the URL to https
   Observe: some of the scripts are not loaded
   
   ](url)

8. Sign out of wp-admin and view the home page over https.
   Observer: Some of the scipts are not loaded. [
   

Any log messages given by the failure

Some script and css files are marked as unsecure

Expected/desired behavior

After configured a domain and enabling SSL in Azure Web App wordpress should load over SSL on hte configured domain.

Hello,

This issue is for a: (mark with an x)

• bug report -> please search issues before submitting
• [x ] feature request
• [x ] documentation issue or request
• [x ] regression (a behavior that used to work and stopped in a new release)

Any log messages given by the failure

Why are you using nginx since version 0.6 ?
A lot of work have been doing on this image using apache. Nginx can break a lot of optimisation work...

Expected/desired behavior

Maybe you should branch this and call it wordpress-alpine-php-apache and wordpress-alpine-php-nginx

Thanks

Please provide us with the following information:

This issue is for a: (mark with an x)

• [ x] bug report -> please search issues before submitting
• feature request
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

docker build . for the Dockerfile of version 0.72

Any log messages given by the failure

Step 18/32 : COPY sshd_config /etc/ssh/
COPY failed: file not found in build context or excluded by .dockerignore: stat sshd_config: file does not exist

Expected/desired behavior

A docker image

---

Thanks! We'll be in touch soon.

Version 0.8 is also failing with this error:
Step 16/23 : COPY wordpress_src/. $WORDPRESS_SOURCE/
COPY failed: file not found in build context or excluded by .dockerignore: stat wordpress_src/.: file does not exist