I have a website that I need to deploy to about 30 customers. They are all the same apart from the branding. Using SVN, I would like to have one base version of the product, and then just the different branded content (images, CSS) for each customer. That way, when I maintain the base product, I don’t have to replicate that change for each customer. Deployment would just be a case of updating and releasing.
Sounds simple, but I am having problems achieving this in SVN. I have been looking into SVN externals using a structure as follows:
Main
Base
.
.
Images
Customer 1
Base
Custom
Images
Customer 2
Base
Custom
Images
and then using externals pointing the Customer Base folders to the main base folder. That works, but I then need to overwrite (for example) the images in the Customer 1\Base\Images folder with the customer specific ones, and when I set up the externals for that it complains “Customer 1\Base\Images is not a working copy root”. It does appear to have overwritten the image with the customer one though.
Maybe externals are not the answer.
In your case, the interface is clearly separeted from the functionality. A possibility is the following (if I well understood your problem) :
Manage your application in a dedicated SVN repository (as usual, with your trunk, branches and tags). And manage your design versions in another repository, with for example the following structure :
./Customer_1
./Customer_1/trunk
./Customer_1/tags
./Customer_1/branches
./Customer_2
./Customer_2/trunk
./Customer_2/tags
./Customer_2/branches
...
With this separation, it's easy to you to manage the version number of your main application. And you have a "small" repository for each customer with possibility to easily copy a design version to start another one by svn copy.
Related
On a website with software documentation, I need to create a new version for a node always that the information changes for a new software release.
Here is an example:
For the product x version 1.0, I have a node (ID: 1000) that explains how to install the product.
When this product has a new release, the instructions need to change. Currently, what I do is to create a different node (ID: 1001) for product x version 2.0, also called how to install. The issue is that, since these two nodes are totally disconnected, as my database grows, managing these versions is getting too painful.
Ideally, I wouldn't have totally disconnected nodes for the same kind of information, but version that node as the product version changes. Is there any module that allows me to do it? If not, any idea on how to solve the issue?
Thank you
It sounds like you want to use node revisioning
https://www.drupal.org/node/320614
My approach would be to use a makeshift solution via entity reference and/or Rules. On a similar project, we used the Rules Link module to remove the author/ownership of the post but keep a reference for later processing by cloning the user entity in said rule to another field.
You could do the same: Automatically generate a new node with a reference to the old one and maybe copies of certain fields.
Depending on how much content you want to reuse, there's the Node Clone module and the Node clone on Save project seems like a fitting case, too (didn't test it).
Before the entity reference module got to be so mighty in Drupal 7 I often heard that sharing a common taxonomy term between 2 nodes would be another easy way to keep nodes „bundled“ – I'm not sure about the UX implications though.
Sorry, seeing that you're talking about documentation, another solution would be to simply activate the Books module and define a book for each product with the different versions as pages (see Drupal documentation as reference – you can easily style the structure, e.g. as tabs).
The module uses the menu system (up to Drupal 7) to keep a simple structure on top of the existing nodes. This approach has its UX limits on very large node counts.
Using the Book Made Simple module you can automatically generate a book on node creation.
This question already has an answer here:
Can buildout create content as part of a Plone install?
(1 answer)
Closed 9 years ago.
I'm loosely following Martin Aspeli's book Professional Plone 4 Development and have a repeatable deployment using buildout. In order to make everything completely automated, I'd like to be able to run bin/buildout and find the site working with all the right add-ons activated. For example, I'm using collective.blog.star, and at present, I have to log into the site and activate it to be able to add blog views, etc..
How can I make buildout also activate the add-ons it downloads in a particular Plone site object?
As Martijn also writes, the quickinstaller takes care of this and it's merely a simple declaration of a dependency you can do in your package, to have the product installed on site-creation automagically, which takes two simple steps:
In the your.package/setup.py add:
setup( ...
install_requires=[ ...
'collective.blog.star'
To let buildout know, this egg shall be pulled and be provided to the ZOPE-instance, too.
And in your.package/your/package/profiles/default/metadata.xml add:
<object ... >
<dependencies>
<dependency>profile:collective.blog.star:default<dependency>
<dependencies>
To actually activate the dependency-product, when you install your product, via profiles.
Check if the profile's name is really 'default' as this is just a convention, defined in the configure.zcml of the product.
It might be, that the order of install can be crucial, as you also want to create content in the same process, I don't know by heart which step would be executed first, the c.b.star-install or the content-creation, you have to test this. In case, the order isn't right, you'd probably have to write another package for splitting the two tasks, controlling the order of install according to the position in the eggs-definitions-list (first comes first, IIRC).
In the past I've heard that it can be dangerous to rename the Plone site object(change it's id).
Is renaming dangerous? What are the potential issues when renaming?
The problem seems to be in the references (from http://plone.293351.n2.nabble.com/Renaming-the-Plone-object-via-ZMI-td4428462.html):
I am trying to rename the Plone object via the Zope Management Interface, however as a side effect, all references I have on "reference_catalog" are lost, including LinguaPlone translations, related content and the path criteria from collections.
I am using Plone 3.1.7, and you can reproduce the problem by creating a vanilla Plone object, add some Documents with related content pointing to each other, add a Folder and Collection, and add a path criterion to the collection, pointing to that folder. Check "reference_catalog". After that, rename the portal object and "reference_catalog" will be empty.
Is there any sollution for this problem?"
Which was answered with:
You need to update your catalog, since the plone object's id is the
first element of the path of all your content.
http://plone.org/documentation/error/portal-content-has-gone-missing/
In the thread there are some links to scripts to avoid losing references.
Any reference to an object that is stored as a path will be a problem. As Yuri's answer points out, that includes the paths in catalogs. That's a relatively easy one to deal with, by doing a full rebuild of the catalog. There are other issues that may be harder to find, such as paths within collection criteria and portlet data.
How do you like to organize your Drupal code? One giant module? Separate modules per feature? Separate modules per code type (theme functions, menu hooks, etc...)?
I've started by trying to organize by feature, treating modules like they were libraries. Ultimately though things are never perfectly contained... modules want to use each other's theme functions, and modules are all contributing various tabs to a common page -- two examples of it not always being so clear where to find code. This tempts me to keep all theme functions together, and all hook_menus together, but this would be awkward for other reasons...
Assume that all code is too specific to eventually share, so there's no attempt here to make self contained contributed modules. I'm mostly concerned about maintaining sanity and cleanliness in a large scale Drupal site.
I tend to have a folder with one main module with all the shared functions, and a variety of sub-modules that are broken up by logical functional divisions. I've found the single huge module approach makes finding stuff in it rather unfun.
It really doesn't make much of a difference if you're not distributing it on Drupal.org, though, so whatever makes sense to you is fine.
I load all customizations into a single module per project (menu/form/link alters, etc.). If enough customization is done, I will fork the original module or create a new module with the original module as a dependency. It's at this point that it pretty subjective: I have no hard and fast rule saying 'fork a module when I reach this many function points or lines of code'.
Anything that adds functionality (meaning that it doesn't override something else) goes into it's own module.
If any newly created or forked modules can be used in other projects or contexts, I will publish them to my personal repository.
I most often use a single module and a set of include files where I store my classes. Although views uses more than one module, it is a great example of the this strategy. Take a look at the views module includes folder to see what I mean.
At the company I work for, we have an intranet that provides employees with access to a wide variety of documents. These documents fall into several categories and subcategories, and each of these categories have their own web page. Below is one such page (each of the links shown will link to a similar view for that category):
http://img16.imageshack.us/img16/9800/dmss.jpg
We currently store each document as a file on the web server and hand-code links to these documents whenever we need to add a new document. This is tedious and error-prone, and it also means we lack any sort of security for accessing these documents. I began looking into document management systems (like KnowledgeTree and OpenKM), however, none of these systems seem to provide a categorized view like in the preview above.
My question is ... does anyone know of any Document Management System that allow for the type of flexibility we currently have with hand-coding links to our documents into various webpages (major and minor , while also providing security, ease of use, and (less important) version control? Or do you think I'd be better off developing such a system from scratch?
If you are trying to categorize the files or folders in the document management system, That's not a difficult task. You only need to access to admin panel to maintain the folders or categorize the folders
In Laserfiche, You can easily categorize your folders regarding the departments and can also be subcategorized them
You should look into Alfresco. It's extremely extensible and provides a lot of ways of accessing the repository.
Note: click the "Developers" tab for the community edition.
My question is ... does anyone know of
any Document Management System that
allow for the type of flexibility we
currently have with hand-coding links
to our documents into various webpages
(major and minor , while also
providing security, ease of use, and
(less important) version control?
Or do you think I'd be better off developing such a system from scratch?
Well there are companies that make a living selling doc management software. Anything you can get off the shelf is going to be a huge time saver, and its going to be better than anything you could reasonably develop by hand.
I've used a few systems:
Sharepoint: although I hear some people don't like it, I didn't either ;)
HyperOffice worked really well for my company of around 150 employees and has all the features you describe.
Current company uses Confluence, I like it :) But its probably one of those tools whose pricetag isn't worth it, especially if you're only using a subset of its features like doc management.
I haven't used it, but one guy I know raves about Alfresco, a free and open source doc management system. I looked at its website, seems simple enough to use.
We also faced a similar problem. However version control was more on our priority and we did look into many solutions in and around. We found Globodox extremely easy to install and use and more important the support team was absolutely fantastic
Try Mayan EDMS, it's Django based, and open source, used it as a base and build the custom features you wish on top of it.
Code location: https://gitlab.com/mayan-edms/mayan-edms
Homepage at: http://www.mayan-edms.com
The project is also available via PyPI at: https://pypi.python.org/pypi/mayan-edms/