Hey there, just as a basic security precaution, it's probably good to deny all to common dot files and config associated with WordPress. I'd suggest just a small addition that should cover most cases:

To only cover the obvious ones:

location ~* \.(htaccess|conf|ini|log)$ {
    deny all;
}

Hi please add vhost Blesta

can anyone make a vhosts config from this .htacess?

RewriteEngine On
RewriteCond %{SCRIPT_FILENAME} !-d
RewriteCond %{SCRIPT_FILENAME} !-f
RewriteRule ^([A-Za-z0-9-]+)/?$ index.php?page=$1
RewriteRule ^profile/([0-9]+)/([A-Za-z0-9-]+)/?$ index.php?page=profile&id=$1
RewriteRule ^ref/([A-Za-z0-9-]+)/?$ index.php?page=ref&id=$1
RewriteRule ^@([A-Za-z0-9_.]+)/?$ index.php?page=profile&id=$1
RewriteRule ^@([A-Za-z0-9-]+)/([A-Za-z0-9-]+)?$ index.php?page=profile&id=$1&s=$2
RewriteRule ^administrator/editor/theme/([A-Za-z0-9-]+)/([A-Za-z0-9-]+)/?$ administrator/editor/index.php?theme=$1&preset=$2
RewriteRule ^administrator/([A-Za-z0-9-]+)/?$ index.php?page=admin&p=$1
RewriteRule ^m_profile/([0-9]+)/([A-Za-z0-9-]+)/?$ mobile.php?page=profile&id=$1
RewriteRule ^chat/([0-9]+)/([A-Za-z0-9-]+)/?$ index.php?page=chat&id=$1
RewriteRule ^search/([A-Za-z0-9-]+)/?$ index.php?page=logout
RewriteRule ^search/([A-Za-z0-9-]+)/([A-Za-z0-9-]+)/?$ index.php?page=logout

Thanks in advance

All assets inside /hub are throwing 404

here's my vhost

server {
  listen 80;
  listen [::]:80;
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  {{ssl_certificate_key}}
  {{ssl_certificate}}
  {{server_name}}
  {{root}}

  {{nginx_access_log}}
  {{nginx_error_log}}

  if ($scheme != "https") {
    rewrite ^ https://$host$uri permanent;
  }

  location ~ /.well-known {
    auth_basic off;
    allow all;
  }

  {{settings}}

  try_files $uri $uri/ /index.php?$args;
  index index.php index.html;
  
  location /hub {
   index index.php;
  try_files $uri $uri/ /hub/index.php?$args;
  }

  location ~ \.php$ {
    include fastcgi_params;
    fastcgi_intercept_errors on;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    try_files $uri =404;
    fastcgi_read_timeout 3600;
    fastcgi_send_timeout 3600;
    fastcgi_param HTTPS $fastcgi_https;
    fastcgi_pass 127.0.0.1:{{php_fpm_port}};
    fastcgi_param PHP_VALUE "{{php_settings}}";
  }

  location ~* ^.+\.(css|js|jpg|jpeg|gif|png|ico|gz|svg|svgz|ttf|otf|woff|woff2|eot|mp4|ogg|ogv|webm|webp|zip|swf)$ {
    # WordPress Multisite Subdirectory
    rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 break;
    rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$ $1 break;
    add_header Access-Control-Allow-Origin "*";
    expires max;
    access_log off;
  }

  # WordPress Multisite Subdirectory
  if (!-e $request_filename) {
    rewrite /wp-admin$ https://$host$uri permanent;
    rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 last;
    rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$ $1 last;
  }

  if (-f $request_filename) {
    break;
  }
}

#4
location ~ /(login|password|account|store|download|knowledgebase|announcements|clientarea/ssl-certificates|user/(profile|password|security)|cart/(domain/renew)|images/kb)/?(.*)$ { rewrite ^/(.*)$ /index.php?rp=/$1/$2; }

This is causing 404 issues for few CSS and JS files in Admin Login page. I had to remove login from the location.

maybe use if ($scheme != https) { return 301 https://$server_name$uri; }?

Hi please add vhost PrestaShop 8.0.x

Hi please add vhost Mautic 5.x

At the moment, the Moodle 4 vhost template redirects all traffic to HTTPS, which interferes with the Let's encrypt certificate issue.

Since you can set HTTPS redirection inside Moodle or while installing it, I don't think it is needed in vhost template. This would also allow the installation Let's encrypt without any changes on vhost.

I would suggest commenting out:

if ($scheme != "https") {
rewrite ^ https://$host$uri permanent;
}

Just as it is done in PrestShop vhost: https://github.com/cloudpanel-io/vhost-templates/blob/master/v2/PrestaShop/PrestaShop%201.7#L16

Also, this kind of redirect would also work:

set $redirect_to_https 0;

if ($scheme != "https") {
set $redirect_to_https 1;
}

if ($request_uri ~ ^/.well-known) {
set $redirect_to_https 0;
}

if ($redirect_to_https = 1) {
return 301 https://$host$request_uri;
}

When enabling friendly links, photos are not displayed.
Please add

Images.

rewrite ^/(\d)(-[\w-]+)?/.+\.jpg$ /img/p/$1/$1$2.jpg last;
rewrite ^/(\d)(\d)(-[\w-]+)?/.+\.jpg$ /img/p/$1/$2/$1$2$3.jpg last;
rewrite ^/(\d)(\d)(\d)(-[\w-]+)?/.+\.jpg$ /img/p/$1/$2/$3/$1$2$3$4.jpg last;
rewrite ^/(\d)(\d)(\d)(\d)(-[\w-]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$1$2$3$4$5.jpg last;
rewrite ^/(\d)(\d)(\d)(\d)(\d)(-[\w-]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6.jpg last;
rewrite ^/(\d)(\d)(\d)(\d)(\d)(\d)(-[\w-]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7.jpg last;
rewrite ^/(\d)(\d)(\d)(\d)(\d)(\d)(\d)(-[\w-]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8.jpg last;
rewrite ^/(\d)(\d)(\d)(\d)(\d)(\d)(\d)(\d)(-[\w-]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$7/$8/$1$2$3$4$5$6$7$8$9.jpg last;
rewrite ^/c/([\w.-]+)/.+\.jpg$ /img/c/$1.jpg last;

# AlphaImageLoader for IE and FancyBox.
rewrite ^images_ie/?([^/]+)\.(gif|jpe?g|png)$ js/jquery/plugins/fancybox/images/$1.$2 last;

# Web service API.
rewrite ^/api/?(.*)$ /webservice/dispatcher.php?url=$1 last;

# Installation sandbox.
rewrite ^(/install(?:-dev)?/sandbox)/.* /$1/test.php last;

details here: cloudpanel-io/cloudpanel-ce#215

CloudPanel version(s) affected

• 2.2.0

Description

• Whenever you enable the Marketplace store products, the pages for each theme cannot find or load the store.css file located in the /templates/theme-name/css/ folder although it is there.

This might have something to do with the nginx rules but am unsure how to fix it.

How to reproduce

• Create new site, use WHMCS template
• Install WHMCS
• Activate the marketplace products at /admin/marketconnect.php
• View store product page at /index.php?rp=/store/ssl-certificates
• View source and you can see 404 for store.css
• Go directly to the /templates/theme-name/css/store.css and it will show not found
• Verify via ftp and ssh that it is there.

Possible Solution

• Update nginx.conf to take into consideration store.css
• To fix it, I went ahead and renamed all store.css to theme1.css and replaced all references in the template files from store.css to theme1.css and it loaded just fine.