I'm helping a colleague configure a new box for an existing Drupal install with multiple sites. It's functioning, but I've noticed that all assets are being referenced as /sites/<site-name>/files/image.png. I don't know from Drupal, but it strikes me that Drupal should be abstracting the logical site from the code so that site-specific assets could be referenced as /files/image.png and Drupal would figure out -- perhaps based on HTTP_HOST -- which site is meant.
In this case, we need separate snapshots of the same site (dev and staging) so we'd like to be able to store the paths without specifically referencing one site or the other. We can do some rewriting to manage this, but I'm wondering whether there's something that we simply don't know.
Does Drupal do this natively in some way? If not, what are others doing to manage this kind of abstraction? Surely we're not the first to encounter this and think there must be a better way.
Thanks.
That would be an interesting module. The Files directory can be in the following locations:
sites/<site name>/files (standard for multi sites, public)
or
sites/default/files (standard installation for single sites, public)
That is, if you want to use the public files method.
Read here if you want to learn about the private files method (very similar to your thought): http://drupal.org/documentation/modules/file
Related
Let's say I have created a news portal bundle "NewsBundle" with articles, tags, events, lots of relations, quite huge and complex.
Now I want to copy this numerous times and create a Fashion News Portal, Car News Portal, Dog News portal and so on each available though an own domain. The portals differ only in templates, translations and assets. As I want to implement complex reporting, I want all the stuff in a single database and would flag all entities with the respective portal.
My question: How so I organize the code?
First I figured out, I could use routing to have the same application but different bundles for each domain.
Then I found out, that I could extend my master bundle. But it seems as this works only once.
As I did all the routing with annotations, it look like it does not work to inherit the routes from the master?
One of the hardest questions is where to put the portal switch. Somewhere I need to set a variable that tells whether its the fashion or dogs portal, so I can filter the content in all repositories accordingly.
I did that in the app.php which is for sure worst practise.
In the end I want to be able to roll out new portals easily without duplicate code.
Any ideas are much appreciated.
Greetings from Hamburg,
Boris
You need to keep your NewsBundle in your application, and to have a number of bundles revolving around it, one for each portal you intend to create.
There is no real need for bundle inheritance here. Your portal bundles depends on the NewsBundle but don't inherit from it.
Routing configuration, templating, and other behaviours related to a specific portal should go in the related bundle. There is a Resources folder in each bundle ; this is where you will need to put specific routing, translation, configuration and templates.
app/config/routing.yml is the central routing conf file where you will need to reference all other routing.yml file.
As for the switch, well, I can't answer that in detail but I think it should be set up in your server application apache or nginx (or other...).
Your problem can be solved via different environments. Each of your portal is a different environment. You can set up your web server to point different front-controllers depending on the domain requested.
Example:
For domain news.domain.com your front-controller would be web/app_news.php. And it will contain line:
$kernel = new AppKernel('news', false);
It will automatically load config from app/config/config_news.yml. In that config you can specify all specific parameters for your portal. You need then just implement your special loader for resources like translations that will load resources from the path specified in config_news.yml.
Our institute has Plone 5.0 and 4.3 running and are migrating dozens of older plone sites into them.
We have created a Diazo theme and it is hosted to provide our theme out to all plone sites. There are specific plone pages like the Login that must be changed. There are two ways we see to do this:
Portal View Customizations. Problem is we can't host this template centrally and can't change it one place to change it everywhere. This will bring maintenance issues.
Diazo. We could put all the html in the index.html and then drop code we do not need through the rules.xml. However this feels super hacky and inelegant. The index file will grow and grow in size.
What is the best approach to something like this?
My idea: (Please tell me if this good or bad)
In Diazo, the rules.xml would load a subset rules file called login-rules.xml. In the login-rules.xml, I'd put a replace rule. The replace rule would have within it all the login HTML.
You've really got two kinds of problems here.
One is deciding where to intervene for your login pages. The other is how to manage deployment of custom code.
If the changes you need are strictly ones of presentation, Diazo is a reasonable place to handle it. Remember that you may use different theme documents, with your rule set making an early decision of which theme (html) file it uses under what circumstances.
If the changes you need are beyond simple presentation and require custom logic, or if the presentation changes start to require complex custom XSLT, make the changes via view customization. But do not do that with the Portal View Customization tool. Customizations that are needed on multiple sites should go into Python packages maintained in a source-control repository like git. That goes for Diazo rules and theme files as well as templates.
You may create the skeletons for these packages with ZopeSkel or mr.bob. Use the JBOT method within these packages to customize individual template files.
Managing deployment is much easier when you're using file-system packages from a repository. You may use mr.developer within your buildout to automatically check out the current version (or a particular tag or branch) of a package when you run buildout. Then, when you need to push changes to multiple servers, you run buildout on each one and restart the ZEO clients. That may be automated with tools like Ansible. See Plone's Ansible Playbook for examples.
I've used several bits of Plone-specific jargon in the above. All of these are well-documented at http://docs.plone.org.
I have regrouped the following information from a few examples in the SonataAdminBundle documentation. Please correct me if there are some errors, but here is what I get in the case of a BlogBundle:
As you can see, in general, each bundle contains both frontend and backend classes.
It seems very messy to mix both frontend and backend in the same folders somtetimes (see Controllers), but to be honest I can't think of an other way...
I actually started handling backend in a separate bundle but then realised that it was also too messy.
So in practice, do people really follow this architecture? Is this the only/best way to handle backend when using SonataAdminBundle?
This beautiful post here is using a different approach...any ideas what I should do to make sure the code doesn't get too messy.
Simple: use folders within locations of mixed content. I put frontend components directly in their respective folders, and add Admin folders for backend files.
You can refer to e.g. a controller in the Admin subfolder like this BlogBundle:Admin\Concert:index, essentially the same works for templates.
On configuration, you could create a config-frontend.yml and a config-backend.yml file, then include it in the original config.yml file. I don't do that though.
I'm trying to help a co-worker configure a Drupal site so that we can deploy the same site upstream without making database changes. We're having trouble with file paths. Here's what I have:
A Nginx webroot pointing to the root of my Drupal 6 (in this case) install (/opt/frameworks/drupal-6).
The content for this site is in /opt/www/my-site.
A symlink exists in /opt/frameworks/drupal-6/sites: dev-my-site -> /opt/www/dev-my-site
Because of some sharing that's going on, there are multiple versions of my-site on the box, so they have to have different symlink names. Right now, the "file system path" is set to sites/dev-my-site/files which breaks when moved upstream.
Is there a way that I can set a configuration variable to override the database setting? Or is there a better way to configure my webroot and sites? I don't know much about Drupal, but I'd like to build this out so that deployments are as simple as possible.
A bunch of trial and error by 2 inexperienced Drupal folks has led to a possible solution. It looks like setting the $conf['file_system_directory'] in settings.php does exactly what we need. Each site on each box will have it's own settings file that isn't touched by deployments, so we might be all good.
If there's a better way or if there are unintended side effects to this particular way, I'd love to hear answers from more experienced Drupal admins.
I have set up 2 drupal instances pointing 2 codebase with a common database
www.abc.com points to folder /var/www/abcfolder
mywww.abc.com points to folder /var/www/mywwwabcfolder
The content is uploaded via mywww.abc.com and www.abc.com is used for general viewing. I have used domain access module where mywww.abc.com is an alais to mywww.abc.com
I want that all the files that are uploaded should be maintained in a common folder i.e. in /var/abcfolder/public/sites/all/files for both urls
I tried changing the file system path via admin/file-system to ../../abcfolder/public/sites/default/files since the path should be relative to the drupal installation folder. However on uploading a file, I get a file not found error.
Any help to resolve this issue would be appreciated?
Should I change the htaccess file in any one of the codebase? If yes, what should the change be?
Regards,
Loveleen
How about trying this:
Store the files in /var/www/abcfolder/sites/default/files. Create a symbolic link from /var/www/mywwwabcfolder/sites/default/files to /var/www/abcfolder/sites/default/files
Look up symbolic links in linux if you don't know what they are. If you're using windows you can still do symbolic links but they are more complicated.
[BTW I am not sure why you are doing this complicated setup. Reconsider using domain access unless you really need to. Is it necessary to have two sites like this? ]