Drupal Planet

Subscribe to canal de noticias Drupal Planet
Drupal.org - aggregated feeds in category Planet Drupal
Actualizado: hace 2 horas 50 mins

Agiledrop.com Blog: AGILEDROP: Drupal SEO Tips

Jue, 05/10/2018 - 21:40
Drupal is a CMS that’s well-known for its security and flexibility. But do you know of another aspect that Drupal excels at? It’s Drupal’s excellent built-in SEO functionality. While Drupal itself plays pretty well with search engines, there are a host of measures you can take to ensure you stay on top of the SEO game even more. After all, the internet is a competitive market, making a site’s SEO all the more competitive. In this post, I’ll explore some of the most common SEO measures you can take to bolster your Drupal site’s SEO efforts.   The Basics All the basic SEO measures that are… READ MORE

Acro Media: Drupal Commerce 2: How to Add and Edit Product Content

Jue, 05/10/2018 - 11:45

The hardest part of Drupal Commerce 2 is the configuration of it all. Luckily, most store managers and administrators don't need to worry about that part. What they DO need to worry about is how to actually add new products to their stores and manage existing ones. For some ecommerce stores, keeping your product offerings fresh and up-to-date can mean the difference between success and failure. If you're using Drupal Commerce 2, managing your store content is easy!

In this Acro Media Tech Talk video, we user our Urban Hipster Commerce 2 demo site to show you the Drupal Commerce 2 product interface and how to add and edit products. The products shown will be configured differently than your own, but the same principles will apply no matter what type of product you sell.

Its important to note that this video was recorded before the official 2.0 release of Drupal Commerce useing a beta release of the Commerce Shipping module. You may see some differences between this video and the current releases. The documentation is also evolving over time.

Urban Hipster Commerce 2 Demo site

This video was created using the Urban Hipster Commerce 2 demo site. We've built this site to show the adaptability of the Drupal 8, Commerce 2 platform. Most of what you see is out-of-the-box functionality combined with expert configuration and theming.

More from Acro Media Drupal modules in this demo

Specbee: Front-End Framework For Drupal Website - How To Make The Right Choice?

Jue, 05/10/2018 - 10:01

Today's world is a close reality to something I dreamt of as a child. A world run by devices, the technology they use and their potential to change the future. New interfaces and devices have brought in sweeping changes to transform the web as we know it. With Artificial Intelligence, IOT and more have started to establish and make an impact in the digital world. This impact has changed the way how we perceive a future with seamless, feature-rich websites.

Colorfield: GDPR documentation

Jue, 05/10/2018 - 04:31
GDPR documentation christophe Thu, 10/05/2018 - 09:31 A short list of Drupal and developer oriented GDPR links.

Appnovation Technologies: DrupalCon 2018: Should Drupal's installer be tailored towards the Enterprise?

Jue, 05/10/2018 - 04:00
DrupalCon 2018: Should Drupal's installer be tailored towards the Enterprise? In Dries' keynote at DrupalCon Nashville 2018 he discussed a blog post by Matthew Grasmick where the "first impression" or installer experience of Drupal was compared with Wordpress, Symfony, and Laravel. A tweet by Jeff Eaton then got me thinking: "Kind of weird that the #driesnote compares the in...

myDropWizard.com: Drupal 8 + CiviCRM Roundearth Lands In Calgary for CiviCamp

Mié, 05/09/2018 - 23:22
On May 22nd, the giant CiviCRM Meetup CiviCamp Calgary arrives! What is a CiviCamp you ask? What is CiviCRM? What is Calgary? Why should a Drupaler care? All will be revealed below, dear reader!

Drupal blog: Offering more inclusive user demographic forms

Mié, 05/09/2018 - 16:05

This blog has been re-posted and edited with permission from Dries Buytaert's blog. Please leave your comments on the original post.

© Open Demographics Initiative's gender identification questions

Last week, Nikki Stevens presented "Other, Please Specify" for TEDx at Arizona State University. In her TED Talk, Nikki shares the story behind the Open Demographics Initiative, which is developing a recommended set of questions that anyone can use to ask online community members about their demographics.

Nikki demonstrates how a majority of demographic surveys require users to conform to restrictive identity fields, which can alienate minority or underrepresented groups. The Open Demographics Initiative wants to develop forms that are more inclusive, in addition to giving people more control over the data and information they chose to disclose.

Inspired by Nikki's presentation, I reached out to the engineering team at the Drupal Association to see if there are plans to implement the Open Demographics Initiative's recommendations on Drupal.org. I was happy to learn that they are collaborating with the Open Demographics team to add the recommendations to the user registration process on Drupal.org.

Adopting Open Demographics on Drupal.org will also allow us to improve reporting on diversity and inclusion, which in turn will help us better support initiatives that advance diversity and inclusion. Plus, we can lead by example and inspire other organizations to do the same.

Thank you Nikki, for sharing the story behind the Open Demographics Initiative, and for helping to inspire change in the Drupal community.

Dries Buytaert: Offering more inclusive user demographic forms

Mié, 05/09/2018 - 15:15

© Open Demographics Initiative's gender identification questions

Last week, Nikki Stevens presented "Other, Please Specify" for TEDx at Arizona State University. In her TED Talk, Nikki shares the story behind the Open Demographics Initiative, which is developing a recommended set of questions that anyone can use to ask online community members about their demographics.

Nikki demonstrates how a majority of demographic surveys require users to conform to restrictive identity fields, which can alienate minority or underrepresented groups. The Open Demographics Initiative wants to develop forms that are more inclusive, in addition to giving people more control over the data and information they chose to disclose.

Inspired by Nikki's presentation, I reached out to the engineering team at the Drupal Association to see if there are plans to implement the Open Demographics Initiative's recommendations on Drupal.org. I was happy to learn that they are collaborating with the Open Demographics team to add the recommendations to the user registration process on Drupal.org.

Adopting Open Demographics on Drupal.org will also allow us to improve reporting on diversity and inclusion, which in turn will help us better support initiatives that advance diversity and inclusion. Plus, we can lead by example and inspire other organizations to do the same.

Thank you Nikki, for sharing the story behind the Open Demographics Initiative, and for helping to inspire change in the Drupal community.

Acquia Lightning Blog: New React-based content Scheduler

Mié, 05/09/2018 - 14:28
New React-based content Scheduler Adam Balsam Wed, 05/09/2018 - 13:28

Lightning 3.1.4 (released on 9 May) ships with a completely new content scheduler built in React. Here's an example of an editor scheduling a piece of content to be published on Friday and archived the following Monday:

We had four main goals when creating this scheduler:

  1. Simplify the UX [Issue #2935198]
  2. Make the scheduler available on content creation forms [Issue #2935105]
  3. Add ability to schedule multiple transition in serial [Issue #2936757]
  4. Give content editors the ability to set the date that content should be published [Issue #2935715]

For the first goal, we had a related team goal of creating something in React. Originally we had thought that might be an internal tool, something that never saw the light of day, or perhaps a configuration form. But when we started digging into the UX challenges of the scheduler, we realized this was a great fit. The result is a responsive, intuitive widget that sits quietly out of the way until you need to interact with it.

The second and third goals were just to fix a couple or regressions that were introduced when we moved away from the Scheduled Updates module as part of the migration to Content Moderation. Both are table stakes functionality for a usable scheduler.

Finally, the fourth goal comes from the reality that, in many workflows, content authors are often the person who knows when content should actually be published. But content authors usually don't have permission to actually publish content - and, as a result, can't schedule that transition either. This system allows site builders to create an "Approved for publish" state. Content authors can then schedule a transition from that state to "Published", but the transition won't actually happen unless an Editor moves the content into the "Approved for publish" state first. Look for more documentation about how we expect people to use that functionality in the near future.

You can find a sandbox of Lightning Scheduler - along with Lightning's other features here:
https://lightning.acquia.com/lightning (admin/admin)

Or update to Lightning 3.1.4 yourself:

$ composer require acquia/lightning:3.1.4 --no-update $ composer update acquia/lightning --with-all-dependencies

Thanks to everyone who helped with testing and UI enhancements. Please file issues in Lightning Workflow's issue queue.

OpenConcept: Privacy is a Big Deal!

Mié, 05/09/2018 - 10:39

The tech sector has undermined personal privacy in the constant pursuit of the latest shiny thing. Privacy is a core component of our democracy and is essential for free expression.

Most have assumed that it is built into the online tools that they use every day. This isn't the case. The media coverage of Cambridge Analytica and Facebook how dangerous this is. The model of surveillance capitalism put forward by Google is now very advanced. Big Data & Artificial Intelligence gives businesses more insights than Big Brother dreamed possible.

Many people are coming to the realization that some state regulation is needed if we are to protect individual freedoms.

Europe has recently instituted the General Data Protection Regulation (GDPR). This legislation is groundbreaking as it not only applies to people in Europe, but to everyone with a European citizenship. How many websites around the world know that they do not have members who have European citizenship?

For the first time, there are real fines associated with not protecting the rights of European Citizens. Violators face fines of up to 4% of annual global revenue or €20 million (whichever is greater).

Most organizations in North America are unaware of the potential implications. Most organizations here probably won't be the first targets, for the European Union, but that is a big risk. The European Commission, the EU’s legislative arm, may choose to be aggressive on the world stage.

I first got involved in looking at the GDPR in early 2017. It seemed that this regulation was something that was complex enough that it should be in Drupal Core. So I started a Drupal issue.

In a CMS like Drupal, it is fair to assume that 80% of the implementations might have some ties to the GDPR. Outside of Europe, the urgency is reduced but for most organizations, it doesn't disappear. My view was that as much as possible should be done at the root of the problem. For many organizations, that is a front facing application like Drupal or WordPress.

Now there is only a small amount that a website can do to bring you to GDPR compliance. As with accessibility, there is value in documenting what you have done for the public. Just like we have a public accessibility statement, we also one for privacy. Users need to have an easy way to know what data you are collecting and how long you keep it for.

There are good efforts in many open source communities to collaborate on building a best practice. These won't be completed for the May 25th deadline, but are still important. It is great to see the leadership from the WordPress and Typo3 communities. There are some great initiatives in Drupal too, including the formation of a Drupal GDPR Compliance Team. This is a community effort to collect and organize improve privacy in our community.

Privacy is a big thing. As with security, there are going to be some elements that really should be dealt with in Drupal Core. The GDPR legislation goes much deeper than this though and will vary much depending on the data collected. There are some great modules that released that are making this much easier. Some changes will need to be made in popular modules that collect user data. There are also challenges like dealing with backups and verifying removal.

More important than the technology is the social side of complying with the GDPR. Documenting the work that has been done, changing the organizational workflow. Ensuring that an organization is legally compliant. The biggest challenge though is in changing the culture so that we challenge ourselves to ask "why are we collecting this information?" - there is a lot of information collected that we just don't need but ask for anyway.

Topic: Primary Image: 

Axelerant Blog: Women at Axelerant: Chapter One

Mié, 05/09/2018 - 10:11

I sat down to speak with the amazing women of Axelerant, and they each shared their unique perspectives about what it's like being professionals in their field. In this chapter, Shweta, Avni, Trupti, and Karuna expound on this—and in their own words.

Ixis.co.uk - Thoughts: Last Month in Drupal - April 2018

Mié, 05/09/2018 - 10:00
April provided plenty of news and updates in the Drupal world and here we take a look at all the best bits from the previous month.

Lullabot: Drupal JavaScript Initiative: The Road to a Modern Administration UI

Mié, 05/09/2018 - 08:19

It's now been over 10 years since Drupal started shipping jQuery as part of core, and although a lot of Drupal's JavaScript has evolved since then it's still based on the premise of progressive enhancement of server-side generated pages. Meanwhile, developing sites with JavaScript has made huge strides thanks to popular rendering frameworks such as React, Angular, and Vue. With some of the web's largest sites relying on client-side only JavaScript, and search engines able to effectively crawl them, it's no longer imperative that a site provides fallback for no JavaScript, particularly for specialised uses such as editorial tasks in a content management system.

At DrupalCon Vienna, the core JavaScript team members decided to adopt a more modern approach to using JavaScript in Drupal to build administrative interfaces, with efforts centred around the React framework from Facebook. To try this out, we decided to build a prototype of the Database Logging page in React, and integrate it into Drupal.

Why Not Vue or Angular?

We chose React because of its popularity, stability, and maturity. Many client projects built with Drupal have successfully leveraged the model of annotating Drupal templates with Angular or Vue directives for quite some time now, but we were wary of building something so tightly coupled with the Drupal rendering monolith. We're very aligned with the API-first initiative and hope that through this work we can create something which is reusable with other projects such as Vue or Angular. The choice of library which renders HTML to the browser is the easiest part of the work ahead, with the hard problems being on the bridge between Drupal and the front-end framework.

What We Learned From The Prototype undefined

As we anticipated, rendering something in React was the easy part— our early challenges arose as we realized there were several missing exposed APIs from Drupal, which we addressed with help from the API-first initiative. Having completed this, we identified a number of major disadvantages to our approach:

  • Although we were creating a component library that could be re-used, essentially we were embedding individual JavaScript applications into different pages of a Drupal theme
  • Our legacy JavaScript was mixed in on the page alongside the new things we were building
  • The build process we currently have for JavaScript can be frustrating to work with because Drupal doesn't have a hard dependency on Node.js (and this is unlikely to change for the time being)
  • A developer coming from the JavaScript ecosystem would find it very unfamiliar

The last point in particular touches on one of the biggest tensions that we need to resolve with this initiative. We don't want to force Drupal's PHP developers also to have to know the ins-and-outs of the JavaScript ecosystem to build module administration forms, but we also don't want developers coming from the world of JavaScript—with promises of "We use React now, so this will be familiar to you!"—to then have to learn PHP and Drupal's internals as well. Having discussed this at length during our weekly initiative meetings, we decided to build an administration interface that is completely separate from Drupal itself, and would only consume it's APIs (aka decoupled). The application would also attempt to generate administration forms for some configuration scenarios.

Hello, world!

We began building our decoupled administration application based on the Create React App starter-kit from Facebook. This is an extremely popular project that handles a lot of the complexities of modern JavaScript tooling and creates a very familiar starting point for developers from the JavaScript ecosystem. So far we haven't needed to eject from this project, and we're enjoying not having to maintain our Webpack configurations, so fingers crossed we can continue with this approach indefinitely.

The first page we decided to build in our new application was the user permissions screen so we could experiment with editing configuration entities. One of the challenges we faced in the implementation of this was the inability to get a list of all possible permissions, as the data we had available from Drupal's API only gave us permissions which had been enabled. We created an Admin UI Support module to start providing us with these missing APIs, with the intention to contribute these endpoints back to Drupal once we have stable implementations.

undefined

We chose to use GitHub as our primary development platform for this initiative, again because we wanted to be in a place familiar to as many developers as possible, as well as to use a set of workflows and tools that are common across the greatest number of open source projects and communities. Using GitHub and CircleCI, we've created an automated build process which allows Drupal developers to import and try out the project with Composer, without requiring them to install and run a build process with Node.js. Over the long-term, we would love to keep this project on GitHub and have it live as a Composer dependency, however, there are logistical questions around that which we'll need to work through in conjunction with the core team.

A New Design

Having got the architectural foundations in place for our application, we then turned to the team working on redesigning the admin UI to collaborate more closely. One of the features we had already built into our application was the ability to fall-back to a regular Drupal theme if the user tried to access a route that hadn't been implemented yet. Using this feature, and trying to keep in mind realistic timelines for launching a fully decoupled admin theme, the team decided that our current path forward will involve several parallel efforts:

  • Create new designs for a refreshed Seven-like theme
  • Adapt the new designs to a regular Drupal theme, so the fallback isn't jarring for the user
  • Build sections of the administration interface in the new React application as designs become available, hopefully starting with the content modeling UI
undefined Hard Problems

We still have a lot of issues to discuss around how the administration application will interact with Drupal, how extensible it can be, and what the developer experience will be like for both module authors and front-end developers. Some of the major questions we're trying to answer are:

  • How and what is a Drupal module able to do to extend the administration UI
  • We're not looking to deprecate the current Drupal theming system, so how can modules indicate which "mode" they support
  • If a module wants to provide its own React component, do we want to include this in our compiled JavaScript bundle, and if so how do we build it when Drupal has no requirement to include Node.js
  • How can modules provide routes in the administration UI, or should they become auto-generated
  • How do we handle and integrate site building tools such as Views, or do we replace this with the ability to swap in custom React components
Forms

How we're going to handle forms has been a big point of discussion, as currently Drupal tightly couples a form's schema, data, validation, and UI. Initially, we took a lot of inspiration from Mozilla's react-jsonschema-form project, which builds HTML forms from JSON schema and separated out these concepts. Nevertheless, a major issue we found with this was it still required a lot of form creation and handling to happen in Drupal code, instead of creating good API endpoints for the data we want to fetch and manipulate.

undefined

The approach we're currently looking at is auto-generating forms from configuration entities and allowing a module to provide a custom React component if it wants to do something more complex than what auto-generation would provide. Here's a working (unstyled!) example of the site information form, which has been auto-generated from an API endpoint.

undefined

We're now looking to augment configuration entities with metadata to optionally guide the form display. (For example, whether a group of options should be a select dropdown or radio buttons.

Try It Out and Get Involved

We have a Composer project available if you want to check out our progress and try the administration interface out (no previous Drupal installation required!). If you're looking to get involved we have weekly meetings in Slack, a number of issues on GitHub, our initiative plan on drupal.org, and lots of API work. You can also join us in-person at our next sprint at Frontend United in June.

A very special thank you to my initiative co-coordinators Matt Grill and Angie Byron, as well as Daniel Wehner, Ted Bowman, Alex Pott, Cristina Chumillas, Lauri Eskola, the API-First initiative, and all our other contributors for everyone's stellar work on this initiative so far!

⬅️✌️➡️  

OPTASY: Reservoir or Decoupling Drupal Made Easy for Anyone: Non-Drupal Developers and Editors

Mié, 05/09/2018 - 04:55
Reservoir or Decoupling Drupal Made Easy for Anyone: Non-Drupal Developers and Editors admin Wed, 05/09/2018 - 07:55

Here's how the ideal decoupling Drupal scenario looks like:

Stripping Drupal to its essential role, that of a robust and flexible content repository, with no Drupal expertise needed. Then using it to back your front-end with; one that you'd be free to build by leveraging any modern (JavaScript) technology of your choice.

… a Drupal back-end content store that would still preserve all its content editing and managing functionalities, needless to add.

Luckily, this is no longer “daydreaming”. Not since Reservoir, the headless Drupal distribution, has been available. 

Here are some of its “promises” or well-known challenges, if you prefer, that this distribution's geared at solving:
 

Valuebound: E-Commerce Solutions and Third-Party Integration Options within Drupal Ecosystem

Mié, 05/09/2018 - 01:45

Drupal has several options and solutions to develop different types of websites including e-commerce portals. Drupalers have redefined the way e-commerce sites used to operate by developing a range of plugins and modules for high-end security, tailored web content, third-party integration, and other utilities. These modules primarily aim at enhancing end users experience, providing a user-friendly interface, flexibility, and reliability.

There are several e-commerce options within Drupal along with options to integrate third-party APIs, which I’ll discuss in a later section. Let’s first discuss the options…

PreviousNext: Making your Drupal 8 kernel tests fail when there is an exception during cron

Mar, 05/08/2018 - 23:39

Several times in the past I've been caught out by Drupal's cron handler silently catching exceptions during tests.

Your test fails, and there is no clue as to why.

Read on to find out how to shine some light on this, by making your kernel tests fail on any exception during cron.

by Lee Rowlands / 9 May 2018

If you're running cron during a kernel test and expecting something to happen, but it doesn't - it can be hard to debug why.

Ordinarily an uncaught exception during a test will cause PHPUnit to fail, and you can pinpoint the issue.

However, if you're running cron in the test this may not be the case.

This is because, by default Drupal's cron handler catches all exceptions and silently logs them. This is colloquially known as Pokemon exception handling.

The act of logging an exception is not enough to fail a test.

So your test skips the exception and carries on, failing in other ways unexpectedly.

This is exacerbated by the fact that PHP Unit throws an exception for warnings. So the slightest issue in your code will cause it to halt execution. In an ordinary scenario, this exception causes the test to fail. But the pokemon catch block in the Cron class prevents that, and your test continues in a weird state.

This is the code in question in the cron handler

<?php try { $queue_worker->processItem($item->data); $queue->deleteItem($item); } // ... catch (\Exception $e) { // In case of any other kind of exception, log it and leave the item // in the queue to be processed again later. watchdog_exception('cron', $e); }

So how do you make this fail your test? In the end, it's quite simple.

Firstly, you make your test a logger and use the handy trait to do the bulk of the work.

You only need to implement the log method, as the trait takes care of handling all other methods.

In this case, watchdog_exception logs exceptions as RfcLogLevel::ERROR. The log levels are integers, from most severe to least severe. So in this implementation we tell PHP Unit to fail the test with any messages logged where the severity is ERROR or worse.

use \Drupal\KernelTests\KernelTestBase; use Psr\Log\LoggerInterface; use Drupal\Core\Logger\RfcLoggerTrait; use Drupal\Core\Logger\RfcLogLevel; class MyTest extends KernelTestBase implements LoggerInterface { use RfcLoggerTrait; /**    * {@inheritdoc}    */   public function log($level, $message, array $context = []) {     if ($level <= RfcLogLevel::ERROR) {       $this->fail(strtr($message, $context));     }   } }

Then in your setUp method, you register your test as a logger.

$this->container->get('logger.factory')->addLogger($this);

And that's it - now any errors that are logged will cause the test to fail.

If you think we should do this by default, please comment on this core issue.

Tagged Drupal 8, Drupal Development, Drupal testing, PSR-3

Palantir: Retheming Palantir.net for Our Audience

Mar, 05/08/2018 - 17:47
Retheming Palantir.net for Our Audience brandt Tue, 05/08/2018 - 15:47 Alex Brandt May 8, 2018

The new www.palantir.net is a decoupled instance of Drupal 8 that allows us greater flexibility to feature content that is most relevant to our site visitors.

When we first migrated our website (https://www.palantir.net) from Drupal 7 to Drupal 8 in the summer of 2016, it was an exciting time for our marketing team. From an editorial perspective, Drupal 8 is a much easier to use interface than D7, and it instantly allowed us greater flexibility with our content.

However, even though we now had a more flexible site, we still felt like the digital experience for our audience missed a few marks. We quickly established a list of goals for phase two of the redesign, and these goals were related to both the overall digital experience and internal business goals.

The Overall Digital Experience

With the next iteration of our site, we wanted to focus on making the site more intuitive for visitors and also surface content in a way that was most beneficial to them. Would future clients prefer to filter case studies by service category or industry? What were visitors hoping or expecting to find on the homepage? What kind of information about Palantir were potential new hires trying to find?

These questions informed the following goals for the site:

  • To be simple and easy to use by having meaningful (and working) filters, allowing users to filter by industry, and curating collections around topics that most interest our audience.
  • To inspire applicants by demonstrating solid work, showcasing our cultural story, and making it easy to find career information.
  • To tell the story of Palantir with crisper messaging, improved visuals, and better storytelling throughout via weaving client testimonials with staff stories and case studies.
  • To be future forward by creating a visual theme with a timeless solution.
Business Goals

We also had a few items we wanted to address that related to our overall business goals. Our website is an important sales and marketing tool for us, and we wanted to make sure it was doing its job. We needed the new site to:

  • Showcase our work better by making it more prominent, showing more visuals and making our visuals more consistent.
  • Capture leads and bring in more business by making it easy for people to contact us no matter where they are on the site, and by simplifying newsletter sign-up.
  • Elevate the Palantir brand by creating a newly themed site that in itself is a demonstration of our design and development skill, showcasing our work in a superior way, and talking more intelligently — but concisely — about ourselves, our work, and our services.
The Process

Just like we recommend for our clients, we began our process with a Discovery phase. One of our web strategists, Michelle Jackson, completed a competitive analysis to inform next steps. A few of the things she evaluated were:

  • What are our peers doing right?
  • What are the current industry standards?
  • What are agencies that we aspire to emulate doing?

The results from this analysis helped us prioritize our wishlist of future site features. We then handed off this wishlist to the designer on the project, Carl Martens. Carl worked through the design phase which included creating wireframes, moving things into a prototype, and then building out the new theme in partnership with Ken Rickard, who completed all of the development. The design was done using our standard process: we built in a modular way using site components, and then compiled them into a living style guide. Particular attention was paid to typographic details, use of color, and how to most effectively use images.

Another design problem we needed to solve was one common to all companies that list their team members: what do you do when a new employee joins the team, and you don’t have a photo for them that matches the others? Even our photographer (who only does our headshots once per year) said, “all my clients have this problem. Let me know when you figure it out!” We thought of several options on how to fix this, and ended up with the chalkboard solution. It allows us to inject some personality into our page while not distracting from the other headshots by having it be a headshot in a different style or lighting.

We decided it was best to do a decoupled instance for this site. More details about the technical implementation of the decoupled Drupal instance can be found in Ken's upcoming blog post.

New Features and Integrations

The latest version of www.palantir.net has an abundance of new features that allow us to weave storytelling throughout the site.

Searchable Homepage

Our previous homepage had much of the important content buried beneath the fold. To fix this, we wanted to turn our homepage into a hub where site visitors could search for content that was relevant to them, no matter where that content lived on the site. The new homepage can filter all of our content by both topic and industry, and helps surface the most relevant pieces of content for our audience. The new homepage also features a collapsible side navigation, so you can see more relevant content at one time.

Topic-Based Collection Pages

Tying into the goals of our searchable homepage, we curated new collection pages based on topics we thought our audience would search for most (which include Planning, Business Strategy, Security, Design & UX, Development, Governance, Content Strategy and Accessibility). That way when someone asks, “what do you do for accessibility?” we can send them directly to a curated page that shows blog posts and case studies specific to that topic. These collection pages can be found at the bottom of our services page.

 

Culture and Careers Content

With the next iteration of the site, we wanted to make sure we were catering to the audience who might be interested in working for us in the future. We achieved this by showcasing all of the great things about working at Palantir, and on these pages we included more images to help show rather than tell that information. Our new Culture and Careers page houses much of the information a potential new Palantiri might look for, including what we think are the key elements of our culture. It also links to our Benefits page which outlines the many perks of working for Palantir, and to our current openings.

Case Studies That Tell a Story

Some of the most important pieces of content on our site are our case studies. It is vital as an agency to be able to showcase our work and capabilities dynamically. The old version of our case studies were extremely text-heavy and did not feature nearly enough visual representation of the process or final product of each project.

The new format of our new case studies are broken into different chunks of content, with the ability to show each bit of information in a way that fits what is being communicated. We can then weave each of these pieces together into one comprehensive, dynamic storyline. By breaking the case studies into smaller, more visual pieces, they are much easier to scan too. We still have to update some of our older case studies, so this is still a work in progress.

 

Updated Services Page

One would think a services page would be the first page to be refined on a business’ site, but somehow our previous services page was a complete afterthought. Buried in the footer, it was a glorified bulleted list. This page was a high priority for us to fix, because we wanted to make sure potential clients could find information about what services we provide. The new services page is easy to find in the main site navigation, and in addition to the afore-mentioned collections, it also features information about our partnerships.

Hubspot Integration

Hubspot is a new sales and marketing tool for us that we have been implementing since the beginning of the year. It helps us track new project opportunities on the sales side, and it also houses all of our marketing tools. One of the new Hubspot tools that we have implemented on our new site is called a lead flow. Lead flows are abbreviated contact forms that we can choose to display on specific pages, granting our site visitors a quick way to subscribe to our email newsletter.

Always Evolving

In true agile fashion, we had an MVP with the goal of launching by DrupalCon Nashville, but we plan to keep iterating and improving the site in the coming months. So, what do we have planned next?

  • New photos for new staff
  • Video that reiterates the Palantir story
  • A timeline of the history of Palantir
  • Listing of awards and press mentions (Great Place to Work, Clutch.co, etc.)
  • Rewriting and adding more case studies
Accessibility

Of course, we also want to make sure our site is accessible. In addition to baking accessibility into our process along the way, we use a tool provided by our partner, Siteimprove, to scan our site and determine if it meets accessibility standards. Siteimprove is a great tool because it flags both quality assurance items (like misspellings and broken links) as well as accessibility requirements (like those provided by WCAG and AA). We use the reports provided by Siteimprove to continuously clean up our content and ensure an enjoyable digital experience for all users.

Tell Us What You Think

So far we’ve had one client tell us this: “The redesign clearly marks a maturation and growth of Palantir. If progressing towards a more serious, trustworthy, and refined company was the goal, I think you nailed it.” We sure hope so!

We’d love to hear what you think about the new site. Share your thoughts on Twitter (@palantir) or by reaching out through our contact form.

Design Development Drupal Site Building Strategy

OSTraining: How to Build User Profiles With Fields in Drupal 8

Mar, 05/08/2018 - 17:26

By default, a Drupal 8 user account collects only very basic information about the user. 

And, most of that information is not visible to visitors or other users on the site.

Fortunately, Drupal makes it easy to modify and expand this profile so that people can add useful information about themselves such as their real name (versus a username), address, employer, URLs, biography, and more.

OSTraining: How to Manage User and Role Permissions in Drupal 8

Mar, 05/08/2018 - 17:23

This tutorial is all about managing uses on your Drupal 8 site.

I'll show you how to control who can do what on your site:

  • Who can create, delete, and edit content?
  • Who can upload modules and themes?
  • Who can modify menus and blocks?

You also see how to make user accounts more interesting. You do this by allowing users to add more information about them. 

ADCI Solutions: How to send the JSON data from a Drupal 8 site?

Mar, 05/08/2018 - 14:11

Imagine a situation: your mobile application needs to get some information from your Drupal 8 site. How can you do it? There are several ways to create and send data with JSON, and we will consider three of them.

Learn about the data sending in Drupal 8

Páginas