Our Prevent Direct Access Gold should be now working on your website. Go back to our PDA Gold settings page.Sudo /opt/bitnami/ctlscript.sh restart nginx Include "/opt/bitnami/nginx/conf/bitnami/nf" #include "/opt/bitnami/nginx/conf/bitnami/nf" Rewrite private/(+)$ "/index.php?pda_v3_pf=$1&pdav3_rexypo=ymerexy" last Find and open your Bitnami Nginx config file normally located at.Copy the rewrite rules shown on Prevent Direct Access Gold Settings page.This video takes you through the process of configuring. Here you go! Our Prevent Direct Access Gold plugin should be working well on your website now. Step 4: Restart Apache to make the new rules implemented sudo /opt/bitnami/ctlscript.sh restart apache In the above code, you may need to change your WordPress directory accordingly, such as Step 3: Paste those codes on step 1 on top of the file as below: # Put your rules here If your WordPress application doesn’t have a nf file yet, you should create it manually. opt/bitnami/apache2/conf/vhosts/htaccess/nf htaccess file can be found at: # the main application configuration file htaccess config file normally located at /opt/bitnami/apps/wordpress/conf/nf RewriteRule ^private/(+)$ index.php?pda_v3_pf=$1&pdav3_rexypo=ymerexy For version 3.0 and above # Prevent Direct Access Rewrite Rules for version 3.x.x Simply copy all codes between the sections. htaccess file containing our custom rewrite rules as image below. Step 1: Under your WordPress admin, navigate to Prevent Direct Access Gold > Status and switch to Tool tab. So here are 3 simple steps that you can do to make our Prevent Direct Access Gold work on Bitnami Apache server: In the case of WordPress, it’s the nf file under /opt/bitnami/apps/wordpress/conf folder.įor compatibility purposes, you should put our custom rewrite rules under nf file instead.
htaccess files to the main application configuration file instead. htaccess files for security and performance reasons.
Nevertheless, thanks for your responses and the cool image.By default, Bitnami disables. Also, for use case such this, it's important to have ability to use Xdebug.Īs for me, I found another repo that covers my problem (with tiny changes). If this use case looks interesting for you, I hope to see this ability in the image from Bitnami because I really like your way to do the things. But it's not cool to have a copy of a Dockerfile from third-party repo in the plugin repo or to have own fork just to have some base Wordpress installed. I don't think that in's necessary to activate them, this part could be explained in the plugin-related Readme. It might be great if for testing goals would be enough to have a docker-compose configuration where one can set a directory which will be automatically copied to the plugins directory in the container. I looked for a repo which could help me to do this without the need to fork and commit anything to Dockerfile. I tried to use this image as a base to test and develop the plugin. I have a plugin that I want to maintain together with a team in the company I'm working for. Maybe anybody else will find it useful too.