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
It's been a while since I've sat down and tried to write a module from scratch in Drupal 8. I've dabbled here and there in the various already existing modules but there's always something interesting about just trying to write that simple
iPhone và iPad của Apple kết thúc năm 2011 với vị trí 1 và 2 trên thị trường trình duyệt web di động.
As someone working on some drupal site you often want to understand what happens on a specific site. This blog post will describe a tool which helps to understand the site faster and easier.
