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.
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.
The page on CSS in the docs http://docs.plone.org/adapt-and-extend/theming/templates_css/css.html#plone-css still suggests using cssregistry.xml, even though the resources are stored in the registry now. Is this the preferred method, as opposed to registry.xml? As far as I can tell it adds them to the plone legacy bundle. Given its name, it sounds like that is something I should be moving away from.
Assuming I don't want to keep using plone legacy bundle, is it bad to add my css/js to the plone bundle or should I create a new bundle for my namespaces?
When using ghost depending on the theme it will be grabbing the assets from the folder
ghost/content/themes/<ThemeName>/assets
Is there a general place to put assets ambiguous of the theme that you're using? The idea being to have a CSS file for a post referenced no matter which theme is currently being used.
My current work around is to have a file like so
ghost/content/general/css/file.css
And then linking it via
ln -s ghost/content/general/css/file.css ghost/content/<ThemeName>/assets/css/file.css
This is of course not optimal and I'm sure there's a better way.
Unfortunately not; Ghost is built similarly to WordPress, in that a theme is meant to be entirely self-contained. Of course there is nothing stopping you from directly referencing a hard-coded address in your themes (that may look outside the scope of its own folder), but this is not advised.
Also worth mentioning that you won't be able to use the {{asset}} helper for anything that isn't in your /assets folder.
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 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