agoradesign: Why it is a bad idea to do function calls on injected services during instantiation in Drupal 8

Planet Drupal - Fri, 29/04/2016 - 18:17
Today I was tracking down a strange issue with a form submission and validation, which finally turned out to be the consequence of an unobvious wrong function call inside a class constructor.
Categories: Elsewhere

Acquia Developer Center Blog: BigPipe in Drupal: Bigger, Better Performance for Free

Planet Drupal - Fri, 29/04/2016 - 17:05

Wim Leers, Senior Software Engineer in the Acquia Office of the CTO (aka “OCTO”), has been busy in the last few years making Drupal 8 amazing! His contributions include working with Fabian Franz on aspects of Drupal’s new caching and rendering systems to make Drupal 8 performant. Today’s podcast is a conversation he and I had about who he is and what he’s been up to following our own collaboration preparing my own post on BigPipe.

Below is a transcript of parts of the conversation you can hear in full in the audio and video versions of this podcast. In the audio and video versions, we also touch on:

  • aspects of contribution and the professionalization of contribution in open source, especially in the light of Wim being paid by Acquia to be a full-time contributor to Drupal.
  • how even small contributions, like a well-written bug report, add up to making a big difference ... and my daughter’s commit credit in Drupal 8 :-)
  • Hierarchical Select module
  • Many hands making light work in open source
  • Plus everything below about caching, BigPipe, performance, and more in the transcript!
Learn more about BigPipe in Drupal 8
Interview video - 41 minutes

BigPipe in a nutshell: “What matters in the end is not the number of requests, but how fast it actually feels for the end-user because that's what you care about and that's where BigPipe makes a huge difference." - Wim Leers

Guest dossier
  • Name: Wim Leers
  • Work affiliation: Senior Software Engineer, Acquia Office of the CTO
  • Drupal.org: wim-leers
  • Twitter: @wimleers
  • LinkedIn: Wim Leers
  • GitHub: wimleers
  • Blog/Website: http://wimleers.com/ - "Hello! My name is Wim and I’m interested in WPO, Drupal and data mining. I’ve worked on Facebook’s Site Speed team. And I love llamas."
  • Drupal/FOSS role: Drupal core contributor
  • 1st version of Drupal: Drupal 5 beta

Partial Transcript
How did you discover Drupal?

Wim: I was going to build this website – or I needed to build a website but I was looking for a way that will allow me to set up a website that was maintainable, that didn’t require too much digging around in code, and that looks like it would be a good choice for the long run. I looked at WordPress, at Joomla, at Drupal, and I think a few others maybe, but Drupal stood above the rest like it was the obvious better choice back then, I believe. It was the time of Drupal 5.0 being in active beta. 4.7 was I think the active version. I never used that. I jumped straight to the beta because it looked much better.

jam: I had the joy of installing 4.6 and 4.7. The good old days. Wow. Drupal 5.0 was such a massive leap at that time.

Why did you stick with it now for nine years?

Wim: Yes. I got kind of rolled deeper into the community as I think is the story for many of us. That was 2006 - the end of 2006. It was the Christmas break at my first year of University. I was trying to actually do less work on this Open-source project that I was working on before by building a website so that others could maintain it. So it’s kind of funny that I used Drupal 4 and other Open-source projects. In doing so, I needed a few things to be built myself in order for this website to really function well. So I started working on that and then I noticed - back then it was very easy to get an account that allows you to create a project, a module on Drupal.org. Right now, we have to go through a quite tough review process or back then at least, there was not review process. It was just if they saw you on IRC quite a few times, “Yes, sure, you can get an account.”

jam: The pendulum swings back and forth on that one.

Wim: I know.

jam: We’ve been in a fairly Draconian period recently.

The path to becoming a performance expert

... from doing something Open-sourcey to choosing Drupal because it seemed the best, to then getting annoyed by sites being slow and then looking at how Drupal could be faster for a Bachelor thesis, to them better understanding it through my Master thesis and at Facebook and then eventually, I ended up at Acquia. It’s a path that has definitely been big, mutually influenced by Drupal.

Wim: Yes. I don't know the details. At any case, back then it was very easy. That’s all that matters. That’s why I managed to publish a module very early on and that started to get quite a few users and get more users and I found it interesting that my module that was growing in feature sets and getting more and more users on the hundreds of websites using it. That was so fascinating to me that I kept working on it and improving it more. Then, I got freelance work doing that in the summer so instead of having a crappy student job for the summer, I managed to do freelance work while further developing this module. So that led to more freelance development and that led to my bachelor thesis being about Drupal and CDNs so performance in general, but then a few years later led to my master thesis being about Drupal, not very strictly Drupal but again performance. Performance plus data mining to better understand why a site is slow in certain scenarios. That basically led to Drupal being a significant part or significant presence during my entire period of studying computer science.

jam: What was that first module?

Wim: Hierarchical select.

jam: Picking up at your Master's thesis, talk about your work in performance and where that’s led you.

Wim: Yes. It’s quite interesting to see how Drupal allowed me to do a bachelor’s thesis on Drupal plus CDN to make Drupal faster. Then I wanted to better understand in which scenarios a site could still be slow so for example when accessed from a certain region even while using a CDM or when using a particular browser or maybe a particular piece of JavaScript was slow in a particular browser. Those kind of things, figuring that that that is quite difficult. People complain it’s slow, but they don’t really explain why, or it’s normal, that’s regular, and users if you will – non-technical people will just complain and say it’s broken or slow but will not be able to pinpoint that’s the exact reason.

There can be so many reasons and it can be very difficult to simulate that, to actually see it happen in front of you as a developer. So for my Master’s thesis, I worked on data mining and collecting performance information, performance data. So applying data mining on the performance data allowed me to automatically figure out which situations, which combinations were slow. So then it will allow you to see which exact scenarios are also the things that are most commonly slow. Therefore, our most worth attention from a person fixing them to look into those problems. From that point of view ... And I published that Master thesis and a series of blog posts about that ... Somehow, a person at Facebook discovered that or stumbled upon that and he reached out to me. He was from the – what was called back then the Site Speed Team. I first, I literally didn't believe it that there was a person from Facebook contacting me. I was looking at the email headers to figure out if it was spoofed or something.

jam: Somebody’s pranking you.

Wim: Yes, yes. Exactly. That's what I thought. So it looked like it checked out. I was saying, “Okay. Let’s send a reply, I guess.” Then, two days later, I think I had an informal Skype call with that person and it looked like they were at Facebook office or something, Silicon-Valley-like in his background.

jam: Because you could tell.

Wim: Well, it looked like he at least wasn't in a cellar somewhere pranking me. It was somewhat legit looking. Yes, then I had phone interviews and I think I actually was asked in the beginning even to do a full-time position but I was still studying so I asked if it was possible to do an internship instead and so that’s how I ended up doing an internship there while continuing to work on that same data mining and performance data project piece of software that I started for my Master thesis. They’ve led me to an interesting place so from doing something Open-sourcey to choosing Drupal because it seemed the best, to then getting annoyed by sites being slow and then looking at how Drupal could be faster for a Bachelor thesis, to them better understanding it through my Master thesis and at Facebook and then eventually, I ended up at Acquia. It’s a path that has definitely been big, mutually influenced by Drupal.

On to making Drupal faster

jam: Your biggest contribution to Drupal 8 has also been in the performance area. Would you like to talk about caching and cache tags and BigPipe?

Wim: Sure. I've now been working on Drupal and working at Acquia full-time for about three and a half years, close to four. The first part of that was Spark, so authoring experience. That's a WYSIWYG editing CKEditor, the toolbar to it to some extent – those kinds of things.

jam: You came in during the Spark initiative?

Cache Tags, Render Caching, Cache Invalidation

Wim: Yes. So that was 2012. Then, for the last one and a half to two years probably, I’ve been working pretty much entirely on performance so making Drupal faster. A big portion of what was looking to be a good candidate for making Drupal 8 significantly faster was cache tags. That was a concept that was added a long time ago, I think even in 2011 or so. But it wasn’t really being used in many places because it was only being used in a handful of places across Drupal Core. For example, entities. So nodes, terms, users did not use them at all even though they seemed like a prime candidate. At the same time we had the concept of render caching which is basically we’re rendering something. Render caching allows you to cache the fragment of the page that is being rendered so that you don’t have to do all of the work of getting the data and then turning that into HTML in the theme system, which can take some time. The point was to use render caching in more places, the most expensive places, for example rendering entities such as nodes and users. That actually made for an interesting overlap between render caching and cache tags because when you have rendered something, you want that data to be updated as soon as the data it depends upon is changed. For example, if you change a node title, you want the render cached nodes to be updated. Otherwise, we’re looking at the old thing.

jam: Right. Now, I think that just about every one who is listening to this will know this already. But what you’re actually describing is one of the harder problems in computer science. How do you cache something and how do you find out in a cheap way when that cache should be cleared and you have new data and how do you avoid having stale stuff showing up as much as possible?

Wim: Yes. So the saying in computer science goes, “There are two hard problems in computer science, naming things and caching,” or “cache invalidation” I should say. To be clear, I did not invent cache tags. That was something that very smart people came up a long time before me. I had the ability also because I’m working on Drupal core full time to bring cache tags to many places in Drupal core and so that it’s an inherent part almost of many parts of Drupal core. So I made it sure that for example every single entity, entity type, so whether it’s config entities or nodes or terms, anything that has proper test coverage and whenever those things change, the corresponding cache tag is invalidated which then allows us to have this rendered caches and any other cache to be updated automatically, to be invalidated automatically. Indeed, it’s just a small bit of metadata that is associated with whatever is cached whether it’s rendered or computed or whatever it is. That allows us to very efficiently update those things. Cache tags everywhere makes sure that we can reliably invalidate things and reliably have things update when they should which was an impossible problem to solve in Drupal 7 and before because we didn’t have such a concept.

jam: And “performantly” as well, if that’s a word.

Wim: Yes, that’s a word. Yes.

jam: Without huge cost on my server.

Wim: Yes. There is always some cost because there is something additional that needs to happen. You’d have to retrieve something from the cache then check if the cache tags that are associated with it have been invalidated in the meantime. That’s the additional cost. But it’s a pretty small cost.

jam: That’s a much smaller cost than re-rendering the entire page.

Wim: Yes. Every single time, which is what happened in Drupal 7 before. Actually, to be honest, in most other systems. So most other CMSs on Frameworks or what you quite often see as a solution which is not really a solution is to just assume it’s okay to cache something for five or for ten minutes. But that means that if you as a blogger for example and you fix a typo, your broken title, your wrong title with still that typo in there is going to be there for another 5-10 minutes. So your changes are not showing up right away which is a very annoying, disconcerting experience.

jam: Sure. It’s a kludge. It’s a hack. I mean Cron versus Poor Man’s Cron comes to mind ...

Wim: Yes.

BigPipe, Cache Context, Max Age and the "Dynamic-ness" of things

jam: Yes. So I’m going to imbed two recent webinar videos that you’ve done on this podcast page [See links above!]. If anyone who’s listening to the podcast, in real time we’re speaking in early 2016, we recently did two webinars at Acquia about a thing called BigPipe and BigPipe is essentially the next step in this conversation. I’m going to imbed those videos and when slides are also going to be available and I’m going to link to all of the stuff that we’re talking about. We’ve got this fantastic caching architecture in place and working in Drupal 8. What is BigPipe and tell us about the magic that it does with all of this stuff?

Wim: Yes. First off, actually the two webinars you were mentioning, the first one is actually a subset of the second one so I would recommend to only link to the second one which concludes everything. So then people have one coherent story. That’s probably going to be useful to them. [Check out all the links above in this post!]

jam: All right. Okay. Now, BigPipe.

Wim: Yes. So far we talked about cache tags and rendered caching. But cache tags are not the only bit of cacheability metadata that we have in Drupal 8. We have two more. Those three things together actually allow us to know comprehensively and with complete certainty what things it depends on, what it varies by its own. So cache tags are for declaring dependencies on data, for example on entities so that we know when something has changed. But we also have cache context which allows us to define which context something depends on, what it varies by. For example, if jam has user role A and I have user role B and we have access to different things, then the outputs, the rendered HTML, should also be different. Or maybe it says, “Hi jam” or “Hi Wim,” then the output needs to vary by user. So those kinds of variations are what cache contexts are about. So cache tags and context and then there is a third called “max-age” to describe something that expires after a certain period of time. That’s less commonly necessary, max-age zero means that something is absolutely not cacheable so it needs to be requested or updated every single time. But it’s useful for things like maybe temperature data that is okay to cache for – that remains the same across say one minute or two minutes or 10 minutes.

So those three things together allow us then to know the "dynamicness" of every part of the page. In Drupal usually we have blocks. Most people build Drupal sites using the block system. So when blocks are appearing in different parts of the page, very often, some blocks are personalized. For example, the menu block below will only show menu links that are accessible to the current user. Maybe there is a shopping cart, maybe there is a “Hi, jam. Your friends have just sent you so many messages.” Something like that. So those kinds of things are dynamic. Then, usually there’s also parts of the page--and it’s not limited to blocks by the way but that’s just an easy way to think about it. Usually, you have blocks that are the same across users and usually even across everything. So for example, a menu of the footer or a search form like a search block.

jam: Or the main content.

Wim: The main content, yes. So all of those are actually cacheable across users like if it’s rendered once, we can reuse it for jam, for me, for anybody else. Thanks to those cacheability metadata, so tags, context, and max-age, we know that a given block is going to vary that much. It’s going to be stale at that point when certain entities invalidate it. For example, when jam changes his user name into something like a “Llama” for example.

jam: Just to pick a random word.

BigPipe and Perceived Performance

Wim: Yes. So the fact that we know for any given block what things it depends on, makes us able to know when something is very dynamic and when it’s not. So that allows us to pull out that part of the page, delay rendering it so that we can send the entire page minus the personalized parts first and then send the personalized parts like the “Hi, jam” blog, the shopping carts, those kinds of things, we can send those later. So the difference on this, the perceived performance. How fast a site feels, how fast a site looks and actually just how fast a site shows up. It makes it so that the sites show up instantaneously regardless of user, regardless of the complexity of those dynamic parts of the page because the parts that are the same--which is usually significant parts of a page--those show up immediately. They can be sent right away extremely fast, which means ...

jam: Usually, when I'm browsing that's the stuff that I actually care about. That’s the article I want to read. That’s the photo I want to see because that's the point of the page and that’s what everybody's getting already and that’s usually pre-cached, ready to go.

Wim: Yes, exactly.

jam: Barely or not at all dynamic.

Wim: Yes, exactly. Basically, the crucial parts of the page are usually not personalized and in that case we can make that available so, so much faster because Drupal and just about every other system out there, what they do currently is they render everything and only then once every single detail is rendered, then they send it to the end user. That makes it so that you have to wait even for the stupid, smaller things that are maybe not that important to you. Then you have BigPipe which, because of that metadata, it's just a module you can install; you don't have to configure anything. Thanks to that metadata, it can figure out which parts are too dynamic or are very dynamic or personalized. It can delay the rendering of that. Send the majority of the page first and then send the dynamic parts later. That makes for a much, much faster experience. We're trying to get that into Drupal 8.1 and it looks like many people are happy with that [BigPipe is an experimental core module in Drupal 8.1!]. It will not be enabled by default. It will even be marked as an experimental module at first because we want to make sure that it works in even the most extreme cases. So it's better to first have it experimental so sites can opt into it so we can get more experience and then hopefully in 8.2 we can make it a non-experimental module. That will be a great performance boost with no efforts basically for every site.

jam: So cache tags rendering, cache context, all of that is in Drupal 8 and on always by default and I don’t have to think about it. I’m just benefitting from your work.

Wim: Yes. Yes.

jam: As of the beginning of February 2016, if I want to take advantage of this delivery mechanism which builds on techniques, that’s called the BigPipe module?

Wim: Yes.

jam: And as of Drupal 8.1 or 2 or probably you're moving that into Core as well. [In core as of Drupal 8.1!]

Wim: Yes.

jam: Wow. Exciting.

Wim: Yes. It is very exciting. Actually, this is actually a technique not invented by us. I should say by the way that it was not just me who worked on this. Fabian Franz also from Germany by the way.

Thank you, Fabian! Thank you, Facebook!

jam: Thank you, Fabian.

Wim: Yes, thank you, Fabian. He did a great amount of work. He did the initial pioneering, the initial proof of concept. I worked a lot with him to actually make it happen and get it to a more final state, but he did a lot of the work. Even Fabian didn’t invent this. It’s a technique pioneered by Facebook. They invented or published about this some years ago. I forget the exact ...

jam: No, no, no. When you were an intern there…

Wim: No, no, no.

jam: You used all the documentation and you snuck it on to a photocopier and smuggled it out.

Wim: Then, I probably would be in trouble. No.

jam: Wim Leers, master software spy!

Wim: That’s actually a pretty cool title. I should try to get that to happen. Yes, they pioneered it. The whole point is that currently, or in the classical way of delivering webpages, what happens is first you do a request, then the server does work, you wait, you wait, you wait. You have a blank screen you’re looking at. Then the server sends a bunch of things. Then the client – the browser has to fetch all the CSS, the JavaScript, the images and can only then start rendering. So it's a sequential process and BigPipe allows us to make that a more parallel process where the browser immediately gets a response, not with everything, but with probably the majority if not all of the CSS and JavaScript and images so it can start downloading and rendering that already. Then dynamic parts show up. That’s the reason it’s called BigPipe in the sense that it becomes a bigger pipe along which to send things because things are happening in parallel instead of in sequence.

jam: All right. Wim, this is so interesting. I wrote a small post about this and I did some research into this and every new thing I find out about it, it's just so exciting. It's such a great bit of technology. Thank you Fabian from Tag1 Consulting for all of your work. Fabian Franz. Thank you Wim for your amazing work on this. I am going to link to everything that we’ve been talking about and I’m going to embed the webinar videos where people can learn a lot more about the technical nitty-gritty of all this [see links above!]. Wim, I guess you're working on getting this into Core now, right? That’s pretty much your job right now?

Wim: No, I’m working on other things as well but that is one of the things that I’m going to focus on in the next few weeks. Yes.

jam: Fantastic.

Wim: I’m very happy. I wanted to get this into Drupal ever since I read about it on Facebook’s engineering blog. It’s finally to the point where it already works. You can download it for 8.0 if you’re running Drupal 8 already. It will hopefully be in 8.1. It’s great that Open-source is then able to get this awesome technique which doesn't require any infrastructure which usually is the case for making things faster. You usually need a lot of infrastructure and money and servers. It’s just a more efficient way of delivering HTML and getting the browsers around the stuff. I'm very excited that it’s going to be available in an Open-source project like Drupal. As far as I know, nothing else has something like this so pretty cool.

jam: I'm working through the title for this podcast in my mind . It's got to be something like “Bigger, Better Performance for Free,” right? Actually, the point that you only just touched on now that I hadn’t thought of this morning of course was you don’t need massive parallel server infrastructure and all this stuff to get things really, really cracking. In this case, you get like a ton more bang for your buck out of Drupal now, just with the all of this default stuff that’s…

Wim: Yes, because usually people measure things in terms of requests per second. That is actually going to be identical with BigPipe. The entire duration of a request is going to be the same. It's just that we send useful information much earlier and then continue to send additional things, the dynamic parts later. So if you look at those traditional things to measure which are easy to measure but don't actually give you a good idea of how fast a site is, because what matters in the end is not the number of requests but how fast it actually feels for the end-user because that's what you care about and that's where BigPipe makes a huge difference.

jam: Wim, thank you for taking the time to talk with me this morning. It's been so great. It’s so interesting and thanks for everything that you've been doing. It’s great, and keep up the good work.

Wim: Thank you. Yes. Thanks for having me, and maybe see you next time and have a great day.

Podcast series: Drupal 8Skill Level: BeginnerIntermediateAdvanced
Categories: Elsewhere

qed42.com: Pune Drupal Group Meetup, April 2016

Planet Drupal - Fri, 29/04/2016 - 16:59
Pune Drupal Group Meetup, April 2016 Body

The monthly Pune Drupal Group Meetup for April was hosted by QED42. The second PDG meetup to take place in the month of April, You would assume meeting this often would get tiring for other people but not us! We Drupalers love a good catchup session.

The first session was kicked off by Prashant and Rahul, Interns at QED42 and they spoke on, "Our experience with Drupal." They explained about their journey as new comers to Drupal, from the lenses of both CMS and the community. Their confusion at the beginning, the new tech and softwares they have learned, their experience at Drupalcon Asia and their love for the community. A really enjoyable session peppered with ernest observations and cute cat pictures and a brilliant first time attempt. Bravo boys!


The second session was taken by Arjun Kumar of QED42 on,"Introduction to CMI." With a brief on CMI and the difference from the features land, he concluded with a demo.


After a short discussion on the probable date and location for Pune Drupal Camp we broke off for BOF sessions,with Navneet leading the discussion on Acquia certifications and further discussions on CMI.

With 20 people in attendence we concluded the PDG april meetup with delicious Pahadi Sandwiches in our tummy. Have a great weekend and see you soon!


aurelia.bhoy Fri, 04/29/2016 - 20:29
Categories: Elsewhere

InternetDevels: The Best Drupal eCommerce Websites

Planet Drupal - Fri, 29/04/2016 - 15:14

Nowadays, lots of companies can benefit from having their own ecommerce sites. It allows brands to sell anything from physical products up to consultations and appointments. In one of our previous blogs, we outlined the main points as to why Drupal is the one stupendous solution for your ecommerce website. Today, we’ll take you on one of the most enthralling journeys and show you a variety of outstanding examples of ecommerce websites that incorporate Drupal. So come aboard!

Read more
Categories: Elsewhere

Mediacurrent: Friday 5: 5 Ways to Connect with Mediacurrent at DrupalCon

Planet Drupal - Fri, 29/04/2016 - 14:55

We hope you've had a great week!

Thanks for joining us for Episode 7 of the Mediacurrent Friday. Planning on attending DrupalCon next month in New Orleans? If so, you won't want to miss Marketing Director Shellie Hutchens give you 5 Ways to Connect with Mediacurrent at DrupalCon.

Categories: Elsewhere

INsReady: Case Study: Launching Inventory Control System with Commerce 8.x-2.0-alpha4 on Drupal 8.1

Planet Drupal - Fri, 29/04/2016 - 11:12

One of our clients recently became interested in taking their inventory control system to a next level. They were offered a solution to go with an out of shelf ERP system. However, it's a requirement that the client has to change the business operation in order to meet the workflow and implicit technical requirements of the ERP system. Moreover, the solution was lack of integration with existing websites and very popular 3rd party mobile platform like WeChat in China (WeChat had 697 million MAUs at the end of December, 2015).

We were brought in to the project to offer an alternative solution. So, we started with reviewing the scale of the business first:

  • One young fashion brand
  • 4 physical retail stores with the 5th one opening within 2 months
  • 1 Magento powered eCommerce site
  • Retail stores, warehouses and manufacturing factory in different cities and countries, such as Shanghai and Hongkong
  • One 4 years old inventory control system which required the manual labor to enter the orders made by Magento
  • 60 products with 8000 SKUs
  • 500 product attributes among Style, Color and Size

We set our goals below for the first phase of the project:

  • Make data complete and rich; this is the foundation for any future analytics and predictions of manufacture and sales. In short: Full stock movement tracking cross the whole business.
  • Centralized stock management for physical stores as well as online Mangeto store. In other words, we need a integration between the inventory control system and Magento stock
  • Offline-Friendly Point of Sales system for physical stores
  • Bulk operation for managing stocks at warehouses
  • Easy but dynamic reporting for different roles at operation to see stock as well as movements
  • High availability or redundancy

We quickly decided to use Drupal 8 (at the time, D8.0.2 was just released) with the understanding that we might need to do a lot of develop within Commerce 2.x. After 3 months, we have met all of our goals, and now we are lunching the project with Commerce 8.x-2.0-alpha4 on Drupal 8.1. In the past 3 months, we have contributed below back to the open source communities:

Below are some screenshots from the project:

(Offline-friendly dedicate page to bulk manage inventory)

(Stock movement page built with Views)

Special thanks to bojanz at CommerceGuys for the great work on Commerce on Drupal 8

Files:  Inventory Control System.png Screenshot from 2016-04-29 16-58-25.pngTag: Drupal PlanetCommerceInventory Control
Categories: Elsewhere

Drupal Commerce: Commerce 2.0-alpha4 released

Planet Drupal - Fri, 29/04/2016 - 00:30

Almost two months and seven thousand lines of code later, here's Commerce 2.0-alpha4. This release brings checkout and revamped product attributes. We've also added upgrade path APIs in preparation for beta1. Meanwhile, we helped push Drupal 8.1 out the door and fixed many Inline Entity Form bugs.

The new checkout flow configuration form.

Reminder: Commerce 2.x alphas are NOT production ready. No upgrade path is provided between alphas. A full reinstall is needed each time.

Read on to find out what's new...

Categories: Elsewhere

Hook 42: DrupalCon New Orleans - We're Excited! How About You?

Planet Drupal - Thu, 28/04/2016 - 23:10
Thursday, April 28, 2016 We're all super excited to be heading to the Big Easy soon for DrupalCon!

We wanted to share some of the sessions and attractions we are looking forward to the most. Hope we see all of you there to share ideas, have a drink, and laissez les bon temps rouler!

We polled our team (and some friends) to find out what everyone is the most excited about - the general theme was food, but you can read all the silly and serious details below.

First the "serious" business question - What session, BoF, training or speaker are you most excited about? Aimee:

I am excited to hear from Dave Reid and how he is handling module ownership of so many widely used modules. Also, this year has a dedicated Project Management track. The Drupal community needs a healthy influx of the business arts to help strengthen its enterprise-grade use. Drupal isn't just the technology, but the people and process used to implement and support it!


There are so many scheduled activities that look great, it's hard to pick just one. One that I'm hoping to get a lot out of is the "Teaching Drupal to Kids and Teens" BoF on Tuesday at 1pm. Having 10 and 13 year old kids, I plan to come home and use them as guinea pigs for the tips we share in that BoF.


The session I am most excited about is - Documentation is getting an Overhaul or Using Paragraphs to Weave a Beautiful Content Tapestry


It's my first time there, so I am going in with an open mind and no expectations. Generally just looking forward to a great experience.


Drupal Commerce


I'm not sure if I have a single session or training I am most excited about, I've got a lot of UX sessions on my schedule at the moment. I am excited to know a lot more about Drupal this year compared to my first trip to DrupalCon last year - so all of it will probably make a bit more sense. Can I be excited about the closing ceremony and finding out where it will be next year?


I still have about three sessions chosen per hour, so I'll have to narrow it down. But looking forward Sara Wachter-Boettcher's keynote and sprinting on Friday.

Kristin (K2):

I'm most excited about mentoring on Friday - come join us! I'm also excited about the in between times when Lindsay and I get to say "Wow that was great!" or "What the heck were they on about?"


I'm most excited about the "Hallway track"


The sessions I am most exited about are - "Drupal 8's multilingual APIs -- integrate with all the things" by Gábor Hojtsy, "Automated javascript testing: where we are and what we actually want" by dawehner
 and "Watch the Hacker Hack" by mlhess and greggles


All the front end sessions. I'm excited to learn as much as possible and put that knowledge to good use.


I'm excited for the "Get off the island! But build bridges back" session! It's focus is building an independent PHP library with the intent of using it in Drupal 7 or 8 or any PHP project! I think it's important to be able to keep the bridges open with outside ideas that we can merge with Drupal so it stays fresh with the latest web development!


I'm looking forward to “Must be Intuitive and Easy to Use”: How to Solidify Vague Requirements and Establish Unknown User Needs.


Now, on to the "fun" part - What are you most excited to see or do in New Orleans?


Wow, so many! I'm excited about our team dinner on a steamboat, the ghost tour, and walking around the French Quarter to discover what there makes "les bons temps rouler"!


All of the food! I've heard amazing things about the food in New Orleans so I'm looking forward to beignets, jambalaya, gumbo, and po-boys. I normally try to eat pretty healthfully but I've given myself a pass to eat whatever I'd like that week. :)


I very excited about geocaching in the Lower Garden District. I also like to drink beer...anywhere.


Looking forward to some American food, and getting to spend time the with rest of the team!


Preservation Hall Jazz Band!


I think I am most excited about the Steamboat Natchez Dinner Cruise! Maybe getting to explore the French Quarter and Garden District, or eating too much food, or visiting New Orleans in general, because I've always wanted to go!


Crawfish! And a beignet or more...

Kristin (K2):

I am most excited about beignets from the Cafe Du Monde! I'm most excited about just walking around enjoying the beautiful architecture and music. And beignets. And poor-boys. And food. All the food.


Hallway track


Hanging out with people I haven't seen in awhile :)




I don't know much about New Orleans, I'm just excited to travel. It would be fun to see a Pelican so I can figure out why they named their NBA team after them, and mostly I just want to eat!


I have some family roots there, so there is a lot of personal excitement for me.



Can't wait to share a beignet, a conversation or maybe even a ghost sighting with you all!



Hook 42 Topics:
Categories: Elsewhere

Mediacurrent: 20 Things You Must Know Before Approaching A Web Agency

Planet Drupal - Thu, 28/04/2016 - 21:27

Before you engage with a new agency to build or redesign your site, there are some key data points you should know about your existing site.

Categories: Elsewhere

Drupal core announcements: Drupal 8 core release window on Wednesday, May 04, 2016

Planet Drupal - Thu, 28/04/2016 - 20:43
Start:  2016-05-03 12:00 - 2016-05-05 12:00 UTC Organizers:  xjm catch Event type:  Online meeting (eg. IRC meeting)

The monthly core patch (bug fix) release window is this Wednesday, May 04. Drupal 8.1.1 will be released with dozens of fixes for Drupal 8. There will be no Drupal 7 bugfix release this month.

To ensure a reliable release window for the patch release, there will be a Drupal 8.1.x commit freeze from 12:00 UTC Tuesday to 12:00 UTC Thursday. Now is a good time to update your development/staging servers to the latest 8.1.x-dev code and help us catch any regressions in advance. If you do find any regressions, please report them in the issue queue. Thanks!

To see all of the latest changes that will be included in the release, see the 8.1.x commit log.

Other upcoming core release windows after this week include:

  • Wednesday, May 18 (security release window)
  • Wednesday, June 01 (patch release window)
  • Wednesday, October 5 (scheduled minor release)

Drupal 6 is end-of-life and will not receive further releases.

For more information on Drupal core release windows, see the documentation on release timing and security releases, as well as the Drupal core release cycle overview.

Categories: Elsewhere

Dries Buytaert: How is Drupal 8 doing?

Planet Drupal - Thu, 28/04/2016 - 20:31

The one big question I get asked over and over these days is: "How is Drupal 8 doing?". It's understandable. Drupal 8 is the first new version of Drupal in five years and represents a significant rethinking of Drupal.

So how is Drupal 8 doing? With less than half a year since Drupal 8 was released, I'm happy to answer: outstanding!

As of late March, Drupal.org counted over 60,000 Drupal 8 sites. Looking back at the first four months of Drupal 7, about 30,000 sites had been counted. In other words, Drupal 8 is being adopted twice as fast as Drupal 7 had been in its first four months following the release.

As we near the six-month mark since releasing Drupal 8, the question "How is Drupal 8 doing?" takes on more urgency for the Drupal community with a stake in its success. For the answer, I can turn to years of experience and say while the number of new Drupal projects typically slows down in the year leading up to the release of a new version; adoption of the newest version takes up to a full year before we see the number of new projects really take off.

Drupal 8 is the middle of an interesting point in its adoption cycle. This is the phase where customers are looking for budgets to pay for migrations. This is the time when people focus on learning Drupal 8 and its new features. This is when the modules that extend and enhance Drupal need to be ported to Drupal 8; and this is the time when Drupal shops and builders are deep in the three to six month sales cycle it takes to sell Drupal 8 projects. This is often a phase of uncertainty but all of this is happening now, and every day there is less and less uncertainty. Based on my past experience, I am confident that Drupal 8 will be adopted at "full-force" by the end of 2016.

A few weeks ago I launched the Drupal 2016 product survey to take pulse of the Drupal community. I plan to talk about the survey results in my DrupalCon keynote in New Orleans on May 10th but in light of this blog post I felt the results to one of the questions is worth sharing and commenting on sooner:

Over 1,800 people have answered that question so far. People were allowed to pick up to 3 answers for the single question from a list of answers. As you can see in the graph, the top two reasons people say they haven't upgraded to Drupal 8 yet are (1) the fact that they are waiting for contributed modules to become available and (2) they are still learning Drupal 8. The results from the survey confirm what we see every release of Drupal; it takes time for the ecosystem, both the technology and the people, to come along.

Fortunately, many of the most important modules, such as Rules, Pathauto, Metatag, Field Collection, Token, Panels, Services, and Workbench Moderation, have already been ported and tested for Drupal 8. Combined with the fact that many important modules, like Views and CKEditor, moved to core, I believe we are getting really close to being able to build most websites with Drupal 8.

The second reason people cited for not jumping onto Drupal 8 yet was that they are still learning Drupal 8. One of the great strengths of Drupal has long been the willingness of the community to share its knowledge and teach others how to work with Drupal. We need to stay committed to educating builders and developers who are new to Drupal 8, and DrupalCon New Orleans is an excellent opportunity to share expertise and learn about Drupal 8.

What is most exciting to me is that less than 3% answered that they plan to move off Drupal altogether, and therefore won't upgrade at all. Non-response bias aside, that is an incredible number as it means the vast majority of Drupal users plan to eventually upgrade.

Yes, Drupal 8 is a significant rethinking of Drupal from the version we all knew and loved for so long. It will take time for the Drupal community to understand Drupal's new design and capabilities and how to harness that power but I am confident Drupal 8 is the right technology at the right time, and the adoption numbers so far back that up. Expect Drupal 8 adoption to start accelerating.

Categories: Elsewhere

Axelerant Blog: Agile Drupal Support Teams Like Ours Are Self-Organized

Planet Drupal - Thu, 28/04/2016 - 20:00

What do the best agile Drupal support teams, plasma laser systems,

and flocks of birds have in common? 

 They’re self-organizing. And you’ve got to see the big picture to get it. I’ll show you.

First off, I suppose should tell you that I’ve been studying self-organization as a scientific discipline for the last decade. It’s a good thing I like this stuff, right? During this 10 year journey I’ve jumped into various subjects: plasma laser systems, educational technology, robotics and computer simulations, Drupal project management, and of course: organizational dynamics.

What I found is that when you get the depths of each of these topics, it’s too easy to see the similarities. Each allows for a systemic view—the big picture.

But before we get in too deep here, let’s cover some basics. A system is a collection of interacting components, each having its purpose. The what doesn’t matter; it’s about the how. It could be plasma particles in laser-plasma interactions, it could be a team working on a project, it could be functional groups interacting to form an organization, it could be a flock of birds flying together constantly maintaining distance. The list is endless.

What we’re talking about here are fixed systems. System that:

(A) Can produce the same outcomes in different ways in the same environment and different results in the same and different environments

(B) Can not only learn and adopt but also create

Agile Drupal support teams are great examples.

They are in effect flexible, scaleable systems that have to naturally adapt to function in a changing environment or perform within a constant environment. Agile facilitates evolution and adaption, meaning fully-agile Drupal teams can do this.

So how does this science work with agile Drupal teams?

Agility in Drupal project management is a simple way to look at project teams as self-organizing nonlinear systems. This system is a network of interacting autonomous entities, all working towards the project’s goal. Each team member is autonomous, and the goal is value-driven.

As an example, Scrum which is an agile model with its three pillars of transparency is a framework that allows the teams to work towards the objective that makes the team most productive. Through this, team productivity is far more important than individual productivity. So while autonomy is taking place, collective achievement is the end-result.

The systemic view of agile teams also explains why clients are expected to be an active participant in the dynamics. The client is a component of the whole system which impacts the input flux, the project’s requirements, and output flux, the project’s releases, by defining priorities and needs.

Every kind of system needs a set of guiding rules.

Scrum, one kind of an agile technique framework for things like agile Drupal QA, is nothing but a set of rules that the project team as a system agrees to play by to meet their goals. Scrum isn’t a methodology—it’s a set of steps that have to be followed, like a manual.

The objective of any system is to improve continuously and emerge. Emergence here means achieving something that wouldn’t be possible independently. It takes an integrated team.

If we look at a project team, scrum does allow agile Drupal retrospectives as a tool or technique for continuous improvement. The main purpose of any environment where any system operates is to design interventions towards improved performance of the system.

Self-Organizing Drupal Support Teams?

So in this way, the best Drupal team can be a self-organizing system, and why not? The science does not limit the volume or size of the system. Perhaps a better word would be a self-organizing dynamic system, through constant retrospection and agility. You can bring stability to chaotic situations—or steep and changing demands or requirements—to meet a shared goal or organizational vision.

Today the discipline of System Dynamics is being used to model the software development life cycle, SDLC, processes we commonly use today. Or at least, that’s what we’re using successfully with our agile Drupal support teams. It works.

You can make this happen.

Applying agile and enabling self-organization might cause some growing pains at first. At Axelerant, we’re transitioning our content department to agile frameworks. It takes time. But for many organizations—perhaps yours?—the way teams go about creating things like dynamic software needs to change.


Agencies with flexible Drupal services, centered on agile practices and self-organizing principals, can help bring this to you. Because enabling self-organization may not be an in-house option right now. But one thing is absolutely for certain—whether you partner with a team like ours of if you go about self-organizing yourself. Things will never be the same.

Want an agile Drupal support on your side? Click Onward. jQuery(document).ready(function() { var custom_cta_viewed = false; jQuery(document).scroll(function() { if ( typeof ga !== 'undefined' && typeof isScrolledIntoViewPort !== 'undefined' && jQuery.isFunction( isScrolledIntoViewPort) && isScrolledIntoViewPort('.custom-cta') && custom_cta_viewed == false ) { custom_cta_viewed = true; ga('send', 'event', 'cta', 'view', 'drupal-support-maintenance'); } }); });

This article was originally published on November 11, 2015. It has since been updated.

This article Agile Drupal Support Teams Like Ours Are Self-Organized by Karuna Batra first appeared on Axelerant - Axelerant: Expert Drupal Development, Support, & Staffing.

Categories: Elsewhere

ImageX Media: Q&A with Lead Front-End Developer, Trent Stromkins

Planet Drupal - Thu, 28/04/2016 - 18:33

ImageX’s front-end development lead, Trent Stromkins, brings a unique background to his role. As a former designer, he uses his love for good design to develop with aesthetics and user experience in mind by marrying form and function. We spoke with Trent to discuss his experience and his thoughts on where design and development intersect.


Categories: Elsewhere

Phponwebsites: Create a node programmatially in Drupal 7

Planet Drupal - Thu, 28/04/2016 - 17:24
      This blog describes about how to create a new node programmatically in Drupal 7. If you want to add a new node, you can done at node/add by default. In Drupal, you can also add a node programmatically. Let see the below code.

// create object
  $node = new stdClass();
  // set title for a node
  $node->title = t('Created node programmatically');
  // set node type
  $node->type = 'article';
  // set node language
  $node->language = LANGUAGE_NONE;
  // set value to node body
  $node->body[LANGUAGE_NONE][0]['value'] = t('This node has been created programmatically in Drupal 7');
  // set value to node body summary
  //$node->body[LANGUAGE_NONE][0]['summary'] = text_summary(t('This node has been created programmatically in Drupal 7'));
  // set node body format like plain_text, filtered_html, full_html
  $node->body[LANGUAGE_NONE][0]['format'] = 'filtered_html';
  // author for a node
  $node->uid = 1;
  // status of node  0 - unpublished, 1 - published
  $node->status = 1;
  // promoted to front page or not
  $node->promote = 0;
  // sitcky at top of tha page
  $node->sticky = 0;
  // comments 0 - hidden, 1 - closed, 2 - opened
  $node->comment = 1;

  // add term
  $node->field_tags[$node->language][]['tid'] = 1;

  // get the file path
  $file_path = drupal_get_path('module', 'phponwebsites') . '/Desert.jpg';
  // create file object
  $file = (object) array(
    'uid' => 1,
    'uri' => $file_path,
    'filemime' => file_get_mimetype($file_path),
    'status' => 1,
  // Save the file to the public directory. You can specify a subdirectory, for example, 'public://images'
  $file = file_copy($file, 'public://');
  // assign the file object into image field
  $node->field_image[LANGUAGE_NONE][0] = (array)$file;
  // Prepare node for a submit
  $node = node_submit($node);
  //save the node

    After ran this code, you can see newly created node at admin/content. When you view that node, it looks like below image:

     Now I’ve hope you know how to create a new node programmatically in Drupal 7.
Related articles:
Add new menu item into already created menu in Drupal 7
Add class into menu item in Drupal 7
Create menu tab programmatically in Drupal 7
Add custom fields to search api index in Drupal 7
Clear views cache when insert, update and delete a node in Drupal 7
Create a page without header and footer in Drupal 7
Login using both email and username in Drupal 7
Redirect users into any page after logged into a site in Drupal 7
Categories: Elsewhere

Chromatic: May the Git --FORCE Be With You [Advanced Git Webinar]

Planet Drupal - Thu, 28/04/2016 - 16:46
5/25/16 – 10:00PST ~ 13:00EST ~ 17:00UTC

Register Now!

You know how to get things done with git: pull, add, commit, push; but have you mastered it like a jedi does the force? Nothing is a more lasting record of our work then our git commits. In a galaxy where companies ask you for your Github account in lieu of, or in addition to a resume, we have one more reason to make sure that our commit history is as readable as our code itself.

In this one hour session, we will cover:

  • Rewriting commits
  • Reordering commits
  • Combining commits
  • The perfect commit message
  • Finding bugs using git
  • Avoiding common pitfalls

Join us for this session and you will leave a jedi-level git master!

These Are Not the Commits You're Looking For

Register Now!
Categories: Elsewhere

Chromatic: Chromatic Site Launch Guide

Planet Drupal - Thu, 28/04/2016 - 16:46

When we prepare to launch a site, we all generally follow a rough checklist of items (if only in our own minds!) to ensure sure that all systems are go. At Chromatic, we wanted to produce a repeatable process that we could share not only amongst ourselves, but also with the community; and so the Chromatic Site Launch Guide was born.

We are hosting this guide outside of our blog as it is a living document and will change over time. Feel free to bookmark it and refer back to it the next time you are preparing to launch a site. The content is generated from a repository on Github, which means modifications via pull requests are welcome!

Categories: Elsewhere

Drop Guard: Probo.CI and Drop Guard work together for better QA process

Planet Drupal - Thu, 28/04/2016 - 12:23
Probo.CI and Drop Guard work together for better QA process Igor Kandyba Thu, 28.04.2016 - 12:23

Not long ago we were talking about the value of testing your updates in feature branch instances. It's the most efficient way of ensuring the quality of applied updates, but it's very time-consuming.

To use this process, you are required to maintain your own infrastructure to spin up QA servers quickly, run automated tests and share the testing instance between team members. And preferably, you do it every time an update is applied for any of the modules across your websites.

Probo.CI integration QA Drop Guard recipes Drupal Planet
Categories: Elsewhere

Jeff Geerling's Blog: Migrate a custom JSON feed in Drupal 8 with Migrate Source JSON

Planet Drupal - Thu, 28/04/2016 - 04:21

Recently I needed to migrate a small set of content into a Drupal 8 site from a JSON feed, and since documentation for this particular scenario is slightly thin, I decided I'd post the entire process here.

I was given a JSON feed available over the public URL http://www.example.com/api/products.json which looked something like:

Categories: Elsewhere

Lullabot: A Framework for Project Kickoffs

Planet Drupal - Thu, 28/04/2016 - 01:05

Project kickoffs can be the shortest individual component of a project, but they can also be the most important. Done poorly, a kickoff can feel like a reading of a contract by inhuman actors doing inhuman work. Done well, a kickoff can bring a team together and push them towards success. Kickoffs are one of the project skills we don’t get many opportunities to iterate and learn. Developers at Lullabot commonly end up attached to a client or project for many months (or years!) at a time, so it’s entirely possible to go that period of time without having a formal kickoff. Here are some thoughts I’ve had after doing several kickoffs this year.

About the Client

In a distributed team, a kickoff usually happens with a phone call. While pre-sales communication will have already happened, the kickoff call is usually the first time when everyone working on a team will be together at once. As a team member from the vendor, this is your chance to ask questions of the business stakeholders who might not be available day to day. I like to find out:

  • Why are we all here? Are the business, technology, or creative concerns the primary driver?
  • What is the business looking for their team to learn and accomplish?
  • What are the external constraints on the project? Are there timelines and due dates, or other projects dependent on our work? What are the upcoming decisions and turning points in the business that could have a big affect on the project?
About Me

We all have ideas about how we want to work and be utilized on a project. Making sure they align with the client is very important to work out during a kickoff. Sometimes, a client has specific priorities of work to get done. Other times, they might not have realized you have skills in a specific subject area that they really need. It’s really important to understand your role on a project, especially if you have multiple skill sets. Perhaps you’re a great Drupal site builder, but what the client really needs is to use your skills to organize and clean up their content model. Figuring all of that out is a great kickoff topic.

About Us

Once we understand each other, then we can start to figure out how we work together. It’s kind of like moving in with someone. You might know each other very well, but how are you going to handle talking with your landlord? How are each person’s work schedules going to integrate?

For a distributed team, communication tools are at the core of this discussion. We all have email, chat rooms, instant messaging, video, and more. What tools are best used when? Are there specific tools the client prefers, or tools that they can’t use because of their company’s network setup? Finding the middle ground between “all mediums, all the time” and “it’s all in person until you ask” is key.

Recurring meetings are another good topic to cover. Some companies will take new team members, add them to every recurring meeting, and use up a 10 hour-per-week consulting engagement with nothing but agile ceremony. Perhaps that’s what you’re needed for—or perhaps they’ve just operated out of habit. Finding a good balance will go a long way towards building a sustainable relationship.

Sharing each person’s timezones and availability also helps to keep expectations reasonable. Some companies have recurring meetings (like Lullabot’s Monday / Friday Team Calls) which will always be booked. Sometimes individuals have days their hours are different due to personal or family commitments. Identify the stakeholders who have the “worst” availability and give them extra flexibility in scheduling. Knowing all of this ahead of time will help prevent lots of back-and-forth over meeting times.

Finally, find out who you should go to if work is blocked. That might be a stakeholder or project manager on the client’s side, but it could also be one of your coworkers. Having someone identified to the team as the “unblocker of work” helps keep the project running smoothly and personal tensions low.

About Tech

For development projects, the first question I ask is “will we need any sort of VPN access?”. VPN access is almost always a pain to get set up—many companies aren’t able to smoothly setup contractors who are entirely remote. It’s not unheard of for VPN access to take days or weeks to set up. If critical resources are behind a VPN, it’s a good idea to start setting that up before an official kickoff.

Barring the VPN-monster, figuring out where code repositories are, where tickets are managed, and how development and QA servers work are all good kickoff topics. Get your accounts created and make sure they all work. If a client is missing anything (like a good QA environment or ticket system), this is when you can make some recommendations.

About Onsites

Some projects will have a kickoff colocated somewhere, either at a client’s office or at a location central to everyone. In distributed teams, an in-person meeting can be incredibly useful in understanding each person. The subtle, dry humour of your video expert becomes apparent in-person, but could have been misunderstood online. Most of the above can be handled in the first hour of an onsite visit, leaving much more time to fill given the travel time!

We like to focus onsites on the topics that are significant unknowns, require a significant number of people across many teams, and are likely to require whiteboards, diagrams, and group brainstorming. Project discoveries are a classic fit; it’s common to meet with many different people from different departments, and doing first meetings in person can be a significant time saver. The goal of an onsite shouldn’t be to “kick off” the project—it should be to build the shared understanding a team needs so they can be effective.

But what about sales engineering?

I’m sure some readers are now thinking “Wait a minute! Aren’t these all things you should know before a contract is signed?”. It’s true! Going into a kickoff without any of this information would be a serious risk.

It’s important to remember that the team on a kickoff isn’t going to be identical to the team who did the sales engineering work. Both the client and the vendor will have new people just getting started. As well, it’s useful to hear the project parameters one more time. Discrepancies in the discussions can alert the team to any misunderstandings, or more likely changes in the business environment running up to the signing of the contract. Especially on projects where a team is already working, hearing about progress or changes made in the week between signing an SOW and kickoff can be invaluable.

What did you learn the last time you helped to kick off a project? Let us know in the comments!

Categories: Elsewhere

DrupalEasy: Just in case - Drupal 8's /core/rebuild.php

Planet Drupal - Wed, 27/04/2016 - 20:59

Drupal 8 has lots of things that Drupal 7 doesn't have - a modern object-oriented foundation, the Twig templating system, and WYSIWYG out-of-the-box - just to name a few. There's also a good number of less flashy additions that are designed to improve the developer experience. One of these additions is the /core/rebuild.php file. 

While it is common knowledge that clearing rebuilding Drupal's caches is good practice during development, Drupal 8 brings a new tool to the table to get it done. Previous to Drupal 8, most developers utilized Drush to clear caches, some less-efficient folks cleared caches from the user interface (usually from the Admin Menu, but sometimes - gasp! - from the admin/config/development/performance page). 

Drupal 8 comes with a new /core/rebuild.php file that doesn't require the Drupal 8 site to be functioning (fatal errors, anyone?) nor does it require Drush or Drupal Console. Instead, as long as your site's configuration allows it, all you have to do is navigate to /core/rebuild.php in your browser. As Drupal's documentation states, this "Rebuilds all Drupal caches even when Drupal itself does not work."

How do you know if your site's configuration supports this functionality? Well, if you're working locally (and if you're developing, you should be working locally), then just make sure that $settings['rebuild_access'] = TRUE; in your settings.php (or, better yet, settings.local.php). The other method involves running the /core/scripts/rebuild_token_calculator.sh script from the commandline, and using the results as query parameters for /core/rebuild.php (see "Method II" on https://www.drupal.org/node/2153725).

Granted, most developers have Drush and/or Drupal Console installed everywhere they're working, but it's always good to have a backup method for rebuilding Drupal's caches - just in case.

Categories: Elsewhere


Subscribe to jfhovinne aggregator - Elsewhere