WordPress CSS Not loading - css

trying to install a fresh WordPress Install using Docker Compose. I'm using AWS EC2 with a ELB
Everything looks fine on logs but once I access to my site I got no css loaded, see the screen :
no css
And the network error :
enter image description here
Here is my docker-compose :
version: "3"
services:
wordpress:
image: conetix/wordpress-with-wp-cli
ports:
- 80:80
restart: always
environment:
- WORDPRESS_DB_HOST=namehostwp
- WORDPRESS_DB_USER=nameuserwp
- WORDPRESS_DB_PASSWORD=passworddbwp
- WORDPRESS_DB_NAME=namedbwp
volumes:
- ./wp_data:/var/www/html
This image is wordpress and wp cli.
Then I run :
docker exec <container id> wp core install --path="/var/www/html" --url="http://nomdomaine" title="Example" --admin_user=supervisor --admin_password=strongpassword --admin_email=info#example.com
Install went well, and in wp-config I got the good dbhost, dbuser, dbpw and dbname
All files seems ok
plugins ok
I dont know what to do.. thx for any help / tips
EDIT : stylesheet url : stylesheet

It looks like you haven't properly configured your domain name and as result the css file can not be loaded. That's what your error ERR_NAME_NOT_RESOLVED means

Related

Running dotnet watch run in docker container breaks Nuget package references

I have a docker-compose file where I start the database and the asp.net server with dotnet watch run like this:
backend:
image: mcr.microsoft.com/dotnet/sdk:6.0
depends_on:
- db
environment:
DB_HOST: db
DB_NAME: db
DB_USERNAME: ${DB_USER}
DB_PASSWORD: ${DB_PW}
ASPNETCORE_ENVIRONMENT: Development
ports:
- 7293:7293
volumes:
- ./:/app
working_dir: /app
command: 'dotnet watch run --urls "http://0.0.0.0:7293"'
As you can see I mount the entire project directory in the container.
Now this runs fine and reloads on changes.
But as soon as the container starts in Visual Studio all the references to Nuget packages get marked red and can't be resolved anymore.
There is a .dockerignore file but I don't think anything in here is really relevant. But here is it anyways:
.dockerignore:
**/.classpath
**/.dockerignore
**/.env
**/.git
**/.gitignore
**/.project
**/.settings
**/.toolstarget
**/.vs
**/.vscode
**/*.*proj.user
**/*.dbmdl
**/*.jfm
**/azds.yaml
**/bin
**/charts
**/docker-compose*
**/Dockerfile*
**/node_modules
**/npm-debug.log
**/obj
**/secrets.dev.yaml
**/values.dev.yaml
LICENSE
README.md
I know this has something to do with project restore but nothing I tried helped. --no-restore made it just not run at all with an exception that it couldn't find the reference to one of the packages.
Any ideas how to avoid this?
Ok I figured it out. Mounting Apperently doesn't care about .dockerignore. I have to exclude the obj directory in the mount. So I just mount a empty directory like this.
backend:
...
volumes:
- ./:/app
- /app/obj # <- directory won't be mounted
working_dir: /app
command: 'dotnet watch run --urls "http://0.0.0.0:7293"'

How do I see what a docker container that doesn't stay running is doing/tried to do?

I'm trying to use the WordPress local development environment, which sets up a bunch of docker containers (and I'm new to Docker). One of them is a WordPress CLI, which I presume is running some scripts to do some configuration, but that particular container doesn't stay running (I believe this is intentional). I'm guessing that a script it's running is failing, and that's happening because of some configuration error, but I can't figure out how to tell what it's doing when it executes (what scripts it's running, what environment variables are set, etc...).
Is there any way to somehow "trace" what the container is trying to do?
$docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
wordpressdevelop/phpunit latest 8ebb6f73d762 2 days ago 732MB
wordpress latest 6c2c086d9173 2 days ago 554MB
wordpress <none> 408627ce79b1 2 days ago 551MB
composer latest ff854871a595 9 days ago 173MB
wordpress cli ee6de7f71aa0 9 days ago 137MB // I want to see what this does
mariadb latest e27cf5bc24fe 12 days ago 401MB
$docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
19007b991e08 wordpress "docker-entrypoint.s…" 48 minutes ago Up 48 minutes 0.0.0.0:8888->80/tcp e6bc9159b910bda3d9b0dae2e230eabd_wordpress_1
26ac5c7ec782 wordpress "docker-entrypoint.s…" 48 minutes ago Up 48 minutes 0.0.0.0:8889->80/tcp e6bc9159b910bda3d9b0dae2e230eabd_tests-wordpress_1
8ae0a4dc4f77 mariadb "docker-entrypoint.s…" 48 minutes ago Up 48 minutes 0.0.0.0:54989->3306/tcp e6bc9159b910bda3d9b0dae2e230eabd_mysql_1
This is on MacOS 11.2.2 running Docker Desktop, Docker version 20.10.5.
I'm not sure if it's relevant, but for completeness' sake, I've included the docker-compose.yml which wp-env generates, below.
Thanks!
Background
This used to Just Work, but I think I broke something in my environment, and am trying to diagnose that. I initially asked about that on WordPress StackExchange, but have since dug deeper. The Docker compose step fails thusly:
...
⠏ Configuring WordPress.Creating e6bc9159b910bda3d9b0dae2e230eabd_cli_run ... done
⠹ Configuring WordPress.mysqlcheck: Got error: 1045: Access denied for user 'username_here'#'172.19.0.5' (using password: YES) when trying to connect
The database container is left up and running, and if I go look in the database, I see it's configured to have root connect with no password:
MariaDB [(none)]> select user, host, password from mysql.user;
+-------------+-----------+----------+
| User | Host | Password |
+-------------+-----------+----------+
| mariadb.sys | localhost | |
| root | localhost | |
| root | % | |
+-------------+-----------+----------+
3 rows in set (0.003 sec)
In the main WordPress container, the wp-config.php file contains this little snippet:
...
// a helper function to lookup "env_FILE", "env", then fallback
function getenv_docker($env, $default) {
if ($fileEnv = getenv($env . '_FILE')) {
return file_get_contents($fileEnv);
}
else if ($val = getenv($env)) {
return $val;
}
else {
return $default;
}
}
...
/** MySQL database username */
define( 'DB_USER', getenv_docker('WORDPRESS_DB_USER', 'username_here') );
/** MySQL database password */
define( 'DB_PASSWORD', getenv_docker('WORDPRESS_DB_PASSWORD', 'password_here') )
Given the error message, I assume the CLI container is trying to do something similar, but the environment variables WORDPRESS_* aren't set, and so it's using the defaults, which ... aren't working. What I think I need to do is track down something that's failing to set those variables earlier in the run process.
docker-compose.yml
version: '3.7'
services:
mysql:
image: mariadb
ports:
- '3306'
environment:
MYSQL_ALLOW_EMPTY_PASSWORD: 'yes'
volumes:
- 'mysql:/var/lib/mysql'
wordpress:
build: .
depends_on:
- mysql
image: wordpress
ports:
- '${WP_ENV_PORT:-8888}:80'
environment:
WORDPRESS_DB_NAME: wordpress
volumes: &ref_0
- 'wordpress:/var/www/html'
- '/Users/cwr/src/cwra/foo:/var/www/html/wp-content/plugins/foo'
tests-wordpress:
depends_on:
- mysql
image: wordpress
ports:
- '${WP_ENV_TESTS_PORT:-8889}:80'
environment:
WORDPRESS_DB_NAME: tests-wordpress
volumes: &ref_1
- 'tests-wordpress:/var/www/html'
- '/Users/cwr/src/cwra/foo:/var/www/html/wp-content/plugins/foo'
cli:
depends_on:
- wordpress
image: 'wordpress:cli'
volumes: *ref_0
user: '33:33'
tests-cli:
depends_on:
- tests-wordpress
image: 'wordpress:cli'
volumes: *ref_1
user: '33:33'
composer:
image: composer
volumes:
- '/Users/cwr/src/cwra/foo:/app'
phpunit:
image: 'wordpressdevelop/phpunit:latest'
depends_on:
- tests-wordpress
volumes:
- 'tests-wordpress:/var/www/html'
- '/Users/cwr/src/cwra/foo:/var/www/html/wp-content/plugins/foo'
- 'phpunit-uploads:/var/www/html/wp-content/uploads'
environment:
LOCAL_DIR: html
WP_PHPUNIT__TESTS_CONFIG: /var/www/html/phpunit-wp-config.php
volumes:
wordpress: {}
tests-wordpress: {}
mysql: {}
phpunit-uploads: {}
docker logs could help you here as it is also showing logs of exited containers (Source).
UPDATE: Acc. to the OP, the actual issue is still unclear but starting with a fresh docker & node installation did the trick & got wp-env running.

how to redirect no-www to www under jwilder/nginx-proxy?

I use nginx docker(https://github.com/jwilder/nginx-proxy), but find it no way to amend .htaccess as mentioned here(Nginx no-www to www and www to no-www). Could anyone tell me how to redirect no-www to www under the above jwilder/nginx-proxy.
This may be a little late but I found the solutions here to be too much faffing, so I created the adamkdean/redirect lightweight companion service for jwilder/nginx-proxy.
The example below simply shows HTTP but you can hook this up to HTTPS if you like using the letsencrypt-nginx-proxy companion service by JrCs.
For adamkdean/redirect, you simply provide two environment vars, one of the redirect location and one of the status code (which can be either 301, 302, 303, or 307) with the default being 307 (if you omit REDIRECT_STATUS_CODE).
version: '2'
services:
nginx-proxy:
image: jwilder/nginx-proxy
ports:
- 80:80
volumes:
- /var/run/docker.sock:/tmp/docker.sock:ro
redirect:
image: adamkdean/redirect
environment:
- VIRTUAL_HOST=example.com
- REDIRECT_LOCATION="http://www.example.com"
- REDIRECT_STATUS_CODE=301
example:
image: example
environment:
- VIRTUAL_HOST=www.example.com
Find the repo here: https://github.com/adamkdean/redirect
You would need to:
git clone https://github.com/jwilder/nginx-proxy,
amend nginx.tmpl and
rebuild the nginx-proxy image yourself.
That way, you would generate a new nginx-proxy image which does include the directives you need.
You can add the redirect without changing the nginx.tmpl. There is the option to import further configuration files either directly under server { or in the default location location / {. See https://github.com/jwilder/nginx-proxy#per-virtual_host.
Create and mount a file /etc/nginx/vhost.d/your-website.com or /etc/nginx/vhost.d/your-website.com_location with the following content:
rewrite ^/(.*)$ http://www.your-website.com/$1 permanent;
Introduction
Unfortunately you did not specify your technical setup.
So i do have to make some assumptions.
Let's assume that you want to start a blog using a fully supported docker environment with following docker images:
nginx-proxy,
docker-gen,
letsencrypt,
ghost (blog software) and
mariaDB.
Therefore you registered a domain with the name personalblog.com.
You already set up an DNS A record to the IP address where your blog content will be hosted. So you have an A record for personalblog.com to that IP address and an A record for www.personalblog.com to that IP address.
Requirements
Please follow the instructions to setup your nginx-proxy with letsencrypt environment (you will find in these repositories a full instruction for setup):
https://github.com/evertramos/docker-compose-letsencrypt-nginx-proxy-companion
After finishing the nginx-proxy setup for docker, please follow these instructions for setup your blog software with ghost and maria db:
https://github.com/LuisArteaga/docker-ghost-mariadb-letsencrypt
There might be a docker bug when pulling the latest image for ghost. So change in the docker-compose.yml ghost:latest to ghost:1.22.1
Redirect non-www to www for jwilder/nginx-proxy
In the nginx-proxy setup (described by #evertramos repository above) you specified in the .env file your Nginx File Path (Check out the line with NGINX_FILES_PATH=/path/to/your/nginx/data). With this you created a directory outside of the nginx docker container.
Step 1
cd /path/to/your/nginx/data/vhost.d/
sudo vim personalblog.com
Step 2
In the new file personalblog.com you add following line:
return 301 http://www.personalblog.com$request_uri;
Save the file with ESC and :wq
Step 3
Go to your path where your docker-compose.yml for nginx lies and do:
sudo docker-compose up -d --force-recreate
Notes
The file that you are creating under /path/to/your/nginx/data/vhost.d/ has to be the name of your domain. In this case you want to redirect from personalblog.com to www.personalblog.com, so the file name is personalblog.com. If you followed the instructions of the repositories above you will automatically redirected to https. So don't worry if you just redirect to http://www.personalblog.com.
Don't forget to update the variable VIRTUAL_HOST to have both the www and non-WW hostname:
VIRTUAL_HOST=www.target-host.com, target-host.com
First you need to clone git using: https://github.com/jwilder/nginx-proxy
Then amend it using nginx.tmpl and at last rebuild it using nginx-proxy image yourself.

Container command could not be invoked

Just encountered this error message while trying to bring up a docker-compose stack on my local machine. I have a Dockerfile which is identical to the official Wordpress image. My docker-compose file looks like this:
wordpress:
image: joystick/wp
ports:
- "8000:80"
links:
- wordpress_db:mysql
environment:
- WORDPRESS_DB_HOST=mysql
- WORDPRESS_DB_NAME=wordpress
- WORDPRESS_DB_USER=admin
- WORDPRESS_DB_PASSWORD=password
wordpress_db:
image: tutum/mysql
environment:
- ON_CREATE_DB=wordpress
- MYSQL_PASS=password
When I change the "image" part at the beginning of this to "wordpress" and use the official image, everything comes up as I'd expect. But when I try to build my own image first, and then use it in this docker-compose file, I get the error message "Container command could not be invoked".
I tried adding a "command" node into the "wordpress" section of this docker-compose, but that did not work.
If you're building from official images, e.g. https://github.com/docker-library/wordpress/tree/master/apache, note the file docker-entrypoint.sh. It must be executable, I set 755 and managed to build the image and run the container.

Lucee 5, Nginx, and Docker Compose not finding sample index.cfm file

I have set up a fairly vanilla Dockerfile to start with, just to see if I can get the sample index.cfm to run:
FROM lucee/lucee-nginx:preview
And the related docker-compose.yml file:
web:
build: .
ports:
- "80:80"
When I run this, I get an Nginx 403 Forbidden error. If I change the ports setting to 80:8080, I get a Tomcat 404 Not Found error.
I'm lost as to how to get this working with Docker Compose. How can I debug this, or is there a different way that I can configure Docker Compose to get it running?
The newer builds of Lucee 5 work (release candidates especially), so this problem has since "sorted itself out."
See the section of the lucee-dockerfiles project for Lucee 5 on Tomcat-8-jre with Nginx.

Resources