While building Drupal websites, we end up building modules for all sorts of random tasks – anything from simply reorganizing the contents of a node object or adding fields to the Site Information page to views plugins or huge integrations. It’s not unusual to have both in-house and contributed modules for which you or your company are the maintainer, that you use across many project. The problem is this: if you have twenty projects running your in house module and it requires a security update, you’re stuck manually updating each project by patching the files and then following your normal workflow. Your contrib modules can take advantage of Drush for updates, but Drush won’t solve the problem of ongoing project based module maintenance.
First thing’s first – need to be using Git. It’s nearly universally supported on *nix hosts, supported by Drush, and it’s what’s in use at Drupal.org, so it’s a solid choice for a Drupal shop on those grounds alone. At Envision we use the git-flow model (though we do not use the actual git-flow script), which I’ll discuss in detail in a future blog.
Git provides a feature called submodules. Simply put, it is a nested repository. In practice, this allows you to not only easily and reliably manage individual project instances of a custom module, it lets you engage in ongoing development on the module as a part of normal project development. Better still, it provides the ability to switch branches, check out tags, and so forth – all on a project’s module instance. Best of all, it’s extremely simple to set up.
Let’s look at an example. I recently released my first module to the community, Node Auto Queue (link to http://drupal.org/project/auto_nodequeue). It’s a pretty simple module. It allows you to configure a node queue to automatically have new nodes of it’s allowed content types added to the queue on creation. It exposes a new fieldset on node creation forms with a list of checkboxes, one per available queue for that content type, checked or not by default based on the queue’s setting.
A screenshot of the auto_nodequeue Drupal module as a Git submodule in SmartGit
That’s it! Now I have a fully functional copy of the auto_nodequeue repository inside the myproject Drupal site. As I make updates to auto_nodequeue, I will commit them back to the actual module repository. This allows me to update it with git pull on each project that needs the new code. You might be wondering – what if I’m using an in-house module and I want to customize it for this site only? The answer is to make a new module just for this site. Using a submodule will force you to separate site specific custom code from generally useful custom code relied on by multiple project, a good practice in general but one we’re often not forced to use because we’re copy and pasting common custom in-house module files into our projects and creating a whole new branch with each go-round.
via Envision
Drupal Developer having 9+ year experience, implementation and having strong knowledge of technical specifications, workflow development. Ability to perform effectively and efficiently in team and individually. Always enthusiastic and interseted to study new technologies
In our last blog post, we saw how to set up a simple website in a foreign language. Like our last recipe, this one is very easy too. The main difference lies in the fact that we need to give users the possibility to choose their preferred language.
Khi bắt đầu đi học hoặc đi làm, nhiều bạn sẽ ra ngân hàng làm một cái thẻ ATM để nhận và rút tiền. Tuy nhiên khi nhận thẻ về, nhiều bạn có thể bỏ qua
At that time, it was estimated that a new version with new features could be released every 6 months
