How to change path to public files on Drupal 8? - docker

By default the path to public filesystem is sites/<site-name>/files in a multi-site environment or just sites/default/files for a single site. How can I change it? I need to keep files on a separate docker volume(s).

You can keep the standard folder structure as it is, and use symlinks to actually use a different path (folder, volume, etc) as the real storage.
Here's the folder structure for a Drupal 8 site I have on my local Homestead. Update the paths according to your own structure.
/home/vagrant/Projects/D/Drupal8/
├── ..
├── private_files
├── public_files
│   ├── ctools
│   ├── field
│   │   └── image
│   └── styles
│   ├── large
│   │   └── public
│   │   └── field
│   │   └── image
│   ├── medium
│   │   └── public
│   │   └── field
│   │   └── image
│   └── thumbnail
│   └── public
│   └── field
│   └── image
├── vendor
└── web
├── includes
├── misc
├── modules
├── profiles
├── scripts
├── sites
│   ├── all
│   └── default
│   └── files -> (symlink) /home/vagrant/Projects/D/Drupal8/public_files/
└── themes
First move current public files directory to outside of Drupal root, or anywhere on your file-system:
$ mv web/sites/default/files public_files
Create a new files directory in its place (Do this only if the next step doesn't work for you):
$ mkdir web/sites/default/files
Create the symlink:
$ ln -s /home/vagrant/Projects/D/Drupal8/public_files/ /home/vagrant/Projects/D/Drupal8/web/sites/default/files
Two important points to pay attention to:
Always use full paths instead of relative paths when creating symbolic links.
Notice the trailing forward-slash usage in source and destination.

Related

Remove some class file from all jars packaged in tar(each tar is a layer of a docker image)

OK so I know how to remove class files from all the jars under a dir. But, now I have different layer from a docker image, each layer is a tar file, and in the tar file there are the jar files.
Can I remove the class files from the jar files, packaged in tar files?
$ tree -L 3
.
├── 29e0fb8afe376cb02219c977cba1c9a80cca895f7f17b72c356f3e25a63337b9
│   ├── json
│   ├── layer.tar
│   └── VERSION
├── 3b75d6634da4d4f4932d2affeabb7454dc51ba160c3833b386c34e328da8f0ba
│   ├── amq # <<<<< this layer is extracted already, and you can see all the jars here. Other layers are not
│   │   ├── activemq-all-5.11.0.redhat-630495.jar
│   │   ├── bin
│   │   ├── conf
│   │   ├── data
│   │   ├── docs
│   │   ├── examples
│   │   ├── lib
│   │   ├── LICENSE
│   │   ├── NOTICE
│   │   ├── README.txt
│   │   ├── webapps
│   │   └── webapps-demo
│   ├── json
│   ├── layer.tar
│   ├── temp
│   └── VERSION
├── c1fa0e994b2d29f60fd2a6caecbe1ac3f987d001903523d60e532b6e08b094f0
│   ├── json
│   ├── layer.tar
│   └── VERSION
├── c8c84a6c1be5bdfc8caafd23082fd725e84f1c9cddb98fd56cad3a62544b2a3c.json
├── ef5088f89fbac64d2d5982ba14492227f60db1221f6bfd6290c6364a2a95a7e3
│   ├── json
│   ├── layer.tar
│   └── VERSION
├── manifest.json
├── repositories
└── script.sh # <<<<< the script is here
So you ask me why?
Well, did you hear people talking about log4j recently? :) I am doing this right now: log4j vulnerability check: how to quickly detect if log4j is used, in mavevn/in an image? "mvn dependency:tree" does not give a full picture
If someone can tell me how to remove these classes from jib maven plugin, that's better. They are from a base image and I doubt we could do that, though.

Why docker ADD destroys folder structure?

I have the following folder structure:
> tree -L 3
├── pom.xml
├── src
│   ├── main
│   │   ├── java
│   │   └── resources
│   └── test
│   ├── groovy
│   └── resources
I tried to build docker image containing those folders together with files using the following Dockerfile:
FROM jamesdbloom/docker-java8-maven
USER root
RUN mkdir src
ADD ./src/* ./src/
ADD pom.xm
However, the structure in docker image is different. Particularly, I can no longer find main and test folders.
$ tree -L 3
.
├── pom.xml
├── src
│   ├── groovy
│   │   └── com
│   ├── java
│   │   └── com
│   └── resources
│   ├── ext_sample_input.json
│   ├── hist_sample_input.json
│   └── sample_input.json
Why is it so?
From official documentation:
Note: The directory itself is not copied, just its contents.
Change your ADD statement to:
ADD ./src ./src/

docker-compose up with multiple yml confs does not start off

This is the tree structure of my project:
.
├── backend-codebase
│   ├── app.js
│   ├── bin
│   │   └── www
│   ├── config.js
│   ├── db
│   │   ├── index.js
│   │   ├── repos
│   │   │   └── todos.js
│   │   └── sql
│   │   ├── index.js
│   │   └── todos
│   ├── dev
│   │   └── postgres
│   ├── index.js
│   ├── package.json
│   ├── public
│   │   ├── images
│   │   ├── javascripts
│   │   └── stylesheets
│   │   └── style.css
│   ├── routes
│   │   ├── api.js
│   │   ├── index.js
│   │   └── users.js
│   ├── scripts
│   │   ├── applyFixtures.js
│   │   ├── dev_entrypoint.sh
│   │   ├── fixtures.json
│   │   └── psql_dump.sql
│   ├── views
│   │   ├── api.ejs
│   │   ├── db.ejs
│   └── yarn.lock
├── dev
│   ├── Dockerfile-node
│   ├── Dockerfile-postgres
│   ├── development.sh
│   ├── docker-compose-common.yml
│   ├── docker-compose-dev.yml
│   └── postgres
│   ├── 12-12-2016_16_58_59.dump
...
I use docker-compose in order to create three containers and orcherstrate everything:
- a node server
- a postgres DB
- a data container for the DB
plus, I created two (and a third one is missing) yaml files under /dev/docker-compose-*.yml. docker-compose-dev extends the common one and should build the images as well as run all the images.
In order to start off everything I tried to launch the following:
$ docker-compose up --file dev/docker-compose-common.yml --file dev/docker-compose-dev.yml
But what I get is this output:
Builds, (re)creates, starts, and attaches to containers for a service.
Unless they are already running, this command also starts any linked services.
The `docker-compose up` command aggregates the output of each container. When
the command exits, all cont
I really don't understand what I'm doing wrong
Silly, silly me.
It was simply the order between the arguments and the command upside-down.
Plus, I can remove the first --file argument, since it is referenced by using the extends yaml key.
docker-compose -f dev/docker-compose-dev.yml up

My Firefox add-on won't show when I install it

So, I'm utterly and completely new to making Firefox add-ons. I have been trying to make a really, really simple one which will run some JavaScript on the page when I click it. That's literally all I want it to do -_-
However, it will install when I drag it into FF/Nightly, but then not show up in the customise menu. It will say it's installed, but that's it. (I also can't open its preferences, but, I'm really not complaining - I just want a really basic add-on).
If you need the code/entire XPI itself, I'm happy to supply. Thank you :)
I am using the following directories and files:
.
├── chrome
│   ├── chrome.manifest
│   ├── content
│   │   ├── boustrophedonise.js
│   │   ├── browser.xul
│   │   └── prefrences.xul
│   ├── locale
│   │   └── en-UK
│   │   └── translations.dtd
│   └── skin
│   ├── icon.png
│   └── skin.css
├── defaults
│   └── preferences
│   └── pref.js
└── install.rdf
While there may be other problems, your chrome.manifest file is in the wrong directory. It needs to be in the root directory (the same directory as the install.rdf file). This is covered in both the "Setting Up the Development Environment" and "Create a Chrome Manifest" sections of the Building an extension tutorial on MDN. The first section explains that you should start with a directory structure that looks like:
.
├── chrome
│ └── content
│ └── sample.xul (Much of your content in this directory)
├── chrome.manifest
└── install.rdf
The chrome.manifest file is one of the required files for a Firefox add-on. It defines what URLs like chome://myExtension/content/* point to. In your case, without the chrome.manifest file being in the root directory, the URL in your install.rdf of chrome://boustrophedonise/content/options.xul is invalid and is probably complained about in the Firefox Browser Console when the extension is installed (or perhaps when the add-on manager is displayed, or the link for your add-on options is clicked). Firefox probably also complains about the lack of a chrome.manifest file. Obviously, since Firefox is unable to find the chrome.manifest file it does not apply the overlay onto chrome://browser/content/browser.xul, nor the skin, both of which are defined in that file, which are the things that hook your add-on into Firefox.
So in your case, you need to move the chrome.manifest file such that it is located as:
.
├── chrome
│   ├── content
│   │   ├── boustrophedonise.js
│   │   ├── browser.xul
│   │   └── prefrences.xul
│   ├── locale
│   │   └── en-UK
│   │   └── translations.dtd
│   └── skin
│   ├── icon.png
│   └── skin.css
├── chrome.manifest
├── defaults
│   └── preferences
│   └── pref.js
└── install.rdf

Mustache conflict at release build

I use wooga's fork of mustache.erl (https://github.com/wooga/mustache.erl) in my project. And when I try to create release I get an error because rebar uses this mustache.beam file instead of a file included in its source.
What should I do to resolve this conflict?
The reason is not in rebar but is that some app in release tool search path contains the mustache.erl file as you release does.
Usually rel.config file contains {lib_dirs, ["../.."]} that force release tool search libs (apps) up your release directory. See example below. To fix it, move your release directory dipper (for example -> you_release/you_release) or move app that contains the same file (mustache.erl) to other place.
├── your_release_directory
│   ├── deps
│   │   └── mustache
│   │   ├── ebin
│   │   │   ├── mustache.app
│   │   │   └── mustache.beam
│   │   └── src
│   │   ├── mustache.app.src
│   │   └── mustache.erl
│   ├── ebin
│   │   └── mustache.beam
├── rebar (or any other app contains mustache.erl)
│   ├── ebin
│   │   └── mustache.beam
│   ├── src
│   │   └── mustache.erl

Resources