Drupal News

Good SEO practices for Drupal website?

Mediacurrent: Power your Drupal 8 Project with Docksal

  • 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.
     

    20 hours 16 min ago

Weekly Drupal beginner questions thread

Amazee Labs: What the hell is GraphQL?

  • 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.

    1 day 9 min ago

How to control layout of content fields and view on a taxonomy term page?

  • Hi Everyone.

    I have a Drupal 8 site that is using a sub-theme of the Bootstrap theme.

    I would like to customize the layout of the content a taxonomy. But I cannot figure out how to change the placement of the taxonomy view results. It always displays after all the content fields.

    Is there any way to make the view available as a field in Display Suite? Or where is it it controlled in the templates?

    I'd like something like this:

    [Top Fields]

    [Taxonomy View Results]

    [Bottom Fields]

    Thanks!

    submitted by /u/theshannons
    [link] [comments]

    1 day 3 hours ago

PreviousNext: Managing Composer Github access with Personal Access Tokens

  • 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

    1 day 7 hours ago

How to set browsercaching for fonts loaded in my template?

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

  • 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 »

    1 day 14 hours ago

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

  • 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.  
     

    1 day 16 hours ago

Pages