Здравей Гост ! Регистрирай се и влез .

Навигация на книгата

Последни коментари

Кой е онлайн

В момента са 0 потребители и 0 гости online.

Гласуване

Колко тестови Друпал сайта имате?
1-5 бр.
61%
5-10 бр.
16%
10-15 бр.
8%
15-20 бр.
3%
20-30 бр.
3%
30-40 бр.
3%
40-50 бр.
3%
над 50 бр.
5%
Общо гласове: 38

Разпространи

Разпространи съдържание

Агрегатор на източници

SOUTHCARE

Drupal Case Studies - 23 Януари, 2018 - 16:24
Completed Drupal site or project URL: https://www.southcare.us

SouthCare is the leading provider of cremation, memorial and burial services in the State of Georgia. SouthCare has built its reputation as a distinct alternative to traditional Atlanta funeral homes. They provide cremation and funeral services that are professional, compassionate and attentive, while offering their clients, affordable options for cremations or funeral arrangements.

Категории: Drupal Case Studies

Amazee Labs: Practices - Amazee Agile Agency Survey Results - Part 9

Planet Drupal - 23 Януари, 2018 - 12:10
Practices - Amazee Agile Agency Survey Results - Part 9

This is part 9 of our series processing the results of the Amazee Agile Agency Survey. Previously I wrote about client interactions; this time let’s focus on practices. How often do teams deploy code? Are they practising peer reviews, automated testing, pair programming or story mapping?

Josef Dabernig Tue, 01/23/2018 - 10:10

When asked about “How often does your team deploy code?”, 53% of the teams answered they would do deployments “Rolling / Whenever necessary”. 13.3% deploy “About once a week”, another 13.3% “About every two weeks” and 6.7% answered they would deploy “Daily”. The remaining chose to go with freeform answers such as different frequencies based on the dev/stage/live environments or that it would depend on the client.

For us at Amazee, the deployment schedule depends on the needs of the clients. Thanks to the automatization that our Amazee.io hosting environment provides, any team member can execute a deployment on their own if it makes sense. Some High-availability clients require a fixed deployment schedule that our team has programmed to happen every week, besides that only critical hotfixes would be deployed instantly out of the schedule. Most of our clients allow us to deploy whenever, yet if a downtime for more complex deployments is needed we usually try to schedule them outside of business hours. For global customers that run their website across the globe, we try to find the deployment slot that fits best and rely on a proxy server like Varnish that keeps serving anonymous users during a deployment downtime.


Our second question was geared towards finding out which agile practices would be used by teams and how important they are considered. Contestants were able to rate from “Unknown”, “Not needed”, “Tried but failed” to “Somewhat in use”, “Actively in use” up to “Very important”. The practice that was mostly unknown is Mob programming.  Story mapping is also widely unknown but also has a good number of constants rating it with “Somewhat in use”. Pair programming is somewhat in use for many but also has a good number of contestants who responded “Unknown” or “Not needed”. The practices mostly rated as “Very important” where Peer reviews/code reviews as well as User testing. Automated testing got a lot of votes for “Somewhat in use”, and a few ones rated it as “Very important”. Per-ticket branch test environments have been rated as “Somewhat in use” by many as well.

For us at Amazee, we do Peer & code reviews for every work increment within our Scrum teams. This ensures code quality, knowledge transfer and feedback between team members. Automated testing happens for mission-critical features. Vasi has an article with good arguments why you should invest in it. User testing is performed on about a third of our projects. Automated deployments, continuous integration and per-ticket branch test environment are extensively used thanks again to the Amazee.io hosting environment goodies. Pair programming is quite common for our teams. While we have experimented with mob programming for teaching purposes, our team didn’t entirely pick it up. Finally, story mapping is something that we started using recently with good results, but we don’t have too much experience with it, yet.

Which practices do you use and how often do you do deployments? Please leave us a comment below. If you are interested in Agile Scrum training, don’t hesitate to contact us.

Stay tuned for the last post where we’ll do a round up of the Agile Agency Survey.

Категории: Planet Drupal

Colorfield: Install Solr 7 for Drupal 8 Search API on Ubuntu 16.04

Planet Drupal - 23 Януари, 2018 - 10:51
Install Solr 7 for Drupal 8 Search API on Ubuntu 16.04 christophe Tue, 23/01/2018 - 08:51 A brief introduction to Search API Solr, an update on the ecosystem and how to get Search API 2.x working on a dev environment with multiple collections.
Категории: Planet Drupal

Drupal core announcements: Drupal 8 will require PHP 7.0 or higher starting March 6, 2019 (one year from now)

Planet Drupal - 23 Януари, 2018 - 03:43

Drupal 8 will require PHP 7.0 or higher starting March 6, 2019. Drupal 8 users who are running Drupal 8 on PHP 5.5 or PHP 5.6 should begin planning to upgrade their PHP version to 7.0 or higher. Drupal 8.6 will be the final Drupal 8 version to support PHP 5, and will reach end-of-life on March 6, 2019, when Drupal 8.7.0 is released. (If 8.7.0 is released before March 6, 2019, the release number for the end-of-life will be updated accordingly, but the end-of-life date will remain the same.)

When planning for which PHP version to upgrade to, consider that PHP 7.2 was released on November 30, 2017 and will remain supported longer than older PHP 7 versions.

Why is support being dropped for PHP 5.5 and 5.6?
  • PHP 5.5 has already reached official end-of-life in 2016. Following that, a growing number of the PHP libraries used by Drupal 8 have also started to discontinue support for PHP 5.5.
  • PHP 5.6 stopped receiving active support from PHP maintainers in January 2017. This means that it is no longer receiving bugfixes, even for some very serious bugs that impact Drupal development.
  • PHP 5.6 is the final PHP 5 version, so the PHP maintainers are providing two years of security fixes for PHP 5.6 beyond its active support, through December 2018. This is a few months after Drupal 8.6's scheduled release and well before Drupal 8.7 would be released.
  • Drupal 8's automated tests require the PHPUnit library, which will drop support for PHP 5.6 in February 2018. Several other third-party dependencies are also dropping PHP 5.6 support in their latest versions.
  • To minimize disruption for both Drupal users and Drupal developers, Drupal 8's support of PHP 5.5 and PHP 5.6 will end at the same time.

We understand that upgrading from PHP 5 to PHP 7 may require time to plan and deploy. We suggest upgrading to PHP 7 in 2018 (rather than waiting for Drupal 8.7.0’s release).

What if I'm using a hosting service that doesn't offer PHP 7?

A majority of PHP hosting providers already offer PHP 7. If you're using one that doesn't, we suggest asking that provider when they will make it available, and if it's not until after March 2019, leave a comment on our tracking issue linking to that hosting provider, so that we can better understand the outliers, and perhaps offer some help.

What if I'm at an organization that maintains its own hosting, and we're using Ubuntu 14.04, which bundles PHP 5.5?

You have a few options if you are using Ubuntu 14.04:

  1. The preferred option is to plan an upgrade to Ubuntu 18.04 (to be released on April 2018, 2018). This version will be the most future-compatible.
  2. Another option is to upgrade Ubuntu 16.04, which is available now. You may need to upgrade Ubuntu again in a couple years if you choose to upgrade to 16.04 now.
  3. Finally, you can choose to upgrade to a separate build of PHP. Ondřej Surý provides a widely used PPA for doing this.
When will Drupal 8 drop support for PHP 7.0?

Support for PHP 7.0 will continue until at least March 6, 2019. We do not yet know whether Drupal 8's PHP 7.0 support will continue past that date, but we will post another announcement as soon as the end of PHP 7.0 support has been scheduled. We recommend you update to PHP 7.1 or higher since those versions will be supported longer.

How does this affect Drupal 8 core development?

Backported fixes account for about 80% of all changes and must continue to work on PHP 5.5 and 5.6 throughout Drupal 8.6.x's support cycle. For this reason, no PHP 7-only changes will be made until the 8.8.x branch is opened in early 2019 (or 8.9.x if 8.8.0 is released in 2018). Once 8.8.x is opened, the library dependencies in that branch can be updated to versions that have a PHP 7.0 requirement, and the Drupal code itself in that branch can begin relying on PHP 7 features. (Drupal 8 release cycle information)

The automated test suite already defaults to using PHPUnit 6 on environments that use PHP 7, but falls back to PHPUnit 4 on PHP 5. The fallback will be removed in the 8.8.x branch.

Does this affect Drupal 7?

No. Drupal 7 remains compatible with PHP 5.2.4 and higher. A separate announcement will be issued if and when that changes.

Категории: Planet Drupal

Palantir: What “Content” Means to Different Teams

Planet Drupal - 23 Януари, 2018 - 01:21
What “Content” Means to Different Teams brandt Mon, 01/22/2018 - 16:21 Ken Rickard Jan 23, 2018

The importance of aligning editorial, marketing, design, and development.

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

Sign up for our newsletter.

As we’ve discussed before, understanding the content on your website is a critical element in the project plan. Today, we’d like to step back a bit and talk about how different teams in an organization might think about content.

First, let’s define our common teams by function:

  • The Editorial team produces and maintains content for the site.
  • The Marketing team sets strategy and metrics around successful audience engagement and interactions.
  • The UX Design team creates the strategy, visual and interactive components that comprise the site’s features.
  • The Development team builds and supports the site so that it fulfills the needs defined by the other three teams.

Note that these teams may all be organized within a single department (commonly marketing) or spread across the organization. Our concern here is not with organizational structure but rather with the perspective and concerns that are inherent in each team.

When teams start work on a new site or a site redesign, the most common mistake is for these four teams to work in silos, as if their individual tasks are unrelated to each other. In this case, a number of issues may arise:

  • A design may include elements that place extra burden on the editorial team.
  • An editorial workflow may require the development of custom code.
  • A marketing plan may ignore the limited editorial and design resources available to achieve its goals.
  • Organizations that have a history of heavily relying on non-digital media for marketing and promotions may have to figure out how to incorporate and plan for the digital work into the existing workflow.
  • A CMS implementation may not be able to produce certain essential design features, or budget and timeline prevents features from being designed a certain way.

Working together, teams can work through these types of issues before they become problems. To do so, it’s vital to get everyone speaking the same language around your content. We like to look at five specific factors when helping teams define their content strategy:

  • Audience defines the users and their needs and answers “who is this for?”
  • Purpose asks the question “what end result are we hoping to achieve?”
  • Workflow deals with the mechanics of content production, approval, publication, and presentation.
  • Transformation explores issues of translation and personalization, so that we define how the content might be modified in distinct contexts.
  • Structure defines the input and storage of the content and how it will be delivered to various publication media. The structure is directly affected by the needs outlined by the three previous items.

Each of these elements has a direct effect on each of our project teams. To understand how, Let’s take a look at Dr. Gillinov’s bio page at Cleveland Clinic to see how these questions bring focus to our project goals.

 

There are many elements that make up this comprehensive profile page and they all require each team member mentioned above to consider the following:

  1. Where does the data/content come from?
  2. What pieces of data/content is the editor responsible for?
  3. What does this page look like if it has all of the possible content types vs. physicians who have very little information?

For the purposes of this discussion, however, let’s focus on the top portion of the page addressing the data/content that makes up Dr. Gillinov’s basic information as it will help us illustrate our points.The first thing we look for here is the number of elements within the design pattern and how they might be produced. At first count, there are 11:

Let’s see how those elements break down.

  1. Picture – an uploaded image of the person.
  2. Video Link – a link to an external video service
  3. Rating – 1-5 stars based on patient feedback
  4. Rating Count – the number of patient ratings
  5. Comment Count – the number of patient comments
  6. Name – the name and honorifics for this person
  7. Department – the assigned internal department
  8. Primary Location – the main office location for this person
  9. Type of Doctor – indicates pediatrician, adult physician, or both
  10. Languages – a list of languages spoken
  11. Surgeon – indicates that this person is a licensed surgeon
Audience

There are multiple types of users that would view this page: potential patients, existing patients, families of patients, and medical professionals. Their needs are different based on who they are and where they are in their care journey.

Purpose

The primary purpose of this specific component is to provide basic information to the audience. The information presented helps them understand the services and availability of this doctor. The use of a picture and a video are designed to build trust by establishing a human connection in addition to the facts presented.

The inclusion of patient ratings serves as an impartial arbiter of the quality of services provided, while the department and location information helps people understand where they can go to receive treatment.

Workflow

For this example, the important question is “Which part of this page is editorial and which part is automated?” Here, the ratings pull in from a secondary system, which the editors do not control. The video is merely a link reference, but is editorial data. And while some of the doctor information might be pulled from an external system, here we assume that it can be edited for display on the web.

There is also an unlisted assumption here – call it feature #12 – about whether or not this doctor has active privileges at the hospital. Our editorial workflow needs to account for when an individual physician changes jobs, retires, or moves away.

Transformations

We use the term “transformations” here as a bit of a catch-all to describe how the data might need to change in different contexts. A common context shift is language.

When considering a multilingual website, we need to evaluate each element of the page for the desirability and feasibility of its translation.

Take the Video field for instance: Translating the link text for a video is trivial, but does the video itself need to be recorded in multiple languages (or at least subtitled)? Does it make sense to show a Spanish translation of the video link if the video is only in English?

The other most common transformation is personalization, wherein content elements are transformed based on our understanding of who the reader is and what they care about.

The key factor to consider about personalization is that it can create exponentially more work for the editorial team. Consider that for each element that desires personalization, we must create one new version for each variation. Let’s say that we want to segment our audience experience by three data points:

  • Returning patient (yes / no)
  • Local resident (yes / no)
  • Age cohort (child / adult / senior)

Now our one piece of content needs 2 x 2 x 3 = 12 variants, plus the original. For clarity, here’s how that looks mapped out: 

If we add in cases where one of the answers is not known, then the math becomes 3 x 3 x 4 = 36 plus the original variant.

As you can imagine, keeping track of those options can become a heavy editorial burden quite quickly if we were to personalize multiple elements on a page.

Structure

The above questions help inform how this page is structured on the back end. Additionally, we have to consider:

  • What fields do we need to capture and report this data?
  • What format should the data be displayed in?
  • What services (other than the website) might consume this data?
  • In what other contexts might this data be shown?

This last question gives an easy example of the type of decision that your programmers may need to make. To fully understand, let’s look for a minute at the contexts of a search result.

Here, the results are alphabetized by the physician’s last name. If we were to enter the physician’s name as it appears in English, “A. Mark Gillinov, MD”, a computer cannot natively sort by last name. We should also consider whether the honorific “MD” should influence sort order, and whether to sort by first and last name in the case of multiple matches to a common surname.

That generally leads to a separation of the sort field into a 14th field concept: Sort name. In our example the sort name is likely to be “Gillinov Mark A.” The remaining question is whether editors should provide that detail or if it should be automatically inferred by a custom element in the CMS.

Additionally, look at the elements that contain links:

  • Video
  • Ratings
  • Department
  • Primary Location

The target of these links needs to be captured, and the logic for that link generation accounted for in the CMS architecture. Further, can these elements be automatically derived from existing data (like the doctor’s name) or are they “hidden” metadata points that need to be added?

In most cases, the mapping for these elements is based on metadata:

  • Video – requires a unique URL for a YouTube video.
  • Ratings – requires a physician ID number provided by the ratings service.
  • Department –  selected from a list of Department pages controlled by the CMS.
  • Primary Location – selected from a list of Location pages controlled by the CMS and containing mapping metadata.

And to add one more element to the structure question: Which of these page elements allow for multiple selection? Can a doctor be part of two departments? Have three primary locations?

Making the Complex Simple

These kinds of workflow complexities in your data are absolutely essential to capture as early in the design process as possible. What if we find that “Languages spoken” is very important to patients, but not currently available in our information set? That requires additional editorial work – and likely a staff-wide survey – that could take weeks to complete simply due to the coordination involved. It is also worth mentioning the impact on initial design choices as well. For example, do we need to consider fonts that have text alternates for language glyphs? Does the design still hold up (spacing, line length, relationship to imagery etc) when there is twice as much French text as English?

Since we’re working directly with Marketing to define our audience and purpose of each page, we should understand how each element of the design improves the overall user experience. That knowledge allows the entire team to make informed decisions about the level of effort to produce and maintain each content element.

All members of the team should have a familiarity and respect for the concerns of other members of the team. When developing and planning content, it is imperative to involve all four teams as early in the process as possible. To bring your content into focus, always ask the following questions about any design or content element shown in a wireframe or mockup:

  • What content or data will be needed to produce this element?
  • Does this content or data already exist in a usable format?
  • What format will this data be entered and stored in?
  • Will this element be editorially curated or automatically produced?
    • If automated, do we have business logic to support that automation?
    • If curated, do we have the staff time to support that creation and maintenance?

Building a robust content model and workflow is a team effort. The functionality of the CMS and the designs they are capable of producing is what brings the Editorial, Marketing, Digital and IT teams together. Giving them the visibility into each other's work streams allows them to collaborate. This collaboration also gives the various team members collective ownership over the content experiences within their organizations.

We want to make your project a success.

Let's Chat.
Категории: Planet Drupal

PreviousNext: Ok Drupal - talking to Drupal

Planet Drupal - 22 Януари, 2018 - 23:57

In November 2017 I presented at Drupal South on using Dialogflow to power conversational interfaces with Drupal.

The video and slides are below, the demo in which I talk to Drupal starts in the first minute.

by Lee Rowlands / 23 January 2018 Tagged Conversational UI, Drupal 8, Chatbots, DrupalSouth
Категории: Planet Drupal

WeKnow: Survival guide to Backup & Restore MongoDB

Planet Drupal - 22 Януари, 2018 - 22:06
Survival guide to Backup & Restore MongoDB

Despite being on the market for over a decade, to many, MongoDB still carries a mythical tone with a hint of ‘wizardry’.

The popular misconception is that MongoDB is only suitable for hip startups and former startups that are still considered ‘hip’ and out of the box, such as AirBnB.

Even with all the buzz and talk around MongoDB, the adoption rate remains relatively low in comparison with other ‘standard’ relational database technologies. Not many seem to understand that to be successful in the world of code you must approach everything new with an open mind.

Besides bearing an open mind, you need to incorporate an avenue to test and learn new technologies and tools. Personally, I choose to learn how to use new tools by trying to accomplish routine tasks.

enzo Mon, 01/22/2018 - 19:06
Категории: Planet Drupal

MISSIONTIX

Drupal Case Studies - 22 Януари, 2018 - 18:36
Completed Drupal site or project URL: https://www.mt.cm

MissionTix, a Baltimore-based online ticketing service, has catered to promoters, venues, and festivals since 2001, offering lower service fees, marketing strategy, support, and personalized customer service.

MissionTix services include:

  • Traditional paperless ticketing mediated through iPhone app and mobile website.
  • Linked access to promote the event through social media platforms.
  • In-house web design and marketing.
  • Seating assignment.
  • Box-office support.
Категории: Drupal Case Studies

Mediacurrent: Power your Drupal 8 Project with Docksal

Planet Drupal - 22 Януари, 2018 - 17:09

Hello and welcome to my first blog post for Mediacurrent! Today’s post will be all about Docksal and how it can help you get up and running developing on Drupal 8 quickly and easily. This post was inspired by the great session I saw at DrupalCon 2017 and will explain how using Docksal will save you time getting up and running for a new Drupal development project. I’ll also talk about some of the technologies behind Docksal such as Docker and Oracle VM VirtualBox.
 

Категории: Planet Drupal

Amazee Labs: What the hell is GraphQL?

Planet Drupal - 22 Януари, 2018 - 13:16
What the hell is GraphQL?

With the growing popularity of GraphQL, the obligatory host of more or less founded opinions - trying to tell you that it's all just a hype - is also on the rise throughout the internet. 

Some of them have a point, some don’t, and you bet we have an opinion too.

Philipp Melab Mon, 01/22/2018 - 11:16

The end of the year is now way past us and I crunched some numbers. The most frequent question I’ve been asked was: «Philipp, could you mute yourself? Your keyboard is very loud.» But that one wouldn't promise a good blog post. So, instead, I will write about the second most frequently asked question: «Why would you use GraphQL instead of REST?»

Honestly, because I wanted to avoid a discussion, which I knew would take too long, I often gave one of the following diplomatic answers: «They serve different use cases.», «It’s a matter of taste.», «GraphQL can’t do everything …»

So here’s my new years' confession: I lied

Common perception of GraphQL

When reading opinions about GraphQL distinct patterns keep popping up. Let's have a look at them. 

GraphQL is there to reduce HTTP requests

When fetching complex related data sets with REST, you need to issue multiple requests. GraphQL avoids that by specifying all information requirements upfront. This is true, but just a small part of the picture. HTTP2 would be a better option to just reduce the overhead of multiple requests, without turning everything else upside down.

GraphQL is a supplement to React

That is a widespread misunderstanding since GraphQL was born out of requirements that emerged with complex Javascript clients, which in turn happen to be implemented with React quite often these days. But GraphQL doesn’t make any assumptions about the client technology it is consumed with. It doesn’t even assume it’s used above HTTP.

GraphQL is not cacheable

A GraphQL query may contain information from different entities, varying fields with arbitrary naming and therefore responses can’t be cached. Responses can be cached, but it’s harder. Besides, it is part of the client’s responsibility to construct queries intelligently, so they can be cached instead of blindly cramming everything into one request.

GraphQL is insecure

Or a less drastic wording: GraphQL has a larger attack surface. Depending on your application, that’s true. Since one query can request a cascading amount of related entities, there’s a lot more potential for something going south. This can be mitigated by designing the schema in a way that doesn’t allow funky constructs or using static query complexity analysis to reject queries that could get out of hand. But both approaches require experience and engineering. It’s definitely easier to safeguard a REST API.

GraphQL is a replacement for REST

That's the big misunderstanding. In my opinion, GraphQL shouldn’t be perceived as an alternative to REST, but as the layer underneath. Conceptually, a REST endpoint is nothing but a persisted GraphQL query.

From a consumers perspective, GraphQL can do anything REST can. Period. There is no valid reason to choose REST over GraphQL.

From a providers perspective, the reduced subset of actions and predictable responses of a REST API are a lot easier to manage.

GraphQL’s elevator pitch

This brings me to the 3rd most asked question of 2017: What’s GraphQL’s elevator pitch?

GraphQL shifts control from data storage and structures to client and product development.

This also answers the question of “when” to use GraphQL: Whenever you want your client to be more powerful. This might not be the case for a public HTTP API. But whenever you control the client, GraphQL is the better choice. And keep in mind that “client” doesn’t necessarily mean web browser, React frontend or smartphone application. GraphQL provides a structured way to describe information requirements that are not limited to HTTP.

It is for example possible to use GraphQL in combination with Twig to turn Drupal’s push-based rendering model upside down and give theme developers all the power they longed for. But this story has already been told.

Категории: Planet Drupal

Has Drupal 8 Usage Hit a Tipping Point?

Drupal News - 22 Януари, 2018 - 09:21

The following blog was written by Drupal Association Premium Technology Partner, Lingotek.

It wasn’t a question of if, but a question of when and the Drupal.org weekly usage statistics are showing it’s happening now. Usage of Lingotek’s Drupal 8 Module finally caught up to and exceeded that of Drupal 7. Is this the tipping point? Is the community finally making the switch to the latest Drupal module?

The Drupal.org Usage Statistics for Lingotek Translation provides information about the usage of the Lingotek Translation project--Lingotek - Inside Drupal 7 Module and the Lingotek - Inside Drupal 8 Module--with summaries across all versions and details for each release. It shows the week and the number of sites that reported using a given version of the project.

The usage figures reflect the number of sites using the project/item that week. The results can give an idea of how popular the different projects are and may help users choose modules and themes for their own sites. The figures are an indicator of which modules are being used. Note: Only Drupal websites using the Update Status module are included in the data.

In the past 6 months, the Drupal.org weekly statistics showed Drupal 7 usage was still going strong. There were twice as many users using the Drupal 7 version in April, May, June, July, August, and September. But starting in October, Drupal 8 usage began to tick upward. In the first week, only 269 reported using the D8 version. Then the momentum quickly shifted. By the second week of October, they were almost equal with 441 users of Drupal 7 and 420 using Drupal 8; they were a scant 19 users apart. Then came the tipping point.

In the third week of October, Drupal 8 usage overtook that of Drupal 7. In a huge turnaround, 772 reported using Drupal 8 when compared to only 447 using Drupal 7.

Since then, the gap narrowed somewhat, but regained a solid lead once again in early November with 894 D8 users and 416 using the D7 version. We’re predicting the lead is here to stay. The tipping point was inevitable.

The support is likely the result of the growing need for localized content. Multilingual web content is critical to engage a global audience that wants to search, shop, and buy in their own language. The Drupal 8 version, with its built in multilingual capability, makes it easier than ever to create content for a global audience. The module supports translation of any content and configuration, including:

  • Content entities - nodes, comments, messages, taxonomy terms and even paragraphs (including nested ones)
  • Configuration entities - fields, blocks, taxonomy vocabularies, views, fields, etc.
  • Configuration items - site name, system emails, etc.

The Lingotek - Inside Drupal Module is the only Drupal module to integrate a Translation Management System directly into Drupal, allowing the Drupal community to use professional-grade translation technologies (e.g. machine translation, translation memory, CAT tool) without ever leaving the Drupal environment. It is built on Drupal's standard multilingual modules (Locale, content translation, entity translation, internationalization, etc.) and helps Drupal administrators, agencies, and web marketers get a Drupal site multilingual-ready within minutes, instead of days.

Many Drupal users have strong opinions about which is better--Drupal 7 or Drupal 8, but one thing is clear: Drupal 8 is the future. The level of innovation and improved functionality available in each new release will be hard to ignore. These usage statistics reflect that the community has begun wholesale migration to Drupal 8 and that we’ve finally reached the tipping point.

Категории: Drupal News

PreviousNext: Managing Composer Github access with Personal Access Tokens

Planet Drupal - 22 Януари, 2018 - 06:20

All PreviousNext Drupal 8 projects are now managed using Composer. This is a powerful tool, and allows our projects to define both public and private modules or libraries, and their dependencies, and bring them all together.

 

However, a if you require public or private modules which are hosted on GitHub you may run into the API Rate Limits. In order to overcome this, it is recommended to add a GitHub personal access token to your composer configuration.

 

In this blog post, I'll show how you can do this in a secure and manageable way.

by Kim Pepper / 22 January 2018

It's common practice when you encounter a Drupal project to see the following snippet in a composer.json file:

"config": { "github-oauth": { "github.com": "XXXXXXXXXXXXXXXXXXXXXX" } },

What this means is, everyone is sharing a single account's personal access token. While this may be convenient, it's also a major security risk should the token accidentally be made public, or a team member leaves the organisation, and still has read/write access to your repositories.

A better approach, is to have each team member have their own personal access token configure locally. This ensures that individuals can only access repositories they have read permissions for, and once they leave your organisation they can no longer access any private dependencies.

Step 1: Create a personal access token

Go to https://github.com/settings/tokens and generate a new token.

You will need to specify all repo scopes.

Finally, hit Generate Token to create the token.

Copy this, as well need it in the next step.

Step 2: Configure Composer to use your personal access token

Run the following from the command line:

composer config -g github-oauth.github.com XXXXXXXXXXXXXXXXXXXXXXX

You're all set! From now on, composer will use your own individual personal access token which is stored in $HOME/.composer/auth.json

What about Automated Testing Environments?

Fortunately, composer also accepts an environment variable COMPOSER_AUTH with a JSON-formatted string as an argument. For example:

COMPOSER_AUTH='{"github-oauth": {"github.com": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"}}'

You can simply set this environment variable in your CI Environment (e.g. CircleCI, TravisCI, Jenkins) and have a personal access token specific to the CI environment.

Summary

By using Personal Access Tokens, you can now safely remove any tokens from the project's composer.json file, removing the risk this gets exposed. You can also know that by removing access for any ex-team members, they are no longer able to access your organisations repos using a token. Finally, in the event of a token being compromised, you have reduced the attack surface, and can more easily identify which user's token was used.

 

Tagged Composer, Security, Drupal Security
Категории: Planet Drupal

Agiledrop.com Blog: AGILEDROP: Drupal events in 1st quarter of the year

Planet Drupal - 22 Януари, 2018 - 04:40
We've stepped into a beginning of a new year, and there will be many events organised by the Drupal community in the first couple of months. We've made a list of Drupal camps and summits that you can attend in the first quarter of the year. Drupal events are bringing together Drupal developers, site builder, themers, end users and those interested in learning more about Drupal. We are attending Drupal events because of, sessions and collaborative discussions. DrupalCamp NJ 2018 United States, Princeton, NJ The campus of Princeton University 3. February 2018 09:00-18:00 This will be the 7th… READ MORE
Категории: Planet Drupal

fluffy.pro. Drupal Developer's blog: Monolog: namespaced logger?

Planet Drupal - 21 Януари, 2018 - 22:47
Using monolg library and monolog-cascade extension you can't configure the "namespaced" loggers. What does it mean? Imagine you have tons of classes and you need to log information from them into a log file. There is nothing special in this. Just define loggers with the needed handler(s) and instantiate them directly in a place where you want them to use with a help of monolog-cascade. It means in your monolog-cascade config file you have to define needed loggers in advance and you have to reference needed loggers by their names. But what if you need an additional logger (with absolutely different handlers/processors) for some of the classes? Will you go through all the classes and change logger names where you instantiate them? I think it doesn't look like a good idea when a small requirement (for instance, change the log file name for records from a bunch of classes) leads to edits in an application code. It's something that must be configurable and that's why I decided to write a tiny library called monolog-cascade-namespaced.
Read more »
Категории: Planet Drupal

DrupalEasy: Testing a local Drupal site emails with Lando and Mailhog

Planet Drupal - 21 Януари, 2018 - 20:29

Over the past few months, I've been evaluating three Docker-based local development environments trying to figure out which is best not only for me, but also for students of our long-form Managing Professional Drupal Development Workflows with Pantheon (next semester starts February 17) and Drupal Career Online (March 26) classes.

I've been test driving Docksal (actually, I've been using it for over a year), DDEV Community, and Lando (I'm a recovering Kalabox user) trying to figure out where the "sweet spot" is for flexibility, ease of use, documentation, Windows-compatibility (we routinely have students on Windows machines), performance, and some other criteria.

I recently stumbled upon a cool open source project (thanks Brian!) called Mailhog that makes it dead easy to test outgoing emails from a local development environment. While I tested it on Lando, both Docksal and DDEV both support Mailhog and have supporting documentation here and here

The general idea of Mailhog is that it acts as a local STMP server that by default, doesn't send emails to the addressed recipients. Rather, it includes a clean UI that allows the developer to view outgoing emails. 

Getting Mailhog up-and-running in an existing Lando site is quite easy. Simply add the following to your .lando.yml

 

proxy:
  mailhog:
    - mail.lemp.lndo.site
services:
  mailhog:
    type: mailhog
    hogfrom:
      - appserver


Then, run "lando rebuild". Caution should be used when using this command, as while most services retain their data during a rebuild, some may not. So far, I can confirm that my databases come through just fine. 

After rebuilding, you're just about done. When you run "lando start" the next time, you'll see a new set of URLs for the local Mailhog UI (you can also get this information via "lando info").

 

 

On your local Drupal site, if you're using the SMTP module or another SMTP-based sending solution, be sure to disable it:

 

 

Then, sending an email from a local contact form (screenshot shows a local copy of DrupalEasy.com):

 

 

Results in this in the Mailhog UI:

 

 

Then, if you want to "release" a message to its intended recipient, Mailhog provides you the option to do that as well via a button when viewing an email:

 

 

The button leads to an SMTP settings form:

 

 

Summarizing, regardless of if you're using Lando, Docksal, DDEV, or another local development stack, Mailhog is a great tool to help you test sending emails from your local development environments. 

While the screenshots in the blog post demonstrate setting up Mailhog with Lando, I can confirm that the process is just as easy with Docksal using the documentation, as I was able to configure it for a local client site in about 5 minutes.

For more information about using Mailhog with Lando, see the official documentation page.  
 

Категории: Planet Drupal

Matt Glaman: Drupal, Coffee, Burgers - A small world afterall

Planet Drupal - 20 Януари, 2018 - 19:00
Drupal, Coffee, Burgers - A small world afterall mglaman Sat, 01/20/2018 - 10:00 This year I joined a coffee exchange for some members of the Drupal community. I had known there was one floating around, but finally got signed up. Over the past two years, I have gotten more and more into coffee - being a coffee snob about roasts and learning brewing techniques. Last week we were paired up. And sent out some roasts.
Категории: Planet Drupal

Eelke Blok: Preparing your Drupal 8.3 site with Media for Drupal 8.4

Planet Drupal - 20 Януари, 2018 - 17:36

If you have the Media module for Drupal 8 installed, you need to remove it before you can upgrade to the latest core version (8.4). Unfortunately, there are a few gotchas involved with the process. This blog post is about getting rid of the old contrib Media module, so the site can be updated to Drupal 8.4 in a subsequent step. This is based on my personal experience. YMMV, as they say.

Категории: Planet Drupal

Drupal Console: Drupal Console 1.5.0

Planet Drupal - 20 Януари, 2018 - 05:20

Drupal Console 1.5.0 is out. The newest release contains bug fixes and one new command.

Категории: Planet Drupal

Acquia Developer Center Blog: Acquia Headless Lightning and Content API

Planet Drupal - 20 Януари, 2018 - 00:10

Acquia Headless Lightning provides an API-first back-end content repository that allows for easy ingestion by front-end applications.

Front-end developers requiring a headless or decoupled CMS have immediate access to a cloud-hosted content repository service for development, delivering, and production.

Tags: acquia drupal planet
Категории: Planet Drupal

Acro Media: Drupal Commerce 2: How to set up Product Attributes

Planet Drupal - 19 Януари, 2018 - 19:27

In this five part Acro Media Tech Talk video series, we use our Urban Hipster Commerce 2 demo site to show you how to set up a new product in Drupal Commerce 2, from start to finish. This is the first video in the series, How to set up Product Attributes.

If you're creating a whole new product type from scratch, the first thing you want to do is setup any product attributes that your product needs. For example, a shirt product type may have a number of sizes (small, medium, large) and colours available to choose from. Size and colour are both product attributes. As a site administrator, you'll use the attributes to configure your product variations. As a customer, your'll use the attributes to pick the exact product that you want to purchase.

Next week we'll post part 2: Product Attributes using Rendered Fields

Its important to note that this video was recorded before the official 2.0 release of Drupal Commerce and so you may see a few small differences between this video and the official release now available.

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 used in this video

Категории: Planet Drupal