Most people think that the things they experience are real... But they are wrong... This can be seen as an illusion if we go to a different culture, or if we enter a different reality by going insane.
This is Jack:
Usually, Jack is theming beautiful website like these:
But when Jack's not in the office, he's got other things on his mind:
So when Jack's son grew out of his old room, Jack took on a new theming project:
Pretty delightful, huh?
And here's a bonus shot of Jack in his son's old room, where he video chats us from:
Yup, that's a monkey in a tree back there.
A common issue that many Drupal developers have is maintaining consistent configuration across environments. Quite often, a developer may run into an issue where something that was tested and confirmed working in development fails in production, or vice versa. Typically, the issue stems from an undocumented change that was made in one environment but not the other. This is an adverse side effect of storing configuration within the database.
Ideally, all configuration should be under version control. In Drupal 8, this issue has been solved by the Configuration Management Initiative. However, to achieve the same goals in Drupal 7, one must implement workarounds.
For variables, it's rather trivial to enforce certain parts of your configuration. When it comes to the variable system, the $conf global has the final say on the value of a variable. The variable_get() function simply retrieves a variable from the global $conf array, and that array is built from the variables table with values in settings.php overriding the retrieved values. Basically, there are two ways to find out what variables on your site you can force via settings.php: the most thorough is to print out the $conf array (preferably through dpm()), but you can also search for instances of variable_set() and variable_get(). Looking for variable_get() might also expose undocumented but useful variables.
But what about more complex pieces of configuration, such as fields, Views, entity types, etc? In many cases, you can export those with the Features module. However, in order to be successful in using Features to manage the configuration of different parts of your site, you need to implement a policy that overridden Features modules in production should be considered broken.
But what about things that aren't exportable to Features? What about special steps that need to be taken to implement a bug fix or new feature? We like to leverage hook_update_N() within a custom deployment module. With this approach, we're able to define (and therefore easily document) changes in code (and therefore under version control) and simply use "drush updb" to implement them. (If you're not using Drush, and you really should be using Drush, this is the same as running update.php.) We put all of our configuration changes in one of these hooks in our deployment module, including variable_set(), module_enable(), module_disable(), features_revert() for any Features that we have changed, database queries to fix data issues caused by previous bugs, etc.
This has several advantages. For one, deployments become a lot simpler. Ideally, you want your deployments to be hands-off. What this method allows us to do is write a simple deployment script that pulls the new code from Git, put the site into maintenance mode, runs a registry rebuild via drush just in case we moved a module (some moves can cause white screens of death if you don't do this), runs updates via Drush, clears cache (just in case), runs cron (just in case), and takes the site back out of maintenance mode. In cases where we manage the ops side or the client's ops team allows, we'll also send a notification to the monitoring system to make sure that the new deployment is noted (very useful for determining when a problem was introduced).
Another key advantage is documentation. With configuration changes made via update hooks, we can tell exactly when configuration changes were introduced and by whom. It also all but eliminates the risk of a costly missed step on deployment to production as the deployment steps themselves are tested when a developer updates their development environment.
For some configuration settings, such as enabling a debug mode for a particular module, we may want to allow those changes to be made temporarily through the UI. However, accidentally leaving those debugging settings enabled can cause performance issues. In these cases, we combat this by defining critical settings in an implementation of hook_requirements(). (This only works for settings that have not been defined via the global $conf variable.) Using hook_requirements(), we're able to check that settings are appropriate for the environment (typically limited to production) and display a message to users with proper access if they are not in order to warn them that they need to adjust that setting back to the appropriate value.
But what should we do with hook_install()? There are two schools of thought here. One is to define all of your final configuration here, and the other is to loop over your implementations of hook_update_N(). I prefer the latter. While looping over hook_update_N() can be a more expensive process if your site has gone through some serious evolution, it's less duplication of code and less of a chance for you to miss something important. The goal of our use of hook_install() is to eliminate database cloning by only requiring the developer to install the deployment module to initialize a fully functional development version of the site.
Eliminate database cloning? For the most part, yes. Database cloning is a bad practice, even cloning upstream from production. Databases can be huge, and cloning a huge database can impact the performance of the site for your users. Databases can contain sensitive information (most standards dealing with the handling of sensitive information dictate that sensitive information only be accessible to those who absolutely need to access it), and most developers don't need access to sensitive information. Databases in production while a bug existed in production don't usually fit the requirement of presenting a known good starting point for development. Believe it or not, your content and customer information are not necessary for development.
So what can we do about content and other information? The answer is to generate it. Generate dummy content. Generate dummy orders. Generate dummy products. And so forth and so on. If you're doing automated testing, you will be having to do that anyway.
There are exceptions to not cloning the production database. Sometimes you will run into bugs that seem to only occur in production. In this case, it is acceptable to clone the database because the bug is likely caused by something that was unanticipated. However, when fixing these bugs you should take steps to ensure that whatever content or other information change that surfaced the bug is tested for before deploying to production thereafter.
Another exception is if you are using a staging and/or QA environment. In this case, you will want to clone the production database upstream to staging/QA just before deploying your fresh code to staging/QA. You need to do this to absolutely ensure that the changes in your deployment module cover all of the changes that will need to be made to production.
Finally, it's important to test. Writing the actual tests are outside the scope of this post, but it is important that you have automated tests in place that ensure that your site is configured exactly how you need it. Even if you have tests for your site's custom modules in those modules, you need to test your deployment module. The goal here is to fail fast. By having a separate test group for your configuration, you can have Jenkins (or whatever other continuous integration software you use) proceed to other tests only after your configuration tests have passed.
Shadowgate Blog #1 - The Story of the MacVentures, Shadowgate and its Re-imagining - by Karl Roelofs
In our web hosts we trust, right? Right. They safeguard your nonprofit’s website, ensure it can handle your incoming traffic, and, perhaps most importantly, they backup your site so that if for some reason, your website ever imploded, it wouldn’t be lost for good.
But just how accessible are those backups? How surefire is your contingency plan? Have you tested it out? A lot of website administrators will find that actually initiating this plan isn’t as easy as it may seem. Those backups might take hours or days of ticketing and waiting to get a hold of, particularly if your website host is already inundated with other customer support issues. What then are you to do when something breaks and the site comes tumbling down?
Enter NodeSquirrel. NodeSquirrel is a Drupal backup service developed and maintained by Gorton Studios. It gives site admins control over their site backups. I sat down with Gorton Studios’ Drew Gorton and Keri Poeppe to learn why nonprofits should consider making NodeSquirrel a part of their workflow.
Stephanie: So what exactly is NodeSquirrel?
Keri: It’s a system for creating, managing, and securely storing website backups. Drupal developers out there will know the Backup and Migrate module. NodeSquirrel extends Backup and Migrate, allowing you to make backups of your website and store those backups in the cloud.
Drew: Backup and Migrate is one of the most popular modules in Drupal. One of the reasons it’s so popular is because it’s easy to create a backup. But by default, that backup stays on your server. What we’re trying to do with NodeSquirrel is make it easy to get that backup off of your server and move it somewhere safer - in this case, Amazon’s cloud. What makes NodeSquirrel such an integral addition to your regular hosting is that it’s something you can use whenever you need to access those backups. Getting to your web host’s backups and testing them can be difficult - and just because they’re backed up doesn’t mean they actually work. With NodeSquirrel, there are no surprises. You can get into your backups, make sure nothing is corrupted, and restore it yourself rather than wait on your host.
Stephanie: How does NodeSquirrel accomplish this?
Keri: NodeSquirrel is an off-site destination, but the process of getting the copy of your site uses the Backup and Migrate Module.
Drew: Here’s an example: there was a NodeSquirrel user whose site was being backed up daily by their web host. Unfortunately, that organization had a major failure and needed to restore the whole site, but the backups they received from their host were unusable. The host had to go back two months to find a backup that actually worked. And, this was from a hosting service costing at least $100 a month.
NodeSquirrel, luckily, was running on their site and they were able to use one of the backups stored on the cloud. It saved them. The problem is that no one ever tests hosting company backups. It’s stored by your host, but no one ever goes back and to check the integrity of the backup and figure out if it can be used when something goes wrong.
NodeSquirrel is different because it’s part of Drupal and the Drupal workflow. We’ve made it easy for you or your developer to retrieve and test your backups.
Stephanie: What sets NodeSquirrel apart for the competition? What sort of functionality can I expect from it?
Keri: It’s unique in that it makes a very specific kind of backup. It copies the database, code, and the files rather than making a backup of the whole server and all of the extra infrastructure. It’s not a lightweight backup, but it’s one that can be very targeted, and you can be more nimble with it. For example, if someone accidentally deletes a blog post or wipes out blocks on the homepage, you can quickly restore the website from a NodeSquirrel backup. You don’t need to spend lots of money or staff time recreating the blog post or home page! And you don’t need to call your hosting company to solve the problem. I think what distinguishes it from standard backup systems is how much control users have over the management of their backups. NodeSquirrel’s settings are managed in your site’s backend, so your website administrator has full control of your backup schedule and functions. Want to backup your site every hour? Go for it. Make the system as robust or as hands-off as you like. You can have that level of control and granularity.
Stephanie: How can I tell if my organization needs a service like NodeSquirrel? Is there such a thing as being "too small?"
Drew: It’s very affordable for anyone who’s invested time and money into their website and wants to safeguard that investment. The site is probably too valuable not to backup. We wanted to make this service accessible and affordable, so for about $100 a year, you’ll have this extra protection. Versus the time you spend trying to fix a bad backup, this is a better alternative. With that price point, it’s more of a question of "why not?"
Stephanie: It sounds like NodeSquirrel offers users a lot of options. Is there anything it won’t protect against? What doesn’t it do?
Drew: Most people ask how it compares to their standard hosting, since we have no direct competition. It’s not a full-server backup or a backup for a complex server. It doesn’t backup your DNS settings or load balance configuration. Typically though, if you have a complex setup, you’ll have a system admin or a disaster response team in your organization. Even if you do, NodeSquirrel might still be supplemental and helpful as an extra layer of protection.
Keri: If you can’t call your hosting company and see a backup, you might want to think about NodeSquirrel.
Drew: That’s actually a great way to test your site host. Call them and ask to access your backups. How long will it take? Will they charge you extra to set up a test environment?
Keri: Download and restore a backup. There’s your test to see if you can sleep easy at night. With NodeSquirrel, you can.
Stephanie: Is there anything else we should know about NodeSquirrel? Any tips for getting the most out of the service?
Keri: I’d stress the low threshold to use it. It requires no additional software. It’s integrated seamlessly, especially if Backup and Migrate is already installed. Ask your developers to install version 3 of Backup and Migrate. It’ll give you the most flexibility. NodeSquirrel is free to try, too. We have a trial offer that allows you to make 20 free backups. No credit card required.
Drew: We wanted to make it easy to do the right thing, and having onsite backup is the right thing. If it works, keep on going.
NodeSquirrel is a highly-affordable extra layer of protection that could save you and your stakeholders a major headache and a great deal of money in the event of a site meltdown. Even if your hosting provider has a backup solution, in the event of data loss, NodeSquirrel is a great alternative to sitting in support queues, waiting on your web host to resolve the issue.
With NodeSquirrel, you can take complete ownership of your backups and spare yourself the worry of whether or not you’ll be able to get your site up and running. It’s poised to integrate beautifully with your Drupal website administrative workflow, allowing you to safeguard your investment without having to spend time building new safety net systems. With plans starting at $9/month, it’s a question of "can you afford not to use NodeSquirrel?"
Want to see it in action for yourself? Sign up for the free trial. If you do take it for a spin, let us know what you think in the comments section.
"I believe gaming addictions exist but that the number of gamers that are genuinely addicted comprises a small minority... the number of genuine video game addicts is few and far between." ...
Following reports that LINE Corp, the Japanese company behind the LINE Game Platform, would soon file for an initial public offering, the company has now gone ahead with the filing. ...
When D8Rules project waiting in a Funding phase had just seven days left to be successfully funded, success didn’t seem likely. The project had raised just over 40% of its funding goal so far. The days shortened; the pressure rose. Happiness exploded exactly two days before the finish line thanks to the rescuing amount which came just in time.
The Biggest Nest of Funders So Far
We know that the Drupal Community is generous in donating money. They confirmed it again in the case of the ‘D8Rules - Support the Rules module for Drupal 8’ project. Together, 138 backers funded 106% of its funding goal. It equated to 15.973 dollars. With this number, D8Rules is, for the moment, the biggest project successfully funded onDrupalfund.us.
Public crowdfunding for D8Rules on Drupalfund started on May 13th. In one day, funders covered 8% of the funding goal already—quite good for a start. During the first two weeks the donating line grew and then it became static. The days were flowing away and more than a half of the final amount was still missing. What happened next?!
Experienced Early Access and second screen app developers join the lineup of speakers exploring the art and business of games at GDC Europe 2014 this August in Cologne. ...
"You realize that you don't deserve to be here. You do not belong. You see amazing, talented people with more experience and talent, and you know you aren't qualified to work in their industry." ...
We in the Drupal community probably know something about Drupal 8 – even if it's just that we're aware it's coming!
But how do you clearly and simply highlight the benefits of Drupal 8 to a non-developer audience, or those beyond our community?
How can you then potentially create a non-dev community of Drupal 8 advocates and share good practice?Introducing Drupal 8 personas What is a persona?
A persona is a ‘person' that represents a specific group of users.
Organisations and companies can use intel from personas to create, for example, a piece or pieces of content that will:
- Highlight expectations and use of your site for your end user
- Help drive the benefits in a way that will be immediately understood by the audience
Deeson Online have been working of a series of personas to help clearly articulate the benefits of Drupal 8.How did we create Drupal 8 personas?
Using interviews with a range of Drupal and non-Drupal users, we got to grips with all the pain points for a range of potential Drupal 8 users. Using Dries Buytaert’s personas from his DrupalCon Prague Keynote speech as a starting point, we then focused on:
We then carried out a series of interviews via Skype and Google Hangouts asking people from across the globe from each of these user groups over 30 questions.
These questions ranged from "How many people work in the company?" to "From the time you wake up to the time you go to bed, what does a day in your working life look like?"What did we do with the answers?
We then analysed all the responses, reducing them down to one 'persona' per user group, ensuring that we captured the persona needs and pain, then matching them against how Drupal 8 will help.The result
A range of easy to consume dowloadable infographic persona fact sheets, that established and potential users can read and share.
The results so far have been really positive. The infographic personas are proving especially useful for those within our community to have something to refer to when talking not just about the power and benefits Drupal 8, but Drupal itself.So learn more about Drupal 8, download the persona infographics and share the Drupal love!
Continuous integration platforms are a vital component of any development shop. We rely on it heavily to keep projects at the quality they deserve. Being early adopters of Docker (0.7.6) for our QA and Staging platform we thought it was time to take our CI environment to the next level!
To use this tool, you must create an Instagram "Client" through Instagram's Developer UI. After installing and enabling the module, you can then add your credentials Instagram Client credentials to the site at admin/config/services/instagram.