Drupal Association News: Sponsored Post: Reclaim Control of Your Server, Running Drupal on a Freedom Host
This article was submitted by our Premium Hosting Supporter Linode.
We’ve all experienced these before: slooow server hardware; unlimited disk space that is capped once you begin to actually fill it; local directory software installs because you’re not allowed to alter the root system. Managed hosting emerged to help solve these problems. And it did - but sacrificed the true power of a host’s infrastructure. Fortunately, an alternative exists that overcomes the deficiencies of both shared and managed hosting. I call it a “Freedom Host.”What is a Freedom Host?
A Freedom Host respects your needs and creativity. It gives you full root access to the server leaving you with the most powerful processors and lightning-fast, solid-state storage.
Why choose a Freedom Host?
“Getting off the Island.”
This counters a long-standing community practice of exclusively using Drupal. We now see large opportunities in combining Drupal with other powerful auxiliary software. Managed providers have long offered users click-to-deploy for Drupal; but where’s the Node.js button? HA Proxy button? Split-DNS? Magento? These options don’t exist on a managed host.A Freedom Host allows you to run what you want when you want.
Security is a priority when running your Drupal website, right? You verify file permissions, sanitize all site forms and enforce strict password rules to protect against risky Internet traffic. But what about protection from other websites on the same server? What about local containers running on the same private subnet as your own? A Freedom Host, whether dedicated or VPS, offers you greater security than what’s provided through today’s shared-hosting or containers.How do I get Managed comfort with Freedom’s power?
Drush – You can install Drush in seconds with full functionality on any Freedom Host.
Control Panels - While many Freedom Hosts provide you with a remote terminal to get started, you can install and run the GUI you want, not just what you’re limited to.
Backups & Monitoring - Any reputable Freedom Host provides a backup solution but additional options are limitless. Save your Drupal site as a tarball, dump your MariaDB/MySQL database or mirror to an external slave server. You can even image the entire server to backup or test locally in VirtualBox. System metric software, including Longview, New Relic or Piwik, measure, graph and store server traffic.So, what can I do with all this Freedom?
While impossible to compile a full list, some interesting Drupal projects I’ve seen include:
- swapping out “Zen” PHP for Facebook’s HHVM for speed improvements in Drupal 8
- testing Drupal 8 using PHP7
- compiling Nginx to include custom features for Drupal
- custom compiling a kernel for improved performance.
A Freedom Host provides options when choosing what and how you run your Drupal website. Options aside, a Freedom Host is more powerful and less expensive than most managed providers. You can’t lose with Freedom.
This article was written by Ricardo N Feliciano. He is currently a Developer Evangelist for Linode, and is an Information Systems Technician in the U.S. Navy.
Few days ago, I've started writing Odorik module to manipulate with API of one Czech mobile network operator. As usual, the code comes with documentation written in English. Given that vast majority of users are Czech, it sounds useful to have in Czech language as well.
First step is to add necessary configuration to the Sphinx project as described in their Internationalization Quick Guide. It's matter of few configuration directives and invoking of sphinx-intl and the result can be like this commit.
Once the code in repository is ready, you can start building translated documentation on the Read the docs. There is nice guide for that as well. All you need to do is to create another project, set it's language and link it from master project as translation.
The last step is to find some translators to actually translate the document. For me the obvious choice was using Weblate, so the translation is now on Hosted Weblate. The mass import of several po files can be done by import_project management command.
And thanks to all these you can now read Czech documentation for python Odorik module.
DrupalCamp St. Louis is scheduled for June 20-21, 2015, and will be held at SLU LAW in downtown St. Louis, MO. Less than a month away, there are a few important bits of news:DrupalCamp STL.15 Keynote Speaker: Alina Mackenzie (alimac)
Alina Mackenzie is a developer and system administrator based in Chicago. In the Drupal community she is a camp organizer, speaker and communications lead for DrupalCon mentored sprints. She is passionate about learning organizations, automation, and making open source friendly for beginners.
Alina's keynote will focus on "Finding the entrance: Why and how to get involved with the Drupal community".
Alina's Drupal.org profile is https://www.drupal.org/u/alimacSession Submission Deadline: May 29
Please submit your session proposals by Friday, May 29—just over a week from today! We'll notify speakers on June 5th whether a session was accepted or not.
We hope to see you at DrupalCamp St. Louis 2015! Registration will open next Monday, and sessions will be announced on June 5th.
It is one thing to be brought into a project as a team player, where the project is managed or you are delivering a predefined piece of it. However, that is typically not the way things happen when doing work for a small business or an initial project which will result in a business launch.
The more challenging and demanding opportunities for a freelancer are those one-man top-to-tail projects: creating the whole megillah. Here is a brief look at the steps that could give the poor shlub a fighting chance.
- Initial Meeting: The client transfers his vision to you. Determine what specifically makes or breaks its success.
Output: Management Summary: Mirror the client’s vision back to him in your own words, for validation.
- Reference site(s): Ask the client to point to sites exemplifying functionality that works and functionality that doesn’t.
Output: Create a spreadsheet that will contain a row for each function, and identify that function as either a launch requirement, nice to have for launch, post-launch, or unneeded.
- Conceptual design: Using the approved spreadsheet, decide what the site will look like.
Output: Some conceptual prototype, such as wireframes, storyboard, etc.
- Functional design: The details behind the elements of the conceptual design; how front-end elements should work, as well as the back-end functionality, business rules, and the seemingly small details (being able to print receipts with a receipt printer, accepting input from card-swipers, syncing with third-party applications, etc).
Output: Functional design document.
In Drupal 7, a hook_node_access implementation could return NODE_ACCESS_IGNORE, NODE_ACCESS_ALLOW and NODE_ACCESS_DENY. If any of them returned NODE_ACCESS_DENY then access was denied. If neither did but one returned NODE_ACCESS_ALLOW then access was allowed. If neither of these values were returned by any implementation then the decision was made based on other rules but at the end of the day some code needed to grant access explicitly or access was denied. Other entities didn’t have access control.
Imagine this scenario. You add three different blocks in your footer region and the mockups call for them to be side by side. Here are 3 ways to accomplish this:Regions
Using regions, we could add and create more footer regions and call them Footer first column, Footer second column, third and forth just like in bartik theme. I personally don’t like this solution because what if we decide in the future to only have 3 columns instead of four? Then we will need to remove regions and change the css, clear the cache etc.. not ideal.CSS
Another way to do this...
Normally, I would do this video style, but I'm a wildcard people and today we write!
A new release 0.2.13 of RInside is now on CRAN. RInside provides a set of convenience classes which facilitate embedding of R inside of C++ applications and programs, using the classes and functions provided by Rcpp.
This release works around a bug in R 3.2.0, and addressed in R 3.2.0-patched. The NEWS extract below has more details.Changes in RInside version 0.2.13 (2015-05-20)
Added workaround for a bug in R 3.2.0: by including the file RInterface.h only once we do not getting linker errors due to multiple definitions of R_running_as_main_program (which is now addressed in R-patched as well).
Small improvements to the Travis CI script.
CRANberries also provides a short report with changes from the previous release. More information is on the RInside page. Questions, comments etc should go to the rcpp-devel mailing list off the Rcpp R-Forge page.
At Drupal Camp London 2015, I spoke with Piyush Poddar, Director of Drupal Practice at Axelerant. We talked about Piyush's history in Drupal, Drupal as a business-ready solution, India's coming of age in open source culture, and how that is driving business value.
Did you have a great time at DrupalCon Los Angeles but want something to show for it?
We are happy to issue a certificate of attendance in PDF format for anyone who picked up their conference badge or signed in at a training.
Simply submit your request via our contact page with the subject "Request a Certificate of Attendance", and be sure to include the associated order number.
How would you like to present at one of the largest PHP conferences in Europe? DrupalCon Barcelona is coming, and we are actively looking for sessions for our new PHP track.
Unlike the Coding and Development track, the PHP track is all about the larger PHP community. We're not looking for Drupal-specific talks but for sessions about PHP itself (PHP 7 anyone?), about related PHP tools like Guzzle, general PHP leading practices, software architecture, and so on.
Yesterday (May 19), the Louisiana Legislature’s House Civil Law and Procedure Committee voted 10-2 to return HB707 to the calendar, effectively voting it down, at least for the current session. The bill would allow businesses to refuse, in accordance with religious beliefs, to provide goods and services on the basis of a patron’s sexuality.
Described as the protection of “the free exercise of religious beliefs and moral convictions”, were the bill to pass it would preclude the state from taking “any adverse action against a person, wholly or partially, on the basis that such person acts in accordance with a religious belief or moral conviction about the institution of marriage.”
However, hours after the committee’s vote, Louisiana Governor Bobby Jindal issued an executive order in an attempt to accomplish much of what HB707 is intended to achieve. We’re aware that at least some of the bill’s opponents doubt the executive order may create substantive law. We’re also aware that the U.S. Supreme Court may issue a ruling (before its current term ends in late June) that preempts any contradictory Louisiana law.Why We’re Talking About Louisiana
Earlier this year, we chose New Orleans as the site for DrupalCon North America 2016. Section 86-33 of New Orleans’ municipal code explicitly forbids discrimination by public businesses and stores. In much the same spirit as New Orleans’ code, we want to take this opportunity to unequivocally state that no one at any DrupalCon should be denied service, assistance, or support because of who they are or whom they love.
Community. Collaboration. Openness. These are our ethos. At our core, we’re as committed to these values being principles for how we treat each other as we are for how we do our work.
The very nature of open source means contributions can come from anyone. That means muting voices is inconsistent with our values. That means we believe inclusivity is progress. And that means it’s important we speak when our community asks questions about the risk of discrimination.
Along with logistics—such as available event space, and costs—our DrupalCon site selection process has always considered whether we’d be able to truly celebrate the diversity of the Drupal community and the spirit of the Drupal Code of Conduct. We believe, despite the bill and executive order, that we can still create a safe, diverse, celebratory space for our community in New Orleans next year. We’re happy to bring the diversity of DrupalCon to New Orleans, and we’re confident it’ll be a fantastic event.Talk To Us
We want to hear about your experiences at DrupalCon New Orleans—any and all of them. Tell us your opinions, voice your perspectives, and share what you see. In the meantime, comment on this post, or email us, with your questions and insights.
Normally I’m sitting at home in Iowa, rocking the boxer shorts on the couch. The Xbox controller is in arm’s reach. Or maybe I’m tearing up a single track course on my mountain bike. But this week, none of that. This week is different.
It’s DrupalCon, so you know I have to put away the games and pack up the power brick so I can join in the fun. I ran through this quick Q&A about my plan for DrupalCon with Promet's marketing team to help understand my goals for this year's big show.
- restructuring website as 21st century style and drop deprecated info
- automate test integration to infrastructure: piuparts & ci
- more test for packages: adopt autopkgtest
- "go/no-go vote" for migration to next release candidate (e.g. bohdi in Fedora)
- more comfortable collab-development (see GitHub's pull request style, not mail-centric)
While developing a system to automate Drupal updates and using that technology to fulfill our Drupal support contracts, we ran into many issues and questions about the workflows that integrate the update process into our overall development and deployment cycles. In this blog post, I’ll outline the best practices for handling different update types with different deployment processes – as well as the results thereof.The general deployment workflow
Most professional Drupal developers work in a dev-stage-live environment. Using feature branches has become a valuable best-practice for deploying new features and hotfixes separately from the other features developed in the dev branch. Feature branches foster continuous delivery, although it does require additional infrastructure to test feature branches in separate instances. Let me sum up the development activity of the different branches.
This is where the development of new features happens and where the development team commits their code (or in a derived feature branch). When using feature branches, the dev branch is considered stable; features can be deployed forward separately. Nevertheless, the dev branch is there to test the integration of your locally developed changes with the code contributions of other developers, even if the current code of the dev branch hasn’t passed quality assurance. Before going live, the dev branch will be merged into the stage branch to be ready for quality assurance.
The stage branch is where code that’s about to be release (merged to the master branch and deployed to the live site) is thoroughly tested; it’s where the quality assurance happens. If the stage branch is bug-free, it will be merged into the master branch, which is the code base for the live site. The stage branch is the branch where customer acceptance happens.
The master branch contains the code base that serves the live site. No active changes happen here except hotfixes.
Hotfixes are changes applied to different environments without passing through the whole dev-stage-live development cycle. Hotfixes are handled in the same way as feature branches but with one difference: whereas feature branches start from the HEAD of the dev branch, a hotfix branch starts from the branch of the environment that requires the hotfix. In terms of security, a highly critical security update simply comes too late if it needs to go through the complete development cycle from dev to live. The same applies if there’s a bug on the live server that needs to be fixed immediately. Hotfix branches need to be merged back to the branches from which they were derived and all previous branches (e.g. if the hotfix branch was created from the master branch, it needs to be merged back to the master to bring all commits to the live site, and then it needs to be merged back to the stage and dev branch as well, so that all code changes are available for the development team)Where to commit Drupal updates in the development workflow?
To answer this question we need to consider different types of updates. Security updates (including their criticality) and non-security updates (bug fixes and new features).
If we group them by priority we can derive the branches to which they need to be committed and also the duration of a deployment cycle. If you work in an continuous delivery environment, where you ship code continuously,the best way is to use feature branches derived from the dev branch.
Low (<=1 month):
- Bug fix updates - Feature updates
These updates should be committed by the development team and analysed for side effects. It’s still important to process these low-prio updates, as high-prio updates assume all previous code changes from earlier updates. You might miss some important quality assurance during high-prio updates to a module that hasn’t been updated for a long time.
Medium (<5 days):
- Security updates that are no critical and not highly critical
These updates should be applied in due time, as they’re related to the site's security. Since they’re not highly critical, we might decide to commit them on the stage branch and send a notification to the project lead, the quality assurance team or directly to you customer (depending on your SLA). Then, as soon as they’ve confirmed that the site works correctly, these updates will be merged to the master branch and back to stage and dev.
High (<4 hours):
- Critical and highly critical security updates
For critical and highly critical security updates we follow a "security first" strategy, ensuring that all critical security updates are applied immediately and as quickly as possible to keep the site secure. If there are bugs, we’ll fix them later! This strategy instructs us to apply updates directly to the master branch. Once the live site has been updated with the code from the master branch, we merge the updates back to the stage and dev branch. This is how we protected all our sites from Drupalgeddon in less than two hours!Requirements for automation
If you want to automate your Drupal security updates with the Drop Guard service, all you need is the following:
- Code deployment with GIT
- Trigger the update of an instance by URL using e.g. Travis.ci, Jenkins CI, DeployHQ or other services to manage your deployment or alternatively execute SSH commands from the Drop Guard server.
- Know what patches you’ve applied and don't forget to re-apply them during the update process (Drop Guard helps with its automated patch detection feature)
- Automated tests reduce the time you spend on quality assurance
Where to commit an update depends on its priority and on the speed with which it needs to be deployed to the live site. Update continuously to ensure the ongoing quality and security of your project and to keep it future-proof. Feature and bug fix updates are less critical but also important to apply in due time.
For those of you interested in Drop Guard to automate the process as described in this blog post, please sign up for the free trial period so you can test all its features – for free – and get a personal on-boarding.
This morning, I pushed out version 2.11.17 of the Geode X.Org driver. This is the driver used by the OLPC XO-1 and by a plethora of low-power desktops, micro notebooks and thin clients. This is a minor release. It merges conditional support for the OpenBSD MSR device (Marc Ballmer, Matthieu Herrb), fixes a condition that prevents compiling on some embedded platforms (Brian A. Lloyd) and upgrades the code for X server 1.17 compatibility (Maarten Lankhorst).
- toggle COM2 into DDC probing mode during driver initialization
- reset the DAC chip when exiting X and returning to vcons
- fix a rendering corner case with Libre Office
‘Love thy neighbor as thyself’, words which astoundingly occur already in the Old Testament.
One can love one’s neighbor less than one loves oneself; one is then the egoist, the racketeer, the capitalist, the bourgeois. and although one may accumulate money and power one does not of necessity have a joyful heart, and the best and most attractive pleasures of the soul are blocked.
Or one can love one’s neighbor more than oneself—then one is a poor devil, full of inferiority complexes, with a longing to love everything and still full of hate and torment towards oneself, living in a hell of which one lays the fire every day anew.
But the equilibrium of love, the capacity to love without being indebted to anyone, is the love of oneself which is not taken away from any other, this love of one’s neighbor which does no harm to the self.
I always have a hard time finding this quote on the Internet. Let's fix that.
I wrote well over one year ago about Earthlings. It really did have some impact on my life. Nowadays I try to avoid animal products where possible, especially for my food. And in the context of vegan information that I tracked I stumbled upon a great band from Germany: Berge. They recently started a deal with their record label which says that if they receive one million clicks within the next two weeks on their song 10.000 Tränen their record label is going to donate 10.000,- euros to a German animal rights organization. Reason enough for me to share this band with you! :)
- 10.000 Tränen: This is the song that needs the views. It's a nice tune and great lyrics to think about. Even though its in German it got English subtitles. :)
- Schauen was passiert: In the light of 10.000 Tränen it was hard for me to select other songs, but this one sounds nice. "Let's see what happens". :)
- Meer aus Farben: I love colors. And I hate the fact that most conference shirts are black only. Or that it seems to be impossible to find colorful cloths and shoes for tall women.
Like always, enjoy!
Jim Birch: Using Drupal's Environment Indicator to help visually manage Dev, Stage, and Production Servers
There are days that I work on half a dozen different websites. I'm sure some of you are in the same boat. We make client edits and change requests with rapid effieciency. We work locally, push to staging, test and review, then push to the live server and repeat. I would be remiss in saying that I never made a change on the live or staging site accidentally.
The Drupal Environment Indicator module allows you to name, color, and configure a multitude of visual queues for each of your different servers, or other variables, like Git branch or path. It is very easy to install, and can integrate with Toolbar, Admin Menu, and Mobile Friendly Navigation Toolbar for no additional screen space.
Once installed, set the permissions of the roles you want to give permission to see the indicator. You can adjust the general settings at /admin/config/development/environment-indicator/settings
While you can create different indicators inside the admin UI, I prefer to set these in the settings.php files on the various servers so they are not overidden when we move databases back from Production back to Staging and Dev.