Drupal Feeds

With the growing popularity and prevalence of Drupal 8, it should come as no surprise that many Drupal development companies are slowly edging away from suppo

As Drupal 8 "relies" on a Configuration Management (CM) system, one of its cool improvements is restoring a Drupal 8 site from an existing configuration instead of only a database dump. This means that you can do a brand new Drupal installation and replicate an existing configuration on your new fresh database!

read more
If you’ve spent much time upgrading older websites to PHP 7, it’s likely you have encountered the annoying situation where PHP notices are printed directly into the HTML output, causing them to display in an ugly, unformatted jumble at the top of the page. The effect looks something like this:
Palantir.net's Guide to Digital Governance: Web-Based Applications Palantir.net's Guide to Digital Governance brandt Mon, 12/12/2016 - 13:22 Scott DiPerna Dec 12, 2016

This is the twelfth installment of Palantir.net’s Guide to Digital Governance, a comprehensive guide intended to help get you started when developing a governance plan for your institution’s digital communications.

In this post we will cover...
  • Common internal applications you may deal with
  • Common third party applications you may maintain an account for
  • Questions to consider about all types of web-based applications

We want to make your project a success.

Let's Chat.

Web-based applications typically add some functionality to your website that it otherwise would not be able to support on its own. These applications tend to come in two varieties:

  • those that have been developed internally by your own organization, and
  • those that are a service provided to you by a third party (typically a paid service)

Generally speaking, it is likely that internally developed applications are hosted and supported by your organization. When you have an issue, you probably talk to your IT team about it.

Some common internal applications:

  • User authentication
  • Organizational profiles or staff database system
  • Image database system or repository
  • Document database system or repository
  • Enrollment or student application forms
  • Programs and courses database systems
  • Products database system

Third party applications are probably accessed via the internet by your website and your users. You (or someone at your organization) probably maintains an account for that service, which you probably pay for monthly or annually. When you have an issue, it is likely someone contacts the third party’s support team for help.

Some common third party applications are:

  • E-commerce or an online shopping tool
  • Donations tool
  • Events with RSVP and ticketing
  • Appointments, room scheduling
  • Live chat

Technically speaking, tools like YouTube, Vimeo, Flickr, etc. are third party application services as well, but they are so easily integrated into your site, often with little or no costs or maintenance, that they require little attention. Still, they may be worth examining when considering governance.

Given the landscape above, your organization likely has several web-based applications – whether those are custom-built applications or third party solutions – which are used to perform specific functions and tasks. Here are some important questions to consider about all of these applications when defining an ownership and governance plan:

  • Who owns each application?
  • Who is responsible for its technical maintenance and support?
  • How are new custom applications developed?
  • Is there a process to follow for making functional changes to internally developed applications?
  • How is content in the application edited or changed?
  • Who is able to change content?
  • Who is responsible for maintaining content in the application?
  • Is there a process to follow for making content changes?
  • How are new third party applications, solutions, or services acquired?
  • Who controls the account, if it is a third party application?
  • How are third party services expanded or scaled across the organization if needs grow?

There are certainly many more considerations to make based on the specific application or service, and the functionality it offers. I recommend evaluating each application that is a functional part of your website to determine the appropriate governance policies for each.

 

This post is part of a larger series of posts, which make up a Guide to Digital Governance Planning. The sections follow a specific order intended to help you start at a high-level of thinking and then focus on greater and greater levels of detail. The sections of the guide are as follows:

  1. Starting at the 10,000ft View – Define the digital ecosystem your governance planning will encompass.
  2. Properties and Platforms – Define all the sites, applications and tools that live in your digital ecosystem.
  3. Ownership – Consider who ultimately owns and is responsible for each site, application and tool.
  4. Intended Use – Establish the fundamental purpose for the use of each site, application and tool.
  5. Roles and Permissions – Define who should be able to do what in each system.
  6. Content – Understand how ownership and permissions should apply to content.
  7. Organization – Establish how the content in your digital properties should be organized and structured.
  8. URL Naming Conventions – Define how URL patterns should be structured in your websites.
  9. Design – Determine who owns and is responsible for the many aspects design plays in digital communications and properties.
  10. Personal Websites – Consider the relationship your organization should have with personal websites of members of your organization.
  11. Private Websites, Intranets and Portals – Determine the policies that should govern site which are not available to the public.
  12. Web-Based Applications – Consider use and ownership of web-based tools and applications.
  13. E-Commerce – Determine the role of e-commerce in your website.
  14. Broadcast Email – Establish guidelines for the use of broadcast email to constituents and customers.
  15. Social Media – Set standards for the establishment and use of social media tools within the organization.
  16. Digital Communications Governance – Keep the guidelines you create updated and relevant.

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

One of the key selling points of Platform.sh is predictable, repeatable deployments. We view the read-only production file system as a key advantage for our customers. But why is that, and how do we manage it? Just how repeatable and predictable is it?

The key to reliability is predictability. If I know my code works in testing, I should be able to predict, with a very high degree of confidence, that it will work in production, too. To do that, we need to minimize the number of variables that differ between staging and production. Zero is ideal, but anything close to zero is generally good enough.

At Platform.sh, the build process for all environments, production or not, is exactly the same. And the inputs to that build process are all consistent and largely predictable.

One of the key selling points of Platform.sh is predictable, repeatable deployments. We view the read-only production file system as a key advantage for our customers. But why is that, and how do we manage it? Just how repeatable and predictable is it?

The key to reliability is predictability. If I know my code works in testing, I should be able to predict, with a very high degree of confidence, that it will work in production, too. To do that, we need to minimize the number of variables that differ between staging and production. Zero is ideal, but anything close to zero is generally good enough.

At Platform.sh, the build process for all environments, production or not, is exactly the same. And the inputs to that build process are all consistent and largely predictable.

How can one extend the Drupal 6-to-8 core upgrade functionality? Recently, I've been working with Drupal upgrades using the UI and found the process to be fairly smooth, but missing some key functionality, like media; at the same time, I've been writing a series of blogposts on the Drupal 8 APIs: it turns out that, to extend the process of upgrades to Drupal 8, we can bring these two threads together.

Read more of "Extending Drupal 6-to-8 upgrade to create media entities"

Speed is important in a Drupal website, very important. For visitors as well as search engines, it’s an essential benchmark to success. But how do you keep your Drupal system fast, even when it has millions of pages and documents? Solr is the answer, here is why and how in Drupal 8.

In a recent project built in Drupal 7, I came across a bit of an uncommon scenario, by which some users needed to have access to certain features that were normally restricted to them, when viewing, editing or creating groups content (ie: whenever they are visiting a part of the site that is considered part of a group).

For example, while normal users didn’t have access to use certain text formats in the wysiwyg editor, those that were considered group leaders needed to make use of that particular text format. In this scenario, a group leader was an existing role within Organic Groups.

While a simple solution could be a dedicated, global user role that is assigned to users when they become group leaders, and assign any extra permissions to that role, it wasn’t the right solution for this scenario, because a user could be a group leader for some groups, but just a normal group member for other groups, whereas the permissions needed to be applied specifically for the groups in which the user is a group leader. In other words, permissions had to be resolved dynamically depending on what group a user is working on at any given moment.

So, what other options are there available to accomplish this? One would be to use drupal alters and hook mechanisms to change the way each feature restricts access to users, but that will become messy very quickly, particularly if you have to do it for several features, in which case each one might need to be tackled in a different way. Besides, what looks simple on the surface, might involve some more hacking and tweaking than expected: for example, for wysiwyg-related alters, hacks need to be made not only when rendering the wysiwyg editor, but also when validating the input data.

I was looking for a more generic solution that could be easily applied and extended to any feature on the system, and I found it while reviewing the user_access function from Drupal core. Code below:

function user_access($string, $account = NULL) { global $user; if (!isset($account)) { $account = $user; } // User #1 has all privileges: if ($account->uid == 1) { return TRUE; } // To reduce the number of SQL queries, we cache the user's permissions // in a static variable. // Use the advanced drupal_static() pattern, since this is called very often. static $drupal_static_fast; if (!isset($drupal_static_fast)) { $drupal_static_fast['perm'] = &drupal_static(__FUNCTION__); } $perm = &$drupal_static_fast['perm']; if (!isset($perm[$account->uid])) { $role_permissions = user_role_permissions($account->roles); $perms = array(); foreach ($role_permissions as $one_role) { $perms += $one_role; } $perm[$account->uid] = $perms; } return isset($perm[$account->uid][$string]); }

As you can see, the permissions are fetched for a given user (if they haven’t been already gathered in the current page request), and then statically cached, so that on subsequent calls they don’t need to be fetched from the database again. The key line of the code above that allows custom code to override system permissions, is this:

$drupal_static_fast['perm'] = &drupal_static(__FUNCTION__);

The drupal_static() function is a mechanism provided by Drupal core to serve as a central static variable storage. Due to the way it works, it is possible for a custom module to call the function with a parameter to get the values stored in it by some other function. More importantly, because it always returns a variable by reference, it means the returned values can be replaced or modified as we please. In this particular case, user_access() maintains the permissions for a given user, as a reference to the values stored by drupal_static().

Knowing this, all I had to do was calling drupal_static() as if it was being called from user_access() itself, and modify the variable returned by reference, to inject permissions dynamically. The best place to do this was in a hook_init() implementation, to make sure all the permissions are in place from as early as possible in the page request. This can be done in just a few lines of code:

/** * Implements hook_init(). */ function mymodule_init() { // Check if request is a group context and inject group-specific logic. if ($og_context = og_context('node')) { global $user; $group_id = $og_context['gid']; /* * This would include some code to check if the user is a group leader... */ // Issue a call to drupal_static(), on behalf of 'user_access' function. $drupal_static_fast['perm'] = &drupal_static('user_access'); $perm = &$drupal_static_fast['perm']; // Add / remove permissions as needed. $perm[$user->uid]['use text format editor'] = TRUE; $perm[$user->uid]['show format selection for node'] = TRUE; // Allow access to draggable views. $perm[$user->uid]['access draggableviews'] = TRUE; $perm[$user->uid]['other perm 1'] = TRUE; $perm[$user->uid]['other perm 2...'] = TRUE; } }

I removed the logic to check if a user is leader of the current group, for simplicity, but other than that this is a fully functional snippet that could be used in nearly every Drupal 7 project that uses Organic Groups. Essentially, it checks if page request is in a group context, then check if user is a group leader (or any other role your groups setup could have), and then add the permissions needed for him during that page request.

 Bonus points
  •  With this in place, it’d be very simple to build an UI to configure the extra permissions that need to be added to specific group roles, even on a per-group level. That way, full control over who can do what, can be achieved from the UI as configuration, keeping the code tweaks at a minimum.
  • I removed some extra logic here for simplicity, but our scenario was on a very busy site. We used a session variable to keep track of the groups for which the user is a group leader, to save yet another database query on each page request.
Related links

Although I didn’t find any existing solution to this scenario, I came across a module that does just the opposite: OG Role Override. It allows to specify certain global roles, that will be treated as specific group roles automatically, even if they don’t belong to a given group. Very handy, as I also had that particular scenario in this same project!

InternetDevels developers working at JYSK shop chain project, keep creating new Drupal modules for the community. In the previous blog post, you could check out the Gridstack field module. This time, we present the Field image tooltips module, which is also ready for Drupal 7 and Drupal 8. As it is our tradition, the author himself is going to introduce the module.

Read more

Drupal gets better when companies, organizations, and individuals build or fix something they need and then share it with the rest of us. Our community becomes better, stronger, and smarter when others take it upon themselves to make a positive difference contributing their knowledge, time, and energy to Drupal. Acquia is proud to play a part, alongside thousands of others, in some of the stories making tomorrow’s Drupal better than today’s. One of them is Nida Ismail Shah’s.

Tags: acquia drupal planeteventshooksSymfonydispatchercoremodule

Web Chef Randy Oest got some perspective from the other side at WordCamp US […]

One of the really interesting things about providing support and maintenance for lots and lots of sites is that you get to see patterns or certain issues affecting several sites, that you might not notice if you're only responsible for a handful of sites.

Not only does this add to our knowledge base of solutions when a customer has a problem, but it can sometimes allow us to preemptively find a problem before a customer even knows they have it (or point it out when we do a FREE site audit).

Anyway, here's a request we've recently gotten from a couple of customers:

Is our web site compromised?!

Our hosting provider says that we've been sending hundreds of e-mails a day that are setting off alarms with their SPAM filter.

Please help!!!!

It turns out that none of the affected websites were hacked -- it was just a matter of spammers taking advantage of a particular Drupal module: "Print Mail" a sub-module of Print.

It's not a security vulnerability - they're using normal features of the module, just at scale with automation.

If you use this module on any of your sites, or are considering enabling it, please read on for an explanation of the problem and some possible solutions.

Decoupled Drupal has long been an approach touted by some in the front-end contingent of the Drupal community to achieve goals such as a better user experience, a more modern front-end developer experience, and clearer separation of concerns.

Tags: acquia drupal planet

We updated OpenLucius, an open source work management system -contributed as a Drupal distribution. These are the 5 most important improvements:

1.Modern layout for folders and files

The app ‘files’ takes care of central management of files and folders. Prevents messy document management on 'G-drives' and in email boxes. You can see the old layout in this video (we will update it soon):

The new layout:

Top 3 improvements:

  • Added thumbnails of images
  • Mobile ready, so you can tap on file/folder with your finger.
  • See where a file originated from (a message, task, event or ‘isolated file upload’), who placed it and when.
2. New group overview

Last spring DrupalCon North America in New Orleans was attended by 3,102 Drupal community members, in the fall 1,787 of you came to Dublin for DrupalCon Europe. That's a whole lot of human beings getting together to talk about the Drupal software, development processes, tools, business strategies, future directions and more. All of which are important. But, I want to talk about all of those human beings. What makes you tick?

Ruth December 14, 2016 Starting Out With Sketch and Drupal

One of my big projects this past summer as an intern at Redfin was to learn about the design software Sketch. This was supposed to culminate in a small presentation just to the office, but I ended up giving a presentation at a “birds of a feather” session at Design4Drupal in Boston. A couple people who missed it asked if I could record it, so I made a video of it once I got back to Portland.

Why Does HTTPS Matter?

HTTPS has been around for a while, but it’s generally not well-understood. Many people know that sites using HTTPS instead of HTTP will display a lock on the URL to tell users that the site is safe to use. Everyone knows that big ecommerce websites have to use HTTPS. Many people are aware that HTTPS is a good idea for login pages and other form pages on any site. But does it matter for every day web pages and sites? Increasingly, the answer is YES, even for small sites and non-form pages.

HTTPS protects end users from eavesdroppers and other threats. Because of all the security ramifications of plain HTTP, Google is putting its considerable weight behind efforts to encourage websites to become more secure with an “HTTPS Everywhere” initiative:

HTTPS is also a requirement for some new interactive functionality, like taking pictures, recording audio, enabling offline app experiences, or geolocation, all of which require explicit user permissions. So, there are many reasons for website owners and users to pay attention to it.

What Does Insecurity Look Like?

As an experiment, to see exactly what level of security HTTPS gives the user, I visited two sites, one HTTP, and one HTTPS. Our Senior Systems Administrator, Ben Chavet, acted like an eavesdropper. He wasn’t even sitting next to me. He was 800 miles away watching my traffic over the VPN I was using. It took him just a few minutes to pick up what I was doing. What he did could have been done by someone in a coffee shop on a shared network, or by a “Man-in-the-Middle” somewhere between me and the sites I was accessing.

When I logged into the plain HTTP site, my “eavesdropper” could see everything I did, in plain text, including the full path I was visiting, along with my login name and password. He could even get my session cookie, which would allow him to impersonate me. Here’s a screen shot of some of the information he was able to view.

undefined

But when I logged into a site protected by HTTPS, the only thing that was legible to my “eavesdropper” was the domain name of the site, and a couple of other bits of information from the security certificate as it was being processed. Everything else was encrypted. 

undefined

There are other problems with plain HTTP. An eavesdropper could steal session cookies to emulate a legitimate user to gain access to information they shouldn’t be able to see. If an attacker has access to a plain HTTP page, they could change links on the page, perhaps to redirect a user to another site. Or by encrypting form submissions (but not the form itself) an attacker can modify a form to post to a different URL. A valid HTTPS page is not vulnerable to these kinds of changes.

Clearly, HTTPS offers a huge security benefit!

What Does HTTPS Provide?

Let’s back up a bit. What exactly does HTTPS give us? It’s two things, really. First, it’s a way to ensure data integrity and make sure that traffic sent over the internet is encrypted. Secondly, it’s a system that provides authentication, meaning an assurance that the site a user is looking at is the site they think they are looking at.

In addition to obfuscating the user’s activity and data, HTTPS means the identity of the site is authenticated using a certificate which has been verified by a trusted third party.

If you get to a site using HTTPS instead of HTTP, you are accessing a site that purports to be secure. On an HTTPS connection, the browser you use (i.e. Internet Explorer, Safari, Chrome, or Firefox) and the site’s server will communicate with each other. The browser expects the server to provide a certificate of authenticity and a key the browser can use to encode and decode messages between the browser and the server. If the browser gets the information it requires from a secure site, it will display a safety lock in the address bar. If anything seems amiss, the browser will warn the user. Problems on an HTTPS page could be a missing, invalid, or expired certificate or key, or “mixed content” (HTTP content or resources that should never be included on an HTTPS page).

Identity, data integrity, and encryption are all important. A bogus site could still be encrypting its traffic, and a site that is totally legitimate might not be encrypting its traffic. A really secure site will both encrypt its traffic and also provide evidence that it is the site it purports to be.

How Do Users Know a Site is Secure?

Browsers provide messages for insecure sites. The specific messages vary from browser to browser, and depend on the situation, but might include text like “This page may not be secure.” or “The certificate is not trusted because it is self signed.” Most browsers display some color-coding that is expected to help convey the security status.  

If a site is rendered only over HTTP, browsers usually don’t indicate anything at all about the security of the site, they just provide a plain URL without a lock. This provides no information, but also no assurance of any kind. And as noted above, unencrypted internet traffic over HTTP is still a potential security risk.

The following chart illustrates a range of possibilities for browser security status indicators (note that EV is a special type of HTTPS certificate that provides extra assurance, like for bank and financial sites, more about that later):

undefined

For more information about the HTTPS security, users can click on the lock icon. The specific details they see will vary from browser to browser, but generally, there is a link with text like “More details” or “View certificate” that will allow the user to see who owns the certificate and other details about it.

undefined

Research about how well end users understand HTTPS security status and messages found that most users don’t understand and ultimately ignore security warnings. Users often miss the lock, or lack of a lock, and find the highly technical browser messages to be confusing. The focus on color to indicate security status is a problem for those that are color blind. Also, so many sites still use HTTP or are otherwise potentially insecure that it is easy for users to discount the risk and proceed regardless. The conclusion of all this research is that better systems need to be put in place to make it clear to users which sites are secure and which aren’t, and to encourage more sites to adhere to recommended security best practices.

A while ago, Chrome started to let users understand how secure a site is. These examples use a combination of color and shape to convey what’s secure and what isn’t. Currently, the plain HTTP site is more noticeably a security threat.

undefined

Starting in January of 2017, they plan to add text saying ‘Secure’ or ‘Not secure’ for even more emphasis:

undefined

Other browsers may follow suit to make plain HTTP look more noticeably insecure. Between the user safety, the SEO hit, and the security warnings that may scare people away from sites using plain HTTP, no legitimate site can really afford to ignore the implications of not serving content over HTTPS.

What Do All the Terms Mean? 

HTTPS terminology is confusing. There is a lot of jargon and countless acronyms. If you read anything about HTTPS, you can quickly get lost in a sea of unfamiliar terminology. Here is a list of definitions to help make things more clear.

Secure Socket Layer (SSL)

SSL is the original standard used for encrypted traffic sent over HTTP. It has actually been superseded by TLS, but the term is still used in a generic way to refer to either SSL or TLS.

Transport Layer Security (TLS)

TLS is the new variation of SSL, but it’s a newer, more stringent, protocol. TLS is not just for web browsers and HTTP, it can also be used with non-HTTP applications. For instance, it can be used to provide secure email delivery. TLS is the layer where encryption takes place.

HTTPS

HTTPS is just a protocol that indicates that HTTP includes the extra layer of security provided by TLS.

Certificate Authority (CA)

A CA is an organization that provides and verifies HTTPS certificates. “Self-signed” certificates don’t have any indication about who they belong to. Certificates should be signed by a known third party.

Certificate Chain of Trust

There can be one or more intermediate certificates, creating a chain. This chain should take you from the current certificate all the way back to a trusted CA.

Domain Validation (DV)

A DV certificate indicates that the applicant has control over the specified DNS domain. DV certificates do not assure that any particular legal entity is connected to the certificate, even if the domain name may imply that. The name of the organization will not appear next to the lock since the controlling organization is not validated. DV certificates are relatively inexpensive, or even free. It’s a low level of authentication, but provides assurance that the user is not on a spoofed copy of a legitimate site.

Extended Validation (EV)

Extended Validation certificates validate the legal entity that controls the domain as well as the fact that they have actual control over the domain. The name of the verified legal identity is displayed in the browser, in green, next to the lock. EV certificates are more expensive than DV certificates because of the extra work they require from the CA. EV certificates convey more trust, so are appropriate for financial and commerce sites.

Next Steps

It seems pretty clear that HTTPS is important. In my next article, HTTPS Everywhere: Making the Switch, I’ll talk about what it takes to migrate a site from HTTP to HTTPS.

More Reading How HTTPS works How HTTPS affects SEO ranking Browser clues about website security How a password can be stolen over an insecure connection Types of Certificates
Remember where we have finished in our world tour of Drupal Camps? Let us refresh your memories. After Africa, Asia, North America, Europe and South America it was time for Middle America to shine. Only two Drupal Camps were found there, so we hoped for more Drupal activity in Oceania. Our hopes were fulfilled. Like in the case of Africa, most Drupal Camps are taking place in one country. In fact, in this case, all of the Drupal camps took place in Australia in contrast to South Africa, which hosted a majority of the events. That was not the case in the past, because New Zealand also helped… READ MORE
Drupal level: advanced

Yesterday a patch for Inline Form Errors landed in Drupal, which as a by-product, brought us a new useful testing possibility: we can now more easily write tests that check if elements on a webpage are actually really visible in the viewport. The visibility of page elements in different scenarios is important for the usability and accessibility of your site.

Drupal 8 comes with exciting "new" testing possibilities, the latest addition was Functional JavaScript testing. Which enables us to automatically test if our JavaScript interactions work and keep working throughout the development process. The tests are run in the PhantomJS headless browser. Simulating interaction with this browser is handled by Behat's Mink. For a bit more background and how to set this up locally checkout this Chapter Three blog.

Visibility testing hardship \Behat\Mink\Element\NodeElement->isVisible()

Now let me first warn you that visibility testing can be quite tricky to grasp if you just start out. For example Mink has a method isVisible() and I was tempted to believe that this method checks that a user can see the targeted element on his screen. But nothing could be further from the truth... it only checks that the element is not styled explicitly invisible. So, for example, if you have some CSS styling like display: none;  or visibility: hidden; on an element this isVisible() assertion would fail. However if your element is not explicitly hidden, but is outside your devices viewport or is being obscured by an overlapping element, you are out of luck with this assertion. Your test would pass with flying colors, while the users sees nothing.

Another thing to note for if you'd want to dig in this matter more: as a Drupal user you probably by now interpret the word node as an object or entity with data that is primarily being use to publish content. In our testing context however it has to be understood as a DOM element which can be targeted by using a CSS selector or XPath. In this article I'll continue to use element.

New assertions \Drupal\FunctionalJavascriptTests\JSWebAssert->assertVisibleInViewport()

To work around the first problem of elements falling outside the viewport of a users device, we added a new assertions to Drupal's JSWebAssert class. It is now possible to check if an element is in (the defined) viewport or not using the assertVisibleInViewport() and assertNotVissibleInViewport() methods respectively.

You can target the to be tested element with CSS selectors or XPath and test if a certain corner or the whole element is visible in the viewport.

'How to use' examples

Let's assume the following for testing purposes prepared "Create page" interface of Drupal with an overlay helper of the viewport size.

To check if, in a certain situation, the header title is visible within the viewport you'll first have to define the viewport size. This can be done with a PhantomJS startup arguments and/or during runtime with the method \Behat\Mink\Session->resizeWindow(). In case of testing with the testbots on Drupal.org a default viewport as shown above will be setup for you. From your own Drupal project root you can start the headless browsers using the following command. The last two parameters indicate the default width and the height of the viewport used during your tests.

/path/to/phantomjs --ssl-protocol=any --ignore-ssl-errors=true vendor/jcalderonzumba/gastonjs/src/Client/main.js 8510 1024 768

Now you can use our new assertion to check if the header title is completely visible (partial code snippet):

$web_assert->assertVisibleInViewport('css', 'h1', FALSE, 'The page header title is not visible.');

In case of our first example the user (robot) scrolled down and the header title is not visible (the element is outside the green region). So the assertion would fail. How to setup a complete functional JavaScript test is outside the scope of the article, but you can use the recently commited CKEditor test code as an example.

For our second example we use a viewport of a mobile device. The user just loaded the page and hasn't scrolled down. For testing purposes we pushed the body field a bit down. And we see that the CKeditor of that field is partly visible (in the red area). By default the method tests the visibility of all four corners of a (rectangular) element (third parameter value: FALSE). With the third parameter we can tell the method to check a certain corner for visibility (topLeft, topRight, bottomRight or bottomLeft).

So the assertion given below will pass because the top left corner of the element is within the viewport (red area). But by default it would have failed, because not all corners are visible.

$web_assert->assertVisibleInViewport('css', '#cke_edit-body-0-value', 'topLeft', 'The top left of the CKEditor enabled body field is not visible.'); Final notes

To actually see the used viewport in a screenshot, a patch is available in an ongoing issue on Drupal.org. Chime in if you would like this possibility in core. It has been used to generate the illustrations in this blog. And remember, visibility testing doesn't take into account that the element could be obscured by another element. So for now, using printscreens, is the only out-of-the-box way of checking if an element is really really visible. Time for another assertion?

Questions or comments? @dmsmidt

Pages