tl;dr: If you want to skip the 'how-to' part and explanation, check out the pix_migrate example Drupal 8 migration module on GitHub.
For a couple years, I wanted to work on my first personal site migration into Drupal 8, for the last Drupal 6 site I had running on my servers. I've run a family photo/audio/video sharing website since 2009, and through the years it has accumulated hundreds of galleries, and over 20,000 media items.
The home page of the Drupal 8 photo sharing website.
Zuckerberg didn’t just invest ‘cuz its fun when he bought Oculus with $ 2Billion. VR existed in some form or the other but was either making people sick or was too costly and then Facebook bought Oculus and it changed everything.
But the question remains as to with all these investments for VR technology and the startups, how will that give an ROI and what is in it for the Media industry?
This article explores and analyses the possibilities of Virtual Reality. We also ponder as to how Media industry can make the most out of such a transition. In a previous article, we find answers to the five most basic yet important questions for VR and its Timeline.Subscription Purchases…
People contributing modules or themes for listing on Drupal.org receive a welcome, or lack thereof, that would have driven away many of us now active in the community. With hundreds of requests moldering awaiting review, the project application process continues to be a community crisis, and it has been acknowledged as such for five years. We are casting aside the literal future of Drupal, with a likely disproportionate impact on disadvantaged contributors. Any separate process for new contributors will inherently be unequal, and will tend toward awful. Let's jump in to mitigate the damage being done and finally get a new system in place— we're closer than ever.
After a couple frustrated module makers asked me to give their projects full status, I went over to the project application review queue out of the sense that it isn't fair to everyone else to save only the two who reach out. Of course, I should have been in there all along: there were project applications which had been vetted by other volunteers and marked Reviewed & Tested by the Community four months ago. One person who contacted me was unhappy their project had passed all the hurdles and was then left lying untouched for a mere two weeks. Of course, they had started the application process nine months ago.
The door through which community members can make their first contribution of a module or theme remains locked, and not enough people have the key (nor is it clear how to get that key to more people).
Keep in mind this is only projects that have actually been reviewed. In nearly every case the person applying has fixed the issues noted and now the project has been considered by someone to be all set for approval. People trying to get to that point are even worse off. The current backlog for people waiting to get a review has projects waiting with the needs review status for nearly a year — 11 months and five days. And of course the current project application review process, despite having gone through several iterations of improvement, still garners its share of complaints when running perfectly— and it still holds new contributors to a higher standard than we hold ourselves.
Finally, some unknown but large percentage of the two thousand projects marked "Closed (won't fix)" have been put in that state automatically by a robot due to lack of activity. If a contributor leaves an application in a "Needs work" state for a month, it is unceremoniously closed without warning. (In contrast, if we don't get around to reviewing or approving a project for months, nothing automatically happens in favor of the contributor, despite written guidelines for escalating ignored issues.) It will be fun to go through all these old issues and contact the contributors letting them know they can promote their sandboxes to full project (and then changing the issue to some other status, like works as designed, to mark it), but we can't do that until the overall process is fixed. The good news is we're closer than ever.
The current proposal looks solid, but it's suffering from inaction. The goals it outlines are excellent:
- We need to remove the gate to new contribution entirely - not just kick the can to a particular elevated role, or a specific limit on the # or kind of releases a new contributor is allowed.
- We need to continue to send strong signals about security coverage to users evaluating whether to use modules from Drupal.org.
- Follow-up: We need to find ways to preserve the value collaborative code review, through changes to Project Discovery to provide signals about code quality, and by providing incentives and credit for review.
I encourage anyone who cares about new people joining Drupal to work on the issues associated with this proposal, in particular the ones to allow non-git vetted users to promote sandbox projects to full project status and add a permission for creating stable releases, and grant to “git vetted” users. While my oft-stated preference is that any gates we put up must apply to all users, so we make sure they are bearable and don't forget about problems for months and years at a a time, moving the gate to a security review at a stable release has huge advantages of its own. It allows a new contributor to put their work out there without being blocked by anything. It allows a module to find its audience and have people invested in its particular functionality at the point of review, rather than have only volunteers who have no inherent stake in the functionality involved. It even lets a contributor decide whether a module has proven sufficiently useful to others to be worth going through security review.
We don't have that system yet though and we still have that huge backlog to get through. Helping other people follow the project application checklist is a great way to get better at making projects yourself— whether you have a dozen already, or don't have any yet. Just remember this is about helping applicants. To give further incentive to the review work, i've proposed including issue credits given to users in the Project Application review queue on profile pages and Marketplace rankings.
It's Rosh Hashanah, the Jewish new year, and the tradition is that we have ten days to make things right with any people we have wronged. Let's accept (again) that we as a community have wronged our potential new contributors, and make things right. Thanks.
Since Drupal is a content management framework, so it’s worth mentioning a module which reflects the very essence of content management — the Views, of course. Simple but powerful, the Views is the most popular module, installed on over two-thirds of Drupal sites.Read more
This article will explain how to formulate the route name for a view because there are very few sources for the information online.
If you have a site that's still on Drupal 6, you're not alone. As of about a week ago, there's still over 88,000 Drupal 6 sites out there!
While support from the community ended on February 24th, the Drupal 6 Long-Term Support vendors have been hard at work, releasing over 20 security fixes for various contrib so far, including very popular modules like Views and Panels!
While the D6LTS vendors haven't released any security fixes for Drupal 6 core yet - it's only a matter of time!
If you want to be ready for it when they do, we recommend that you update to Pressflow. But that's not the only reason!
Read more to find out why and how!
This is the second installment of Palantir.net’s Guide to Digital Governance, a comprehensive guide intended to help get you started when developing a governance plan for your institution’s digital communications.In this post we will cover...
- What's next after the 10,000ft view
- What properties you need to think about
- Applications and integrations you also need to consider
Stay connected with the latest news on web strategy, design, and development.Sign up for our newsletter.
Having started at the 10,000ft view to assess the digital ecosystem for our governance planning, part two of the Guide to Digital Governance begins to identify the specific properties and platforms you will need to consider within that ecosystem.
Taking the top level categories you listed for your governance plan in part one, you now will want to think of the properties and platforms within each of them. The following questions are intended to help you think through each piece carefully.
- What are the websites we own that are visible to anyone on the Web?
- Do we have any public subdomain Websites, such as subdomain.mywebsite.com?
- Do we have any micro-sites, or Websites with a URL that is different from our main site?
- Do we have any blogs that may be hosted elsewhere, but would be considered part of our public Web presence?
- What are the Websites we own that are visible to only those with access we control?
- What are the Websites we own that are visible to only those who have access through machines running on our organization’s network?
- Do we have any subdomain Websites, such as subdomain.mywebsite.com that require logging in?
- Do we have any Websites for only a specific set of constituents?
Intranets and Portals
- Do we have a network of internal-use Websites (a.k.a an Intranet), accessible only by password or by logging on to the organization’s network, or otherwise hidden (even by obscurity)?
- Do we use any portal sites or pages as a means of aggregating links of importance for specific groups of users?
- Are there any web-based applications we use to perform specialized tasks, such as generating reports from data in a database or retrieving digital assets from a database?
- Are there any online tools that we use (whether built internally or purchased from a third-party vendor as software-as-a-service (SaaS)?
- What platforms, systems, and/or services do we use for collecting payments online?
- What platforms, systems, and/or services do we use for selling products online?
- Where are these located relative to our other Websites?
- What are the social media networks we use to communicate to the outside world?
- What are the platforms we use to create digital media, such as video, audio, and photography?
- What are the platforms we use to distribute digital media, such as video, audio, and photography
- What are the systems we use to send broadcast email to all or large segments of our internal group, members, staff, community, etc.?
- What are the systems we use to send broadcast email to all or large segments of our external community, clients, constituents, etc. for the purposed of marketing and promotion?
Digital Communications Governance
- What are the pieces that will constitute our official governance system?
- NOTE: You may not know the answer to this one yet, so leave it empty for now.
This post is part of a larger series of posts, which make up a Guide to Digital Governance Planning. The sections follow a specific order intended to help you start at a high-level of thinking and then focus on greater and greater levels of detail. The sections of the guide are as follows:
- Starting at the 10,000ft View – Define the digital ecosystem your governance planning will encompass.
- Properties and Platforms – Define all the sites, applications and tools that live in your digital ecosystem.
- Ownership – Consider who ultimately owns and is responsible for each site, application and tool.
- Intended Use – Establish the fundamental purpose for the use of each site, application and tool.
- Roles and Permissions – Define who should be able to do what in each system.
- Content – Understand how ownership and permissions should apply to content.
- Organization – Establish how the content in your digital properties should be organized and structured.
- URLs – Define how URL patterns should be structured in your websites.
- Design – Determine who owns and is responsible for the many aspects design plays in digital communications and properties.
- Personal Websites – Consider the relationship your organization should have with personal websites of members of your organization.
- Private Websites, Intranets and Portals – Determine the policies that should govern site which are not available to the public.
- Web-Based Applications – Consider use and ownership of web-based tools and applications.
- E-Commerce – Determine the role of e-commerce in your website.
- Broadcast Email – Establish guidelines for the use of broadcast email to constituents and customers.
- Social Media – Set standards for the establishment and use of social media tools within the organization.
- Digital Communications Governance – Keep the guidelines you create updated and relevant.
We want to make your project a success.Let's Chat.
When I was on vacation in Italy this summer, I had no internet, which gave me a lot of time to think. Some of that time was spent reflecting on why I do what I do. I have been working on Drupal for over 15 years and on Acquia for almost 10 years. The question of what gives me meaning and purpose has changed drastically over that time.Evolving purpose
I started Drupal because I wanted to build a website for myself and a few friends — an internet message board to exchange messages. In the early days of Drupal, I was obsessed with the code and architecture of Drupal.
As I wrote in 2006: "I focused completely and utterly on creating fewer and fewer lines of more elegant code.". I wanted Drupal to be pure. I wanted the code to be perfect. For Drupal to be architected in the right way, I had to rewrite it multiple times and strip away anything that wasn't necessary – I couldn't imagine preserving backwards compatibility as it meant we had to drag along a lot of historical baggage. My mission in the early days was to keep the platform fast, clean and on the leading edge of technology.
As time passed and Drupal started growing, my role evolved. More people became involved with Drupal, and I thought more about scaling the community, including our tools, processes and culture. I started to focus on building the Drupal Association, promoting Drupal, handling trademark issues, and last but not least, setting the overall direction of the project. In the process, I started to worry less about achieving that perfect vision and more about the health of the community and collaborating on a shared vision.
While I miss programming, I have come to accept that I can't do everything. Every day when I wake up, I decide where I want to focus my energy. My guiding principle at this time in my life is to optimize for impact. That means enabling others versus doing much programming myself.Meaningful moments: part I
While in Italy I decided to make a list of the moments in Drupal's history that stand out as particularly meaningful or purposeful. I started to discover some patterns in these moments, and ended up sorting them into two groups. Here is the first set:
- When people find Drupal, and it gives them a better career path and ultimately changes their life. I got goosebumps when almost 3,000 people stood up at DrupalCon San Francisco when I asked "Please stand up if Drupal changed your life". I often talk to people that went on to make a full-time living with Drupal – or even start a Drupal business – to provide better lives for their families. Some of these stories, such as Vijaya Chandran Mani's, are deeply impactful.
- Seeing how Drupal is used for aid relief, like in the aftermath of the 2013 tornado in Moore, Oklahoma. Members of the Drupal community worked throughout the night to create a website for victims to help each other.
- Seeing how Drupal has made a meaningful impact on the Open Web movement. Over the last 10 years, millions of people have created Drupal sites that express their creative freedom and individuality. In recent years, I've become concerned about the Open Web's future and have spoken out on how the Drupal community is uniquely positioned to help preserve the open web. I believe it's an important mission that we should all embrace, so the original integrity and freedom of the Open Web remains intact for our children and grandchildren.
All of these moments suggest that my purpose is self-transcendent – I get meaning when my work matters more to others than it does to myself. Organized into radiating circles, the impact on each of these groups gives me purpose: individual Drupalists, the Drupal community, Drupal end users, and the open web. This is why I've become so passionate about things like usability, internationalization and accessibility over the years.
I know it's not just me; my team interviewed many other people that have the same feelings of finding meaning when their work results in life-changing outcomes. One great example is "Franck" Seferiba Salif Soulama, who hopes that training more young people in Drupal can lift people from Burkina Faso, Africa out of poverty. He wants to provide them job opportunities so they don't have to leave their country. Other examples are Drew Gorton or Ronan Dowling. There are many people like Franck, Drew or Ronan around the world that have a positive domino effect on others.Meaningful moments: part II
The second group of moments I wrote down weren't necessarily self-transcendent, but still gave me purpose. Here are a few examples:
- Fundraising after the great server meltdown. In 2005, we had to raise money to buy new infrastructure for Drupal.org. We nearly had to shut down Drupal.org and could have lost everything. While it was a difficult time, this moment was especially meaningful as it helped us come together as a community.
- Having to ask individuals to leave the project or change their behavior because their values weren't aligned with the project. While providing critique or removing someone from the project has never been never easy, I'm proud of the times we stand up for our values.
- Getting Drupal 8 over the finish line after 4.5 years of hard work. At times, many people doubted our progress, questioned whether we were making the right decisions, and even left our project. While the development process wasn't always fun in the moment, when we did release parties around the world, we all felt a real sense of accomplishment. In the long run, we built something that will keep Drupal relevant for many years to come.
Many of us find meaning when the hard and uncomfortable work results in life-changing outcomes for others. Not only does this type of work provide purpose, some people believe it is the recipe for success. For example, Angela Lee Duckworth's TED talk on grit applies directly to the work that is done by Drupal's maintainers.How do we scale purpose?
Hearing all of these inspirational stories makes me think: How we can attract more people to the project, but do so in a way that ensures we share our core values (like giving back)? While there are no straightforward answers to this question, there are many organizations that are doing great things in this area.
One example is the Drupal Campus Ambassador Program which hopes to appoint ambassadors in every university in India to introduce more students to Drupal and help them with their job search. While at Drupalcon India earlier this year, I met Rakesh James, who has personally trained 600 people on Drupal!
Another example is the Drupal apprenticeship program in the UK, which focuses on recruiting new talent to the Drupal community. Participants get an extensive Drupal bootcamp to help them with their job search. Many of these apprentices are disadvantaged young people who have great talent and aptitude, but might be lacking the traditional route or access to a meaningful career path.
I'd love to take programs like these global – they instill our values, culture and a sense of purpose to many new people. If you know of similar initiatives, or have ideas to share, please do so in the comments section.
Based on my own introspection, and hearing from amazing Drupalists from around the world, I truly believe that Drupal is fueled by a collective sense of purpose that sets us apart from other open source software communities and organizations. We need to keep this purpose in mind when we make decisions, especially when the going gets tough. What is your sense of purpose? And how can we scale it around the world?
Starting with Drupal 8, we decided to make more rapid innovation possible by releasing minor versions every 6 months that may come with new features and backwards compatible changes. Now that we released Drupal 8.1.0 and almost 8.2.0 as well, how did we do? Also what else is possible and what is blocking us to make those moves? What do all the changes mean for how might Drupal 9 unfold?
Dries Buytaert posted last Wednesday The transformation of Drupal 8 for continuous innovation and on the same day I presented Checking on Drupal 8's rapid innovation promises at DrupalCon Dublin. Here is a video recording of my session, which should be good for those looking to get to know Drupal's release process and schedule, as well as how we made it possible to experiment within Drupal core directly with Drupal 8. While I did hope for more discussion on the possibilities within Drupal 8 with the participants, somehow the discussion pretty much ended up focusing on Drupal 9, when it should be released and how much change should it come with.
Drupal 8 Development Cookbook, written by Matt Glaman is full of useful information about Drupal 8 site building and development - and a worthy addition to anyone's Drupal library. Unfortunately, the "cookbook" format of the book seems to subtract, rather than add, to the usually well-explained concepts throughout.
The book covers an impressive array of topics: Everything from setting up a local environment to many of the technical details of the Entity API. No matter what your skill level with Drupal, there is likely to be something in this book of interest. Having been a Drupal professional for over ten years, I found the chapters on plugins, configuration management, the Entity API and web services especially interesting and educational.
Each chapter (there are 13) includes an often-too-brief introduction, followed by several "recipes." Each recipe includes several sections, including "Getting ready," "How to do it…," "How it works…," "There's more…," and "See also." While the How to do it… sections usually contained the bulk of the narrative, I often found myself wanting more details in the How it works… section. Additionally, I felt that each recipe often didn't have an adequate introduction. The crazy part is that the information I was looking for was often in the How it works… section - presented after the How to do it… section. I think this will lead to some initial confusion by readers asking themselves "why am I doing this?" until they read the How it works… portion. Usually, all of the information was there, just not in the right order (for me at least.) This is especially apparent in the "Plug and Play with Plugins" chapter where I found the How it works… sections more valuable than the How to do it… sections. They really would have been better leading off each recipe.
The author clearly has a firm grasp of the material. This usually shines through in most of the recipes, but there are times in the book where I think the author assumes the reader has a similar level of knowledge - which leads to some disconnects in the narrative. One example of this is the "Creating a custom content type" recipe. There is very little introduction, and I feel that it assumes the reader has a firm grasp of the power of content types (and fieldable entities, for that matter.) This, and several other recipes would benefit greatly from beefed-up introductions (including Features, text formats, some of the Front-end recipes and plugins [especially explaining why we use annotations.])
The recipes also vary widely in their complexity. I'm not sure this if this is a good or bad thing, but perhaps some sort of "complexity level" rating should have been applied to each one to give the reader a heads-up. This is illustrated well with the fact that the plugins chapter assumes the reader has a firm understanding of object-oriented PHP. Granted, I don't expect the author to write a primer on the topic, but a warning in the introduction, or aforementioned complexity level, would have helped smooth the transition into this chapter.
As one example of the format forcing things to be out-of-order, the book begins with the assumption that the reader has a local development stack installed, which is not an unreasonable assumption. But for readers who are new to local development environments, after the recipe to install Drupal 8, in the There's more… section, the author presents valuable information about how to create a database and a database user. There is no mention of this material prior to the How to do it… section. I can easily imagine a scenario where a reader is attempting the recipes in the order they are presented without reading ahead, and being extremely frustrated until they find the There's more… section. A mention of it earlier in the chapter would go a long way here.
The book does a really nice job covering topics I didn't expect to see - including DrupalVM, Entity Reference Views displays, a thorough explanation of a module's .info.yml file and routing files (who knew you could validate a route name with RegEx right in the .routing.yml file!) There is a really nice chapter on configuration management (although more of an introduction on content vs. configuration would have been extremely useful) and Entity API.
For Drupal 7 developers moving to Drupal 8, "The Entity API" chapter is worth the cost of the book. This chapter solidified and extended the knowledge I already had. Its introduction is solid and the chapter includes examples for both content and configuration entities. While it suffers from some of issues I've already mentioned (great content, wrong format,) for the most part it overcomes these challenges and goes much deeper into the topic than I had hoped. Well done!
At the same time, the book also covers a few topics in places where I thought it was a little too aggressive - having a "Running simpletest and PHPUnit" recipe in chapter 1 is a good example. In addition, I believe I spotted a few bugs in the book - both in the narrative and in the code samples - I've forwarded them to the author. Also, in some chapters, the author is writing about a moving target. There are more than a few places where he is forced to reference active Drupal.org issues. As these issues are resolved, recipes may spoil (food pun!)
There were more than a few recipes that involved custom module development; all of which are well-written, technically on-point, and will be extremely useful for Drupal 7 developers moving to Drupal 8. Since this is a book review, I have to pick on one point - all of the recipes were presented as if the developer is writing them from scratch. In reality, I've found the vast majority of Drupal 8 developers building custom modules for clients take full advantage of Drupal Console's "generate" command. While the author does formally introduce this in the last chapter of the book, it feels like it's not in the right place. By introducing it earlier many of the recipes could be written to take advantage of it.
Who would I recommend this book to? If you're a Drupal 7 developer looking to learn Drupal 8 development, this book is a great resource. While there are several introductory and site-building chapters that won't be very useful to you, the more advanced chapters provide (usually) adequate background information along with practical examples (ahem, recipes) to get you going. Would I recommend this book for beginners? If you have a solid PHP background, then yes. In my opinion, the author is more than capable of writing an intermediate-to-advanced Drupal 8 development book - leave the introductory stuff to someone else.
The monthly core patch (bug fix) release window is this Wednesday, October 05. Drupal 7.51 will be released with fixes for Drupal 7. This is also the release window for Drupal 8.2.0, the next scheduled minor release of Drupal 8. (Read the release candidate announcement for more information on the minor release.)
To ensure a reliable release window for the patch and minor releases, there will be a Drupal 8.2.x commit freeze from 12:00 UTC Tuesday to 12:00 UTC Thursday. The final patches for 7.51 have been committed and the 7.x code is currently frozen (excluding documentation fixes and fixes for any regressions that may be found prior to the 7.51 release). So, now is a good time to update your development/staging servers to the latest 8.2.x-dev or 7.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!
Other upcoming core release windows after this week include:
- Wednesday, October 19 (security release window)
- Wednesday, November 02 (patch release window)
Drupal 6 is end-of-life and will not receive further releases.
Just started a discussion about it here:
Hope you join the discussion and share your thoughts.