Planet Drupal

Subscribe to Planet Drupal feed
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 16 min 7 sec ago

Zivtech: Website Documentation Tips and Insights

Wed, 26/08/2015 - 13:30

Managing a website without documentation is like trying to put together Ikea furniture without the directions--it's just not happening. Often, documentation is overlooked by companies and organizations on a budget, but it is a truly invaluable part of building a new website. Check out some great tips and tricks from our team of technical documenters, and learn how we provide our clients with documentation for their sites.

Write with Efficient Tools Writing documentation requires generating dummy content, and our earlier post on lorem ipsum generators give you lots of tools for generating placeholder text. However, technical writers also need to create annotated screenshots to accompany the words that they write, as well as repeat the actual technical steps they are documenting. So here are some additional tools we found to be great assets to a documentarian's repertoire:
  • Awesome Screenshot - Use to take screenshot of a full webpage with auto-scrolling. Also provides a link to share your screenshot (stored on the cloud).
  • Window Resizer - Save pre-configured browser window sizes to capture your responsive design layouts.
  • No Scrollbars Please! - Remove the scrollbar from your browser to take a clean screenshot (especially of a webpage requiring scrolling).
  • Skitch - Use to capture desktop screenshots and annotation with arrows and text. We use it in combination with the extensions above.
  • Firefox Selenium IDE - Automate the repetitive technical steps that you are documenting.

Confluence Macros If you use Confluence (an Atlassian product for documentation that integrates with JIRA), then check out the following Confluence macros which we find to be extremely useful.
  • Code Block - Insert code snippets throughout a page with syntax highlighting
  • Excerpt and Excerpt Include - Reuse a part of documentation on multiple pages
  • Expand - Initially hide some documentation as a link, which expands to display content upon a click on the link
  • Info, Tip, Note, and Warning - Callout important information, such as status of the feature documented and release versions.
  • Panel - Add border (like a box) to separate some documentation from the rest
  • Table of Contents - Great for the beginning of a tutorial guide or as a sidebar on a long page
  • Page Tree - Great on a page that introduces a topic with sub pages

Be Agile with Documentation

If you are agile, your documentation can be too. In a Johnson & Johnson Drupal project, we are providing documentation services as technical writers embedded amongst developers. Because we are integrated as part of their agile development process, we track our work in JIRA, participate in standups and retrospectives, such that documentation is continuously up to date with each sprint. We find that writing in agile iterations is a great way to capture feedback from various parties involved, including product owners, developers, and users in trainings. This way, strong documentation can be produced to maximize support for everyone on the project. Writing technical documentation is easier and more efficient to do in-sprint, while the features being documented are still present in the minds of the developers and product owners.

Find the Voice for Your Audience Documentation being agile also means that you can adapt your writing voice to best suit your audience. Try to always learn more about your audience as you write documentation throughout the project. So far, this blog post has been written in an informative, technically instructional voice. Now say that our audience wants something lighter, more familiar, and empowering, then perhaps we should adapt our voice to something as follows.

Ask Not What Your Product Can Do For You — Ask What You Can Do With Your Product

When doing technical writing, it's easy to be... well, too technical. Just because you're a "technical writer" doesn't mean you should think of your audience as "technical readers." Your audience consists of people that want to do things. Empower them! Don't drone on and on about how "this product does many things" (yawn), when you can enable your reader by telling them "You can do many things with this product!" Yes, sometimes the product simply "provides," but any opportunity you have to inform the reader of what they can do, instead of telling them what the product does, take it.

  • Boring: "From the dropdown menu, a number of items are available. Selecting one will customize this feature."
  • Empowering: "By clicking the dropdown menu, you will see a number of items available to you for customizing this feature. Choose the option that best embodies the spirit of your brand."
Much better, right? The first example, while technically sufficient, does little to engage the reader, and does the bare minimum to inform them of what needs to be done. The second example puts them in charge of driving the product, and uses "you" to communicate directly to them. Also, the second sentence of the empowering example informs the reader of what their motivating reason behind making their choice is. Don't just tell your readers how to do things; let them why they're doing things and what it can do for them and/or their business.


Every website is different, so technical writing should be flexible, adaptive, and leverage the best tools to complete documentation for its team.

Want to learn more about about documentation? Check out our Training & Documentation page. Terms: Related Services Training We turn smart people into great developers. Read more
Categories: Elsewhere

Realityloop: Drupal Development tips for Common Problems

Wed, 26/08/2015 - 08:21
26 Aug Jarkko Oksanen

Some problems when developing are simply annoying, and show up again and again. Many of these are relatively tricky to solve without knowing the best solution for the problem. I’ve combined my answers to a few of these problems that I've found I run into often.

1. You need to access Drupal site with no login details

Sometimes it just happens that there will be a website that you need to manage, and you don't have the administration password for it. You might think that there is a reset password functionality, but if the email of the administrator is invalid, getting the password is not so simple.

Use Drush to generate an one-time login link

This is a very quick and easy way to get logged into Drupal. It only requires that you have server access and Drush (http://www.drush.org/) is installed. The drush command you would use is:

drush uli

Drush will then output you a one-time user login link for this particular website. The Drush command has options that you can add to it that are listed below.

--browser : Optional value denotes which browser to use (defaults to operating system default). Set to 0 to suppress opening a browser.
--uid : A uid to log in as.
--redirect-port : A custom port for redirecting to (e.g. when running within a Vagrant environment)
--name : A user name to log in as.
--mail : A user mail address to log in as.

A more advanced command example would be:

drush uli --browser=firefox --name=admin node/2

This would log you in using firefox, for the admin user, and redirect you to node/2.

For more to read on Drush check out http://www.drush.org/en/master/

Update password using the database

In the case Drush isn’t available, your only option may be accessing the database. The idea is to simply change the encrypted password to another one through the database. If you’re using a GUI such as Sequel Pro, all you need to do is to navigate to users and change the encrypted password of the user admin.

Without a GUI, you can do it with a simple MySQL query.

UPDATE users SET name='admin', pass='$S$DfQ/y58nGpZvyRLYd3LSyJ.s82xSC3Z.2oxdCIL4EHKAYcQnDl9T' WHERE uid = 1;

This would set the password of admin, if its the uid 1, to “lol”. This is an encrypted password string. To create your own password hash you can navigate to Drupal docroot and run the following command.

php scripts/password-hash.sh 'yourpassword'

And it will generate you an encrypted password.

Use a module to hack your way through

This is a solution I would only use on local setups to change my password. There is no real use case for using this on production servers, as it logs everyone in as user 1 that try to access the site. However, if you don’t have any server access, and can only push code to the server, this might be your only shot.

  1. global $user;
  2. $user = user_load(1);

Then you can go change the account settings or promote other users to uid 1.

 

2. No images show up on my local development site

As we know, Drupal consists of three components, the database, the codebase and the files. The third one is considered the least important when developing, but to thoroughly test your work you do need the images to show up.

There is often an issue that the Drupal site that you are working on has hundreds if not thousands of large images which could end up as large as 10gb downloads, and downloading this for your local setup is simply not worth it. Fortunately there are a few solutions that you can use to conquer the problem.

Stage file proxy

https://www.drupal.org/project/stage_file_proxy

Stage file proxy regenerates the image links in a way that they will use the production server to get the images, and doesn't make you download them to your local setup. However default behavior of the module downloads the files when they’re missing. I encourage using the “Hotlink” mode of the module which does as previously explained.

Installing Stage File Proxy can be as simple as :

  1. drush en stage_file_proxy -y
  2. drush variable-set stage_file_proxy_origin "http://www.example.com"

But in most cases I find that saving the settings manually from the configuration is needed. It supports even locked in sites, with more documentation at https://www.drupal.org/project/stage_file_proxy.

Using JS to populate images with a dummy image

If you are working without an internet connection or there are issues with stage file proxy, then what you can do is to use JS to populate broken images with dummy images. This doesn't respect Drupal image styles, but it is a way to play with images. Add it to your JS after document ready.

  1. $('img').error(function(){
  2. $(this).attr('src', "/dummy-image.jpg");
  3. });
3. Getting a database without server access

Getting a database, files and code from your Drupal website can sometimes be tricky, especially when you have no server access. For example; you are working on a client site that has been forgotten somewhere in the cloud for a year, and no one has access to the server, there is still a solution you can try to get a copy of the site.

Use the Backup and Migrate module.

https://www.drupal.org/project/backup_migrate

Fortunately most cloud servers allow modules to be installed on the fly. All you need to do is to use Drupal UI to install this module and you’ll be able to get a copy of the website easily. To do this you need to enable Update Manager, and then install the file using /admin/modules/install user interface. If the server where your website is does not support this, then you need to gain access to the server.

The latest version of the Backup and Migrate module allows you to get a whole site with database, files and code. For simpler sites, using this module is great.

4. Moving modules around in a Drupal setup causes errors

Drupal gets angry when you move modules around in a setup. When you as a developer get your hands on a drupal website that other people have worked on, often the first instinct is to move the modules into a correct directory. Doing this can cause errors on the site and often results in a WSOD.

The error that results is often something like follows:

Fatal error: require_once(): Failed opening required '/profiles/profile/modules/contrib/entity/includes/entity.inc' in /profile/includes/bootstrap.inc on line 3161

This is due to Drupal looking at functions where they were before, and now don’t exist anymore. To fix this issue you need to fix the module paths.

Repair paths via drush registry rebuild

Drush to the rescue again! Compared to the manual solution explained after, this is definitely faster and a safer solution. Install Drush rebuild registry by running the following command (you need to have drush installed first):

drush dl registry_rebuild

After you’ve moved the modules to the directory you want just run the drush registry rebuild command.

drush rr

This will go through your module registry and fix all of the broken connections.

Then clear your drupal caches, and if needed re-run the drush rr command.

Do not blindly trust the power of this command on production servers. I would recommend thorough testing before moving modules around and doing these changes on live sites, as it can become a mess. Always remember to take a backup of your database!

Repair module paths manually

If for some annoying reason you cannot use the power of Drush, or it has failed you, you can still do things manually. Manually fixing is time consuming if you’re doing a lot of changes to your directory structure. Remember to backup your database before starting.

  1. Make sure you’re logged in your Drupal setup before moving the modules. This allows you to access the /admin/modules page. Accessing this page rebuilds the system table which might solve your problem. Move your modules to the directory you want, and access the /admin/modules page.
     
  2. If the problem still continues you need to manually fix the following tables: system, registry and registry_file. The have filenames for each module, these need to be fixed as they are pointing to wrong directions. The following query is an example and was used when moving modules from the profile to a sites/all/modules/contrib setup.

    1. UPDATE system SET filename = REPLACE(filename, profiles/myprofile/modules', 'sites/all/modules/contrib');
    2. UPDATE registry SET filename = REPLACE(filename, 'profiles/myprofile/modules', 'sites/all/modules/contrib');
    3. UPDATE registry_file SET filename = REPLACE(filename, profiles/myprofile/modules', 'sites/all/modules/contrib');

     

  3. After doing the changes, clear your Drupal caches and keep your fingers crossed for success. You might need to clear all the caching from the database as well.

5. Creating your re-usable local.settings.php

This is more of a personal touch. In my local development I’ve tried to create a local.settings.php that is relatively universal to all of my projects.

There are modules that always cause issues with local development such as securepages, or just need config, such as the before described stage_file_proxy. The local.settings.php is a file that is added to your docroot to provide these settings and make it faster for you to develop.

  1. # Local site configuration settings.
  2. if (is_readable('/path/to/site/sites/default/local.settings.php')) {
  3. include_once('/path/to/site/sites/default/local.settings.php');
  4. }

And on your local when you’re setting up your site, you just add your optimal local settings php.

This is my current version of the local.settings.php. Check out my latest one at GitHub and feel free to contribute to it, or add your comments below. The idea would be to include as much as I can in a file, as extra config doesn't really matter!
This will speed up your development by making sure that the settings you want are there, and most importantly done without clicking around the site!

  1. global $conf;
  2.  
  3. // Turn off Secure Pages. Secure Pages Module.
  4. $conf['securepages_enable'] = FALSE;
  5. $conf['https'] = FALSE;
  6.  
  7. // Stage File Proxy Configuration
  8. $conf['stage_file_proxy_origin'] = 'http://mysite.com';
  9. // Stage file optional with securepages
  10. // $conf['stage_file_proxy_origin'] = 'http://username:password@mysite.com';
  11. $conf["stage_file_proxy_use_imagecache_root"] = FALSE;
  12. $conf['stage_file_proxy_hotlink'] = TRUE;
  13.  
  14.  
  15. // Turn off Caching.
  16. $conf['cache'] = 0;
  17. // Block caching - disabled.
  18. $conf['block_cache'] = 0;
  19. // Expiration of cached pages - none.
  20. $conf['page_cache_maximum_age'] = 0;
  21. // Aggregate and compress CSS files in Drupal - off.
  22. $conf['preprocess_css'] = 0;
  23. // Aggregate JavaScript files in Drupal - off.
  24. $conf['preprocess_js'] = 0;
  25.  
  26. // Minimum cache lifetime - always none.
  27. $conf['cache_lifetime'] = 0;
  28. // Cached page compression - always off.
  29. $conf['page_compression'] = 0;
  30.  
  31.  
  32. // Turn off other caching.
  33. $conf['css_gzip'] = FALSE;
  34. $conf['javascript_aggregator_gzip'] = FALSE;
  35.  
  36.  
  37. // Turn on all error reporting for local development.
  38. error_reporting(-1);
  39. $conf['error_level'] = 2;
  40. ini_set('display_errors', TRUE);
  41. ini_set('display_startup_errors', TRUE);

This will speed up your development by making sure that the settings you want are there, and most importantly done without clicking around the site!

These are just some of the problems have come up during the days. If you have one you’re always running into, feel free to leave a comment about it!

drupal planetdrupaldevelopmenttips
Categories: Elsewhere

Modules Unraveled: 146 Drupal Update Automation and Drop Guard with Manuel Pistner - Modules Unraveled Podcast

Wed, 26/08/2015 - 07:00
Published: Wed, 08/26/15Download this episodeUpdate Automation
  • I’d like to talk a little bit about automation processes in general before we jump into Drop Guard, if that’s okay. What types of things are we talking about updating? Server configuration? Drupal projects? Deployment?
  • What are some of the technologies you were using before developing Drop Guard? Maybe the underlying pieces that make up the Drop Guard architecture.
Drop Guard
  • What is Drop Guard?
    • Simply put, Drop Guard is a service to automate Drupal updates with seamless integration into development and deployment processes. Drop Guard helps Drupal shops and other Drupal support and service providers to automate their update work. In case of critical security updates Drop Guard will update the site automatically within 1 hour. This makes the operation of a site more secure and reliable and makes Drupal updates a full part of the development process.
  • You said it’s “integration into development and deployment workflows.” What do you mean by that?
    • Drop Guard works simply as a dedicated team member that is responsible for applying updates in the development as well as in the maintenance and support life-cycle of a project. You can configure Drop Guard to work with any hosting provider and with any team workflow. Drop Guard can execute different Rules-Based commands to trigger deployment actions just as a real team member would do it on manual update work.
  • How granular can you get with updates? Security only? All updates?
  • How does Drop Guard actually work? Is there a module to install? Server setup?
  • What happens if a bug is introduced with an automatic update? Is there a process to notify the developer?
  • Who is Drop Guard designed to be used by?
    • Drop Guard is designed to help Drupal agencies and freelancers to deliver Drupal update services automatically. Every Drupal shop can use Drop Guard as a white label service to deliver update services to their clients as part of support contracts. For end users that don’t understand the processes behind deployment and developement deeply enough, the service is too complex but Drupal shops will definitely benefit from additional developer time that they can save for their project business.
  • What prompted you to start building the Drop Guard service? And when was that?
    • We started with the base technology in 2012 to build a system for our internal support contracts. We had the need to automate recurring things and ensure that our SLAs for security patches are processed reliably. When Drupalgeddon shocked the Drupal world and many sites had to be patched in a very short period of time, we already had the benefit of automated updates for our supported projects. At this point I realized that the system might have a benefit for other Drupal shops. So Drop Guard has its birthday with Drupalgeddon :-)
  • Do you have any insights of the roadmap of Drop Guard?
    • Sure! Currently we are in an internal Beta phase. That means we harden the service with some trusted users and we will add more beta users each week till the end of September.Then we will open Drop Guard for a public Beta version where everybody that is interested can start using the service with the help of our support team. I am sure that there are many usability issues we will face as the high flexibility results in a more complex configuration processes. But thanks to our current beta users we were able to address and fix many of them till now. Also the Feedback from Drupalcon Barcelona visitors will be an important milestone for us.
  • Does this work with all hosting providers? (VPS, Pantheon, Platform.sh, Acquia cloud etc.)
  • What does the pricing structure look like after the beta period?
  • You mentioned there’s an incentive for people to get involved with the beta now. Do you want to talk about that?
Episode Links: Manuel on drupal.orgManuel on TwitterDrop Guard on TwitterDrop Guard WebsiteDrop Guard WebinarTags: Automationplanet-drupal
Categories: Elsewhere

OSTraining: Drupal Error: More Than 5 Failed Login Attempts

Wed, 26/08/2015 - 02:22

If you've forgotten your Drupal password and try unsuccessfully to login, you may get this message:

Sorry, there have been more than 5 failed login attempts for this account. it is temporarily blocked

The image below shows how the message appears. I'm going to show you how you can fix this error.

Categories: Elsewhere

2bits: Re-Indexing your content to Solr, the fast way ...

Wed, 26/08/2015 - 00:00
There are rare occasions when you want to re-index all your site's content in Solr. Such occasions include: Major Drupal version upgrade (e.g. from Drupal 6.x to Drupal 7.x). Changing your Solr schema to include more search criteria. Upgrading your Solr server to a new major version. Moving your Solr server from an old server to a new one.

read more

Categories: Elsewhere

Drupal.org Featured Case Studies: Wight & Company

Tue, 25/08/2015 - 22:41
Completed Drupal site or project URL: http://www.wightco.com/

Wight & Company (Wight) is an integrated architecture, engineering, and construction services firm with offices in Chicago and Darien, Illinois. Wight has expertise in key markets including corporate, commercial, federal government, higher education, local government, PK-12 education, and transportation and infrastructure. 

TOKY Branding + Design created a website that sets Wight apart from the all-too-common aesthetic and functionality of competing firms. TOKY specializes in digital and print work for clients in architecture, building, and design, as well as the arts, education, and premium consumer products.

Key modules/theme/distribution used: Advanced MenuAPC - Alternative PHP CacheEntity APIEntity cacheField collectionImageAPI Optimize (or Image Optimize)Memcache API and IntegrationMetatagRemote stream wrapperSpeedyTaxonomy access fixTaxonomy displayOrganizations involved: TOKY Branding + DesignTeam members: Daniel Korte
Categories: Elsewhere

Shitiz Gag's Blog: [GSoC 2015: Hawk Authentication] Week 14: Concluding Summer of Code

Tue, 25/08/2015 - 19:07

This would be my last weekly update as far as Google Summer of Code 2015 is concerned. The long road is coming to an end as the season closes on Friday, 28th August 2015. This week I tackled a bug in core of Drupal which I discussed in my last week’s update.

Fixing WWW-Authenticate

This issue is #2553531 on the Drupal bug tracker. Previously when a user was accessing an area which required them to be logged in without logging in, Drupal would call authentication providers for a “challenge”. This challenge allows Basic Auth to specify it’s WWW-Authenticate header and send a HTTP 401 unauthorised error telling the user that they need to be logged in and can use Basic Auth as a means to log-in. This was good, as basic was the only protocol which would communicate via WWW-Authenticate until Hawk came along.

WWW-Authenticate can have multiple values, a server sending WWW-Authenticate: Hawk, Basic for example is saying that the client can use hawk or basic auth protocol. This wasn’t possible in the current code base as Drupal did not allow multiple Auth providers to specify the challenge. I modified the code to allow multiple auth providers to send their challenge which gets compiled by the authentication provider manager into an exception. Previously, the auth provider would send an exception itself which is why multiple auth providers could not specify their own challenge.

This fix is still to be accepted into Drupal core, although I hope it would get accepted soon.

Concluding Summer of Code

This would probably be the last coding I will be doing during Summer of Code, but it’s not last related to Drupal or my project as I plan to continue it’s development after GSoC as well and hopefully I get to stick around Drupal for a long time.

I had a lot of fun during the summer, and I got to learn a lot of new things as well as got introduced to Drupal and it’s community. I worked on implementing a new protocol within PHP, developing a general purpose library which can be used by anyone willing to use the protocol with PHP and implemented the protocol as a Drupal module. All things that I have never done in the past, and the things I struggled with at times but ultimately learned them and managed to succeed to the best of my abilities. I also improved my understanding of concepts such as Dependency Injection, unit testing, composer, authentication and authorization as well as security concepts related to them, encryption, hashing and general Drupal architecture and development.

For students participating in the future, don't hesitate to ask around the Drupal community via the forums or IRC if you get stuck doing something as they are very helpful. Drupal is a complicated beast and there are a lot of people apart form your mentor who are willing to help, it would also be faster at times when your mentor might not be available. I took a lot of help from the community during my project and the community really helped around.

I’m glad to have taken part in this year’s summer of code and I will remember this experience forever. A big thanks to my mentor Jingsheng Wang (skyred) and the Drupal community for their support as well as Avantika Agarwal for proofreading my blog and documents related to Summer of Code. I will continue with what I started this summer of code and try to learn and share as many things as I can.

Thank you!

Categories: Elsewhere

Tim Millwood: Versioning in Drupal

Tue, 25/08/2015 - 17:59
Currently Drupal has naming conventions for branches and tags in git for contrib module. These are...
Categories: Elsewhere

Dries Buytaert: Digital Distributors vs Open Web: who will win?

Tue, 25/08/2015 - 14:25

I've spent a fair amount of time thinking about how to win back the Open Web, but in the case of digital distributors (e.g. closed aggregators like Facebook, Google, Apple, Amazon, Flipboard) superior, push-based user experiences have won the hearts and minds of end users, and enabled them to attract and retain audience in ways that individual publishers on the Open Web currently can't.

In today's world, there is a clear role for both digital distributors and Open Web publishers. Each needs the other to thrive. The Open Web provides distributors content to aggregate, curate and deliver to its users, and distributors provide the Open Web reach in return. The user benefits from this symbiosis, because it's easier to discover relevant content.

As I see it, there are two important observations. First, digital distributors have out-innovated the Open Web in terms of conveniently delivering relevant content; the usability gap between these closed distributors and the Open Web is wide, and won't be overcome without a new disruptive technology. Second, the digital distributors haven't provided the pure profit motives for individual publishers to divest their websites and fully embrace distributors.

However, it begs some interesting questions for the future of the web. What does the rise of digital distributors mean for the Open Web? If distributors become successful in enabling publishers to monetize their content, is there a point at which distributors create enough value for publishers to stop having their own websites? If distributors are capturing market share because of a superior user experience, is there a future technology that could disrupt them? And the ultimate question: who will win, digital distributors or the Open Web?

I see three distinct scenarios that could play out over the next few years, which I'll explore in this post.

This image summarizes different scenarios for the future of the web. Each scenario has a label in the top-left corner which I'll refer to in this blog post. A larger version of this image can be found at http://buytaert.net/sites/buytaert.net/files/images/blog/digital-distrib....

Scenario 1: Digital distributors provide commercial value to publishers (A1 → A3/B3)

Digital distributors provide publishers reach, but without tangible commercial benefits, they risk being perceived as diluting or even destroying value for publishers rather than adding it. Right now, digital distributors are in early, experimental phases of enabling publishers to monetize their content. Facebook's Instant Articles currently lets publishers retain 100 percent of revenue from the ad inventory they sell. Flipboard, in efforts to stave off rivals like Apple News, has experimented with everything from publisher paywalls to native advertising as revenue models. Except much more experimentation with different monetization models and dealmaking between the publishers and digital distributors.

If digital distributors like Facebook succeed in delivering substantial commercial value to the publisher they may fully embrace the distributor model and even divest their own websites' front-end, especially if the publishers could make the vast majority of their revenue from Facebook rather than from their own websites. I'd be interested to see someone model out a business case for that tipping point. I can imagine a future upstart media company either divesting its website completely or starting from scratch to serve content directly to distributors (and being profitable in the process). This would be unfortunate news for the Open Web and would mean that content management systems need to focus primarily on multi-channel publishing, and less on their own presentation layer.

As we have seen from other industries, decoupling production from consumption in the supply-chain can redefine industries. We also know that introduces major risks as it puts a lot of power and control in the hands of a few.

Scenario 2: The Open Web's disruptive innovation happens (A1 → C1/C2)

For the Open Web to win, the next disruptive innovation must focus on narrowing the usability gap with distributors. I've written about a concept called a Personal Information Broker (PIM) in a past post, which could serve as a way to responsibly use customer data to engineer similar personal, contextually relevant experiences on the Open Web. Think of this as unbundling Facebook where you separate the personal information management system from their content aggregation and curation platform, and make that available for everyone on the web to use. First, it would help us to close the user experience gap because you could broker your personal information with every website you visit, and every website could instantly provide you a contextual experience regardless of prior knowledge about you. Second, it would enable the creation of more distributors. I like the idea of a PIM making the era of handful of closed distributors as short as possible. In fact, it's hard to imagine the future of the web without some sort of PIM. In a future post, I'll explore in more detail why the web needs a PIM, and what it may look like.

Scenario 3: Coexistence (A1 → A2/B1/B2)

Finally, in a third combined scenario, neither publishers nor distributors dominate, and both continue to coexist. The Open Web serves as both a content hub for distributors, and successfully uses contextualization to improve the user experience on individual websites.

Conclusion

Right now, since distributors are out-innovating on relevance and discovery, publishers are somewhat at their mercy for traffic. However, a significant enough profit motive to divest websites completely remains to be seen. I can imagine that we'll continue in a coexistence phase for some time, since it's unreasonable to expect either the Open Web or digital distributors to fail. If we work on the next disruptive technology for the Open Web, it's possible that we can shift the pendulum in favor of “open” and narrow the usability gap that exists today. If I were to guess, I'd say that we'll see a move from A1 to B2 in the next 5 years, followed by a move from B2 to C2 over the next 5 to 10 years. Time will tell!

Categories: Elsewhere

Annertech: Case Study - Performance Testing a Drupal Website

Tue, 25/08/2015 - 12:02
Case Study - Performance Testing a Drupal Website

At Annertech, there are three things we take very seriously: website/server security, accessibility, and website load times/performance. This article will look at website performance with metrics from recent work we completed for Oxfam Ireland.

We use a suite of tools for performance testing. Some of these include Apache Benchmark, Yahoo's YSlow, and Google's PageSpeed Insights. Our favourite at the moment is NewRelic, though this does come at a cost.

Categories: Elsewhere

KnackForge: Drupal Moodle user integration

Tue, 25/08/2015 - 07:20

Moodle is a free and open-source software learning management system written in PHP and distributed under the GNU General Public License. Moodle is used for blended learning, distance education, flipped classroom and other e-learning projects in schools, universities, workplaces and other sectors.

Our main objective is that we wanted to manage all the users from Drupal i.e., use drupal as the front end for managing users. For this purpose, we have a moodle plugin and drupal module. Drupal services is a moodle authorization plugin that allows for SSO between Drupal and Moodle. Moodle SSO provides the Drupal functionality required to allow the Moodle training management system to SSO share Drupal sessions. 

In order to make SSO work, we need to ensure that sites can share cookies. Drupal and moodle sites should have url like drupal.example.com and moodle.example.com. As mentioned earlier, sites should be able to share cookies. To make sites use shared cookie, we need set the value of $cookie_domain in settings.php file on the drupal site. In our case, the site urls was something like drupal.example.com and moodle.example.com. For these type of sub-domains, the cookie_domain value can be set like the below one:

$cookie_domain = ".example.com";

Note: The dot before "example.com" is necessary.

Let's start with the steps that need to followed for achieving SSO between drupal and moodle:

1. Moodle site

Categories: Elsewhere

KnackForge: Configure & Import SOLR data

Tue, 25/08/2015 - 06:44
If you are planning to import data from database (MySQL, PostgreSQL) download the required database connector,   For PostgreSQL, you can download here   First step, configure the data source file in SOLR. To do this add the new file in SOLR home directory solr/<core>/conf/data-import.xml <?xml version="1.0" encoding="UTF-8"?> <dataConfig> <dataSource
Categories: Elsewhere

KnackForge: Slideshow in Drupal

Tue, 25/08/2015 - 06:20

This post explains about creating slideshow in drupal. There are many ways and plugins available to create slideshow in drupal and I am going to discuss some methods which will be very efficient and useful.

1) Using Views slideshow module

2) Using jQuery cSlider plugin

3) Using Bootstrap carousel

1. Using Views slideshow module:

The modules required for this method are:

  1) Views

  2) Views slideshow

  3) jQuery cycle plugin ( Download here and place it at sites/all/libraries/jquery.cycle/)

Enable the added modules. To create views slideshow, create a new content type for instance "Slideshow" with an image field which can be used as slideshow image.

Add multiple slideshow nodes with images. Then, we have to create a view block with slideshow content. Select "slideshow" as required format and configure transition effect in the Settings link.

 

After saving this view, place this view block at neccessary region at admin/structure/blocks.

2. Using jQuery cSlider plugin:

1) You can download this plugin from here. There is also a demo file in this plugin which can be used as a reference.

Categories: Elsewhere

Drupal Association News: 2014 Drupal Association Annual Report and Financials

Tue, 25/08/2015 - 01:54

One of our key values at the Drupal Association is communication:

We value communication. We seek community participation. We are open and transparent.

One of the ways that we try to live this value is by making our numbers -- both operating targets and financial -- available to the public. The monthly board reports share basic financial numbers and all our operational metrics. Once a quarter, we release full financial reports for the previous quarter. You can access all this information at any time on the Association web site.

At the close of each year, we take the opportunity to have our financials reviewed (and sometimes audited). The review process ensures that we've represented our financials properly. This work takes some time. Though our fiscal year closes on 31 December, it takes six to eight weeks to get the final bits and pieces handled in our financial systems. The independent review or audit adds another 8+ weeks to the process of closing out our year. Then we have to review the findings with the Finance Committee and the full Board before we share them publicly. That's why it's August and we're just now sharing the 2014 reviewed financial statements with you.

In 2014 we also began tracking our progress towards several operational goals for the first time. Though we share those numbers every month in the board report, we pulled some of our favorite stats and stories together into an Annual Report to share the work that our financials represent.

What happened in 2014?

2014 was an investment year. Per our Leadership Plan and Budget for the year, our key focus was building an engineering team to first address technical debt on Drupal.org and then take on actual improvements to the site. We purposely built a budget that anticipated a deficit spend in order to fully fund the team. The intent was to also build some new revenue programs (like Drupal Jobs) that would ramp up and eventually allow us to fund the new staff without deficit spending. And that's what we did. We went from two full time staff focused on Drupal.org to ten.

The investment has been paying off. We spent a lot of 2014 playing catch up with technical debt, but also managed to improve site performance markedly while also increasing the portability of our infrastructure. On top of that, staff worked with community volunteers to release new features related to commit messages, profiles, and Drupal 8 release blockers. Most importantly, staff and the working groups prioritized upcoming work and published a strategic roadmap for improvements to Drupal.org.

We held two huge DrupalCons, one in Austin and one in Amsterdam, and planned for a third. Our very small team of events staff and a crew of remarkable volunteers hosted over 5,500 people across our two events, all while planning our first Con in Latin America. We had some stumbling blocks and learning opportunities, and have been applying what we learned to the three 2015 DrupalCons.

We launched Drupal Jobs. This was something the community asked for very clearly when we conducted a 2013 study. We’ve seen steady growth in usage since our quiet launch and will continue to refine the site, including our pricing models, so that it is accessible to Drupalers around the world.

We diversified our revenue streams. DrupalCons used to be 100% of our funding. Not only is this a risky business strategy, it puts undue pressure on the Cons to perform financially, leaving us little room to experiment or make decisions that may be right for attendees, but could negatively impact the bottom line. As we increase the funding sources for the Association, we can make more and different choices for these flagship programs and also grow new programs with the community.

We introduced branded content including white papers, infographics, and videos. These materials have been widely used by the community and have helped us understand the Drupal.org audience in a better way. You can see a lot of this work on the Drupal 8 landing pages, where the key content pieces were downloaded thousands of times in 2014.

We released new vision, mission, and values statements for the Association. These tools are really useful in defining the focus of the organization and helping to guide how we get our work done. Working in a community of this size and diversity is extremely challenging. There is no choice we can make that will include everyone’s ideals, but our values help us make those decisions in a way that allows for transparency and open dialogue with the community. It’s something that we try to honor every day.

What about money in 2014?

As anticipated, we ran a deficit in 2014. However, we did manage to grow our overall revenue by about 6% from 2013 to 2014. This trend has continued into 2015, though not at the rate we had hoped. Still, we are now on track to support the investment we made in 2014 into the future. Another key win in 2014 is that we grew non-DrupalCon revenue to 21% of our total revenue. Diversifying our revenue streams reduces our financial risk and takes the pressure off of Cons, allowing us to experiment more.

I want all the details

Excellent! You can check out:

Categories: Elsewhere

Larry Garfield: Just how insular is the PHP community?

Mon, 24/08/2015 - 22:21

Periodically, there is a complaint that PHP conferences are just "the same old faces". That the PHP community is insular and is just a good ol' boys club, elitist, and so forth.

It's not the first community I've been part of that has had such accusations made against it, so rather than engage in such debates I figured, let's do what any good scientist would do: Look at the data!

read more

Categories: Elsewhere

OSTraining: Drupal 8: What do Site-Builders Need to Know?

Mon, 24/08/2015 - 21:41

Over the last few weeks, we've been working really hard on preparing training for Drupal 8.

We'll release the training close to the actual launch date of Drupal 8, but before then we have a great video to get you started.

This is a webinar we did with Acquia called, "10 Things Site Builders Need to Know Before Leaping to Drupal 8".

I talked about the many user-friendly features in Drupal 8, including the mobile-friendly admin interface and the in-place WYSIWYG editor, plus improvements in theming and module development:

Categories: Elsewhere

Drupal Watchdog: Auditing, Ethics, and Drupal Sites

Mon, 24/08/2015 - 19:07
Article

As web sites and applications have become more complex, the need for auditing – at multiple points in the lifecycle of a project – has become ever more important.

Before delivery, a web project can be audited to ensure the ability to meet business goals or compliance with regulations. After delivery, an audit can identify problems and propose remedies. In a possible merger or acquisition, an audit can help evaluate the project’s relative benefits and liabilities.

Website auditing has become similar to financial auditing (which is separate and distinct from accounting and financial activities). It is similar to the practices applied in auditing management systems (see “There’s a Module Standard for That” sidebar).

Website auditors must apply these four principles:

  • Judgment They must be able to choose the scope and granularity of the website, without wasting effort on discovering problems with no meaningful impact on the behavior and performance of the site; hence, a need for business acumen.
  • Expertise In order to determine whether or not best practices were followed by the original site developers, auditors must achieve a level of proficiency beyond that with which the site was delivered.
  • Objectivity Auditors cannot audit a site they themselves produced, or else risk selective blindness – the inability to see problems they missed the first time around.
  • Distance Auditors cannot operate on a website developed by a company – especially their own – with which they have any kind of commercial or personal involvement.
The Real World

Market studies show that site audits are often used as a loss leader by generalist Drupal agencies. Their objective: to set the stage for redevelopment and third-party maintenance work, where the main volume of business is done using “findings” from a short and low-cost audit to provide the developer with a technical advantage against competitors.

Categories: Elsewhere

Four Kitchens: REST Easy Part 4: The Tax(onomy) man!

Mon, 24/08/2015 - 18:09

It’s easy to add node endpoints to your RESTful API - but there’s more to Drupal than nodes. This week we’ll add an endpoint for a taxonomy vocabulary.

Categories: Elsewhere

Acquia Developer Center Blog: Training Your Team on Drupal 8: Balancing Classrooms and Individuals

Mon, 24/08/2015 - 18:03

Not every student learns the same way, so teachers consistently have to find a way to instruct a classroom while also reaching students individually.

We were reminded of a teacher’s greatest challenge when we trained dozens of Acquia employees on Drupal 8. As my co-author Kent Gale and I detailed earlier in this series on Drupal 8 instruction, we separated employees into groups of two, with one person having some knowledge of the new platform and the other having no knowledge. Once their instruction ended, they split up and each teamed with two other employees – our version of chromosomal mitosis.

Our approach to training was structured. We had goals to achieve. But we also had to stay flexible throughout. Because experience, knowledge, and skill set differed with each employee, we had to connect with them individually while maintaining the larger class structure.

We had people with deep programming experience. We had middleware folks. We had site builders. We had front-enders. Because of that, the training program had to present a lot of material, but not so much that individuals wouldn’t learn. We trained with the expectation that not everyone would, or even needed to, become experts.

Consider the training of our “explainers,” the employees who explain our products to the public. We had to figure out what they could easily learn in only one- to four-hours of training. They needed to know enough to promote and answer questions about Drupal 8, but didn’t need to know as much as a support person, who received anywhere from 40 to 80 hours of training. Figuring out what the explainers needed to learn took some effort, but there was ample material to help us determine which path to follow.

Speaking of paths, your team doesn’t have to follow ours. Mitosis worked great for us, but it may pose a problem for your program if you have fewer employees, less time to train, or other considerations.

You need to find out what works best and that, as we’ve mentioned, takes time and effort, success and failure. Some employees like to be lone wolves and learn everything on their own, for example, so our process may not work for them.

Tools that track progress will help you ascertain what works and what doesn’t. Every company, no matter how large or small, faces time constraints, so these tools will guide you through the unknowns.

We used training as a key performance indicator (KPI) for employees. Shared ownership in this big Drupal 8 training project made sense if we all had to make a big leap together in understanding the new platform. Sometimes employees will sweep training under the rug because they believe putting out other fires is a priority.

We knew learning Drupal 8 would be a significant commitment; it’s a significant change, after all. But we couldn’t delay training. Drupal 8 was coming out and there was no time for delay. KPIs helped motivate and get everyone on the same page. There was a vested interest in making progress.

Blog series: Organizing to Rock with Drupal 8Workflow: PendingFeatured: NoTags: acquia drupal planetDrupal 8 related: YesAuthor: Thomas Howell
Categories: Elsewhere

Sooper Drupal Themes: 8 Common Customer Service Complaints All Drupal Developers Will Deal With

Mon, 24/08/2015 - 10:51

Every Drupal developer heard stories of 'clients from hell' and collaborations that turned into nightmares. And, it’s true… you’re going to come across some extremely difficult clients. No matter you do, no matter how hard you work…you’re going to have problems with them. 

Remind yourself: “I am not alone!”

All businesses – no matter what kind of company it is...

Categories: Elsewhere

Pages