Attending a large conference for the first time can be both exciting and uncertain — and DrupalCon is no exception. What should first-time attendees to DrupalCon expect?
After spending the weekend going through a rather excellent (I thought) video overview course on AngularJS, my head was spinning with the possibilities when it came to building Drupal sites that were much more responsive in terms of loading and displaying content. So, I decided to start working on some proof of concept modules that would help me better understand how to effectively meld these two tools together.
One of the major topics of discussion in the Drupal community has been decoupled (or headless) Drupal. Depending on who you ask, it’s either the best way to build break-through user experiences, or nothing short of a pandemic. But what exactly is a decoupled architecture?
I go to Seattle for two weeks, and Microsoft goes bonkers. First the Debian release party, and now Visual Studio for Linux?
(Source: BUILD conference keynote)
Many blog posts have outlined the benefits of using VMs (Virtual Machines) for local Drupal development instead of either using native PHP and Apache, or a bundled environment like MAMP, XAMPP, or Acquia Dev Desktop. The advantages of using virtualization (usually managed by Vagrant) are numerous, but in certain cases, you can make a good argument for sticking with the traditional solutions.
If you'd like to take the dive and start using virtualized development environments, or if you're already using Vagrant and VirtualBox or some other VM environment (e.g. VMWare Fusion or Parallels Desktop), how do you optimize local development, and which pre-bundled Drupal development VM will be best for you and your team?Criteria for the Perfect Local Development Environment
These are the criteria I use when judging solutions for local Drupal development (whether virtualized or traditional):
- Should be simple and easy to set up
- Should be fast by default
- Should be flexible:
- Should work with multiple providers; VirtualBox is free, but VMWare can be much faster!
- Should allow configuration of the PHP version.
- Should work with your preferred development workflow (e.g. drush, makefiles, manual database sync, etc.)
- Should prevent filesystem friction (e.g. permissions issues, slow file access speeds, etc.)
- Shouldn't have hardcoded defaults
- Should be complete:
- Should work without requiring a bunch of extra plugins or 3rd party tools
- No extra languages or libraries should be required (why install Ruby gems, npm modules, etc. unless you need them for your particular project?)
- Should be Free and Open Source
- Should include all the tools you need, but allow you to disable whatever you don't need (e.g. XHProf, Apache Solr, etc.)
- Should work on Windows, Mac, and Linux with minimal or no adjustment
- Should be deployable to production (so your local dev environment matches prod exactly)
A lot of these points may have more or less importance to a particular team or individual developer. If you're a die-hard Mac user and don't ever work with any developers on Windows or Linux, you don't need to worry about Windows support. But some of these points apply to everyone, like being fast, simple, and flexible.
A hotfix release for the Finance-YahooQuote Perl module on CPAN is now available. Available Yahoo! Finance decided to change the base URL. My thanks to Nicola Chiapolini who not only noticed but also sent me the one-line patch fixing this:--- YahooQuote.pm~ 2010-03-27 01:44:10.000000000 +0100 +++ YahooQuote.pm 2015-04-29 11:31:20.407926674 +0200 @@ -34,7 +34,7 @@ $VERSION = '0.24'; ## these variables govern what type of quote the modules is retrieving -$QURLbase = "http://download.finance.yahoo.com/d/quotes.csvr?e=.csv&f="; +$QURLbase = "http://download.finance.yahoo.com/d/quotes.csv?e=.csv&f="; $QURLformat = "snl1d1t1c1p2va2bapomwerr1dyj1x"; # default up to 0.19 $QURLextended = "s7t8e7e8e9r6r7r5b4p6p5j4m3m4"; # new in 0.20 $QURLrealtime = "b2b3k2k1c6m2j3"; # also new in 0.20
If need be, edit your file YahooQuote.pm by hand.
Having maintained this since 2002 in RCS, I also just created a GitHub repo for it where development/maintenance will now happen.
Modules Unraveled: 134 Deciding when to upgrade to Drupal 8 with Kristof Van Tomme and Peter Kohan - Modules Unraveled Podcast
- What is d8upgrade.org?
- When did you put the site together?
- How were you offering the service before the site was up?
- Talk about MVP
- Why did you guys create this service?
- Build a more direct communication channel for module maintainers - Mailing list (module devs talk to people using module
- Initiative to get out the catch 22 - modules aren’t ready, so you can’t upgrade, you don’t upgrade so the modules don’t get money to be upgraded.
- Does it cost anything?
- Nope - it’s free
- Are you planning to monitize the site in any way?
- We expect a lot of site owners will be looking for a way to upgrade their website, if they don’t yet have an agency, we can help them find a good agency. If this evolves how we imagine, this could fuel the sales pipeline for our consultancy and a few selected partners. We are not going to go hardcore salesy on this, but put in links for module work and 2for1 discounts and hopefully some of those will convert into customers for us or our partners.
- How does it work? What do I have to do to track a site?
- As simple as possible, conscious choice to not make it a module - just copy paste your module page
- How many people have signed up so far?
- We’ve got a total of 73 sites now, some from the same people - after Drupalcon LA we expect that to become a few hundred.
- What do you have planned for the future of the site?
- The community misses a permission marketing channel for module developers. We would like to let site owners sign up for important information about the modules they use through a push communication channel. There is a lot of talk in the community that we are not getting any support from site owners for the development of D8, but we’ve made it almost impossible for them to stay up to date. There is no way they are going to start reading the issue queues of modules on regular basis.
- I took a look at the site and saw something called 2for1 - Give to Get. What’s that?
- This is part of the strategy we want to use to monetise the platform: we offer our customers a 2 dollar discount on their future D8 project for every dollar they invest in helping Drupal 8 get out of the door. This gets us more business and brings outside funding into the community. For too long we’ve been giving money from one developer’s pocket to the next developer’s pocket. We hope we can change that this way. We are inviting other consultancies to join us in this campaign, if you want to join, you can become a partner in the campaign.
The Drupal Field Group module has been on my Essential Drupal list since I first learned about it, and with 200,000 installs, I am certainly not the only one.
Field Group lets you add the common CCK field wrappers on their own so you can organize not only the display of the nodes through the Entity View Modes, or Display Suite on the "Manage Display" tab, but it also lets you organize fields as they are displayed to the administrator on the Add and Edit screens through the "Manage Fields" tab.
Field Groups allows for adding and configuring of the following field types:
- Horizontal tabs
- Vertical tabs
- Multipage steps
- HTML5 elements
- HTML elements
If you are using a default Admin theme like Seven, adding and configuring the default Fieldsets, tabs and accordions make your content configuration screens blend in perfectly since they are already styled. You can also take your node add and edit screens to the next level by theming DIV's, or any HTML/HTML5 elements if you are using your front end theme for administration screens, or a custom admin theme.
My last blog post proved popular, and I've had some requests for a video demonstrating it, so I've put one together:
Maintaining visual regression tests can be hard, but the more tests we write for our projects, the more we see the tremendous power it provides in terms of QA and monitoring our sites.
One daunting task each developer hates (and often avoids) is validating their markup on multiple browsers. All of Gizra's developers use either Mac or Ubuntu on their machines, so the line to the "IE computer" on the far end of the office is getting long. Way too long.
And honestly - after our poor developers validated their work once, if we'd ask them to do it again. And again. And again... we'd probably be left without any.
Developers moral shouldn't be underestimated!
Shoov means "Again" in Hebrew for this very reason.Go ahead and jump to our example repo which now has cross browser tests. Writing your tests once - but testing on multiple platforms and browsers is a big win.DuckDuckGo.com tested by BrowserStack on Windows7, IE11, with 1024x780 resolution
Submitted by: William Estrada - DCon LA Community Summit volunteer
Do you love your local Drupal community? Do you want to grow Drupal adoption in your hometown? Do you take satisfaction is providing mentorship or are you looking to pay it forward after being mentored? Are you the person who always raises their hand to help others and wants to get involved?
It provides R with a reader for TOML files. TOML stands for Tom's Obvious Markup Language. And before you roll your eyes, glance at the TOML site. It really is different, and has a number of rather wonderful features:
- free-format indentation as you please
- comments anywhere, even on the same line
- actual types such as string, integer, float, bool and datetime (!!) which are all native
- vectors, of course, of the above
- arbitrary nesting of tables
See much more at the TOML site. I converted one first project at work to this and it really rocks. Point to a file, get a list back and index all components by their names.
We also added really simple S3 classes to the default print() method uses str() for a more compact presentation of what (in R) is of course nested list types.
Internally, the RcppTOML packages use the splendid cpptoml parser by Chase Geigle. This brings in modern C++11 and makes it that CRAN simply cannot build a binary for R on Windows as the g++ version (still, as of April 2015) in Rtools is too old. There is word of an update to Rtools and that point should we able to support Windows as well. Until then, no mas.
Today I found out (by mail from my German friend) that there is a place called Longo Mai. Still need to explore it but it made my day currently.
For working with Debian packages, one method of maintaining them is to put them in git and use git-buildpackage to build them right out of the git repository. There are a few pitfalls with it, notably around if you forget to import the upstream you get this strange treeish related error which still throws me at first when I see it.
Part of maintaining packages is to be able to fix security bugs in older versions of them that are found in stable and even sometimes old stable (jessie and wheezy respectively at the time of writing). At first I used to do this outside git because to me there wasn’t a clear way of doing it within it. This is not too satisfactory because it means you lose the benefits of using git in the first place, and for distributions you are more likely to need collaboration with, such as working with the security team or help with backporting.
So because I don’t think the details are easily found and also I’ll probably lose them again and need a central spot to find what I did last time.Building the environment
The first step for a new distribution is to create the building environment. You really only need to do this once when there is a new distribution with then possibly some updates from time to time. The command will create the environment in /var/cache/pbuilder/base-DIST.cow/DIST=wheezy git-pbuilder create
You will find all the files in /var/cache/pbuilder/base-wheezy.cow/ which is then ready to do be used.Creating the branch
The master branch is generally where sid will located. For the other distributions, I use branches. For the initial setup you will need to create the branch and start it off from the right point. For example, the last non-security update for wordpress in jessie was version 4.1+dfsg-1. We then want the jessie branch to start from this point.git branch jessie debian/4.1+dfsg-1 git checkout jessie
This will then create and put you on the jessie branch. You only need the first line once. You can switch between sid (master branch) and jessie (jessie branch).
At this point you have a working place to make all the updates you need to do. Nothing is terribly different from the usual workflow.Building the package
Make sure you have checked in all your changes and now it is time to build your package!git-buildpackage --git-pbuilder --git-dist=jessie --git-debian-branch=jessie
You may need two additional flags:
- -sa Use this for the first security update so there is also the source included on the security servers.
- –git-tag Once you are sure this is the latest changes for this version this will tag in git with the debian tag, such as debian/4.1+dfsg-1+deb8u1
As a follow-up on your blog post, where you complain about the state of Hadoop. First, I couldn’t agree more with all you wrote. All of it! But why not trying to get Hadoop in Debian, rather than only complaining about the state of things?
I have recently packaged and uploaded Sahara, which is OpenStack big data as a service (in other words: running Hadoop as a service on an OpenStack cloud). Its working well, though it was a bit frustrating to discover exactly what you complained about: the operating system cloud image needed to run within Sahara can only be downloaded as a pre-built image, which is impossible to check. It would have been so much work to package Hadoop that I just gave up (and frankly, packaging all of OpenStack in Debian is enough work for a single person doing the job… so no, I don’t have time to do it myself).
OpenStack Sahara already provides the reproducible deployment system which you seem to wish. We “only” need Hadoop itself.
Let’s take a brief look at how translation contributions work in Drupal. This written tutorial is based on the free video, Translation in Drupal.
The Global Redirect module ensures that we will have the best possible technical output from Drupal for Search Engine Optimization (SEO). It is available for Drupal 6 and Drupal 7, and it looks like they have been hard at work building it for Drupal 8.
For years, the best practice for any site is to make the URLs keyword rich and friendly so the user knows what to expect when they visit. So we change Drupal's "Clean URL" settings from jimbir.ch?q=node/27 to jimbir.ch/node/27 and then we change Pathauto's settings from jimbir.ch/node/27 to jimbir.ch/blog/essential-drupal-global-redirect-module.
What we are missing is that those original URLs still remain live on the internet, and can be considered duplicate content, a detriment to good SEO. Global Redirect automatically sets up 301 Redirects for both of the old URL schemes, to the new friendly URL.
The same goes for the trailing slash. This module removes (or adds if you so choose) the trailing slash, so there will be only one canonical URL living between jimbir.ch/page and jimbir.ch/page/
The last big option is the home page. In Drupal's Site Information, we set which node we want as the site's homepage. Global Redirect makes sure that we only have one page indexed, rather than jimbir.ch and jimbir.ch/home.
There are quite a few more options that can be configured at:
I wasn’t sure whether I would make it to Linuxdays Graz (GLT15) this year so I didn’t participate in its call for lectures. But when meeting folks on the evening before the main event I came up with the idea of giving a lightning talk as special kind of celebrating the Debian jessie release.
So I gave a lightning talk about "Debian 8 aka jessie, what’s new" on 25th of April (couldn’t have been a better date :)) and the slides of my talk turned up to be more useful than expected (>3000 downloads within the first 48 hours and I received lots of great feedback), so maybe it’s worth mentioning them here as well: "Debian 8 aka jessie, what’s new" (PDF, 450KB)
In our preceding post we focused on the topic of "responsibilities and communication" and the importance of questions that help to clarify duties and responsibilities. Today we’ll deal with unrealistic deadlines and budgets – and how to avoid them.
An 800-hour project is not finished in a day, not even with 100 programmers. The completion time of a project is derived from the sum of the times estimated for the individual requirements. In order to do this reliably, it’s essential to know in detail what has to be done. This is why requirement engineering is vital at the beginning of a project. Even though a deadline (completion date) is determined by the sum of expenses, it’s important to note that not everything in a project can run in parallel, meaning that more is not always faster. A project plan for the overall project and for every single sprint will help you to control the progress, expenses and deadlines.
Not every job requires the same expertise. In addition to technical skills, there are often technical requirements that are necessary to reflect specific customer business processes in the software. These requirements should be stated in the individual tasks. It’s part of the project management to make this categorization a responsibility of the developer. If you optimize your project plan, for example with a Gantt chart, you can plan resources such as time, money and people at the beginning of a project and validate the plan accordingly.2) Which developers can do which tasks?
One developer is not equal to every other developer. Everyone in the team has specific competencies: you get selected for a project because your skills fit well. Even in software development, it’s rarely the case that everyone all has the same expertise. A good Drupal developer is not necessarily a good site builder nor a good themer. You might make this assumption when hiring a person, but you’ll be disappointed if you don’t verify his/her skills. Therefore, you should be able to associate the expertise of your team with the specific tasks on hand. A good way to illustrate the dependencies of tasks is with a Gantt chart: for realistic budgeting you need a detailed plan so that you know, as a provider, what you have to achieve over which period of time. On the customer side, a detailed plan with clear time estimations helps you know what you’re getting for your money so you can rest assured that all the features – such as deadline, budgets, prices and specifications – are realistic. This is necessary because you want to achieve something positive with your project and, thus, have to rely on the data from good and realistic planning. The deadline is determined by adding up the times required by each developer in the team, taking the dependencies of each task into account. Plan in a fixed buffer for project management, quality assurance and communication.
Project management cannot be hurried. It costs time and money, but if done right, it’s worth it. When the project’s time and budget are reaching the end without the certainty that the project itself is facing a successful end, the quality inevitably suffers. So: plan realistically to protect your team from unnecessary stress and to provide your customer with the assurance that he can count on your word. This is an essential foundation for any successful project.3) Done does not equal completed
Even when all the development work is done in your project, it doesn’t mean that the project is really completed. Now, when acceptance is imminent, the integration of all the single tasks needs to be (double-)checked. When deploying the project to acceptance you should definitely first check internally whether all benefits promised in the concept were actually implemented and tested. This usually happens on a staging system to prepare a customer presentation. Optimally, for each task you should also be able to demonstrate that you’ve fulfilled it with the promised performance and validated it by testing for proper execution. Only once this internal process is successfully completed should the project results be presented to the client for approval. Unfortunately, it’s often overlooked that the cooperation of the customer is required: your customer needs to test his specification accordingly and, hence, accept the project if there are no more serious bugs. Working cleanly and in detail is even more important at the beginning of the design phase. This becomes evident not just in the acceptance: if there are only minor bugs that don’t prevent the functioning of the concept, the project must be accepted with a bug report, which will then be attached to the acceptance report.
So, try desperately to stick to the following points:4) Only provide what was actually tested
Although you have the right to repair, it looks unprofessional if you provide your customer with a project result that has obvious errors. This casts the project team in a poor light. So, write down what you’ve tested. Key points about each task and the benefits of the concept are sufficient. Clear acceptance criteria will help prove that all the requirements have been fulfilled5) Involve your clients in the acceptance and prepare it well
Nothing is worse and more unproductive than if you provide your customer with the results of the project after three months of silence. Certainly, you may argue that you’ve just been doing focused work, but communication is simply essential to managing expectations. Your customer will feel lost if you don’t communicate at all. If you don't communicate recent status updates in recurring meetings, your customer will create his own expectations regarding the progress. So, communicate and show individual project results continuously – but only when they’re also really presentable. Engage your clients in the purchase process and show a demo of what the software can do and how that fits into the concept you created earlier, so your customer isn’t left with doubts and ambiguities but can ask you directly. Questions and problems can then be discussed immediately – and resolved.6) Collect all the aspects that your customer wants to be changed
Sure, there will be functions and requirements that must be implemented in the software before it can go into production. Collect all these points in an initial protocol. Then, evaluate the different points, examine the requirement changes (change requests) and determine which of the points are still outstanding to the concept. Those still owing must either be implemented as soon as possible or appear in the internal quality assurance. Actually, they shouldn’t be there at all if you’ve already tested internally against the specifications! Change requests are then processed after acceptance. The same applies to minor bugs that don’t affect the functionality.
Both parties should have the same goal: To achieve (partial) acceptance and thus arrive at a decision that a project milestone is completed, after which work can continue and the software enhanced with other useful features. The project is taken forward after each individual milestone, with partial acceptances for single milestones and checks against the project objectives. This has the nice side effect that your customers will become familiar with the software in small pieces and you’ll get immediate feedback on whether the development is going in the right direction or not. So you see :
An agile approach doesn’t mean that there’s no concept! Quite the opposite – planning is important.
In the planning phase, particularly in terms of effort and deadlines, you have to count on further work after acceptance of the project.
The next post will deal with how to manage agile projects with structure and control.Other blog posts of this series:
A basic content management system works fine for a simple, static website, but for those of us with content-heavy websites—like online news platforms or schools or non-profits—a basic CMS will be hopelessly overmatched. Dynamic companies and organizations need a correspondingly agile CMS to effectively meet their web needs—and the words “dynamic” and “agile” and “effective” are all practically synonyms for “Drupal.”
Drupal is generally regarded as the most powerful and adaptable open source CMS available, and it’s utilized by influential news organizations like Al-Jazeera, powerful NGO’s like UNRWA, and prestigious universities like Georgetown. Additionally, Drupal boasts an active and passionate developer network that ensures that it’s an excellent system because it's constantly evolving to meet your evolving needs.
But a trade-off for its power is its complexity, and the simple truth that Drupal is a powerful tool that can potentially be overkill for a modest website—and this means migrating to Drupal shouldn’t be taken lightly, and that you will need to work with a competent development team.
But if you’re willing to undertake a few simple steps, you can discover whether or not Drupal is the CMS for you and make the process of migrating to Drupal simple and stress free, while unlocking its incredible potential…1. Map your Ambition
This is basic, but necessary, and if you avoid it it can come back to bite you down the road. Identical to if you’re planning on moving your business to a new office or introducing a new product or campaign, you need to turn that idea into a tangible model before you can actually proceed with any direction.
When it comes to migrating to Drupal, this will allow you to estimate how many resources you have to commit to the project and what your expectations are, and will reveal to you how achievable your ambitions are.
You should ask yourself:
- What’s the timeline for your migration?
- How soon do you need to see a return-on-investment?
- Which in-house employee will oversee the transition?
- What do you envision the minimal viable product looking like?
- What potential hangups can you not possibly incur?
- How much is the opportunity cost of upgrading?
Covering these simple steps will make it clearer whether or not you’re ready to migrate to Drupal, and armed with this model you’ll be ready to get the actual wheels turning towards your goal.2. Perform an Organizational Site Audit
The Drupal development team needs to understand your organization's needs if it's going to build a functional website, and that means your organization can’t have a vague idea of what it needs—it needs a concrete understanding. You should comb through your site and analyze its functionality versus your needs. This will save innumerable back-and-forth meetings and potential disaster down the road—when you’re in too far to turn back.
So before collaborating with Drupal designers, you should to be able to identify:
- Which components currently provide value from the source site?
- Which parts need to be migrated from the source site?
- What enhancements to design and functionality does your new site require?
- Which design or functionality features you would like to retain?
- Which required features from the old site will be difficult to integrate because of custom design?
Now, having actualized your ambitions and mapped your situation, you should be able to consult with a Drupal development team and let them dig into your site with a technical site audit. But to do that, first you need to find the right developers for the job–and this should be done carefully.
A couple things to look for when choosing your team:
- Are they Drupal approved?
- Does their portfolio contain similar projects to yours?
As said before, Drupal is a complex CMS, and if you entrust your web development needs to an inexperienced developer or hire a single freelancer to handle a demanding task, the development process will stressful and the eventual product will undoubtedly be flawed.
Freelancers have their merits—but if you contract a Drupal development team with a proven track record of success, you will be dealt with efficiently and professionally. The resulting migration process will be stress-free and your updated site will be up and running promptly.
Migrating to a new CMS can be a daunting process—but it doesn’t have to be. If you put in a little legwork, and collaborate with top-notch Drupal experts like Vardot, your resulting website will satisfy your requirements and put you one step further along the path to success in an increasingly digital world.
Questions or Comments? Respond below or drop us an email and we’ll get back to you no time.Tags: Migrating to Drupal Drupal Development Drupal Planet Title: Ready to Upgrade Your Website? Here's Tips for Migrating to Drupal