سیاره دروپال

Drupal.org - aggregated feeds in category Planet Drupal
Subscribe to خوراک سیاره دروپال
Possible solution for knowledge sharing in the Drupal 8 media domain slashrsm Mon, 06.02.2017 - 10:48

Drupal 8 has very good media handling support. Media team has (and still is) working hard to make Drupal the best CMS in the world when it comes to managing media. We have many modules in the contrib space that solve most of the common use cases in the domain. There is one problem though; there are many of them and some of them are quite complex and abstract. I've noticed that many times users struggle to completely understand what each module is responsible for, which features it comes with and specially how they all together fit into the bigger picture.

There are so-called feature modules (such as File entity browser, Media, Content browser, Media entity browser, ...) and distributions (such as NP8, Thunder, Lightning, ...) which ship with default configuration for the 80% use case. They are plug and play solutions, but it is also possible to use them as a base for learning and research of the ecosystem.

But unfortunately that's not enough. While some people learn the quickest by exploring existing solutions (myself included) that isn't the case for everyone. A lot of people need more guidance and those are the users that we're currently not supporting as much as we should. In order to drive further adoption of the media ecosystem and Drupal 8 itself we need to solve this knowledge sharing problem that I believe we have.

I was thinking about this problem a lot lately and I think I came up with an idea that could help us solve it.

It is a book.

A problem solving oriented book which would guide users through the ecosystem, explain individual parts and, most importantly, offer a bunch of recipes for the common problems. It wouldn't be one of those 800+ pages technical books (who has time to read that?!). Rather it would be a compact source of information which you can have on your desk and use it when you run into a problem. We all want to build websites and the purpose of this book would be to help you do that as fast and as efficiently as possible.

Book would produced by the people that designed and built the Drupal 8 media ecosystem, which would ensure highest levels of quality. It would be released under a Creative commons license with its sources publicly available on GitHub. Printed and compiled eBook versions would be sold through the standard channels.

Why copyleft?

I honestly believe into the free sharing of knowledge in our society. My opinion is that the only way to evolve our civilization is to freely share the knowledge that we have. There are also practical reasons besides the philosophical one. Making the book publicly available ensures that it will be likely updated as the ecosystem and Drupal itself evolve and change. This wouldn't necessarily be the case if the standard copyright license would be used.

Great idea! Why didn't you realize it already?

I am glad that you agree! :) Well... it is not that easy. Producing a real book is not that simple and it also comes with quite some expenses. There is the cost of the content production, proofreading, design, print, shipping, ... I've done a back of a napkin calculation and estimated that we'd need around 20.000€/$21.500/17.000GBP to do it.

My idea was to start a crowdfunding campaign to raise this amount. Backers would, depending on the perk level, get an eBook, print edition or both. Besides that they'd also get early access to the repository with the ability to provide feedback during the process of writing.

Now I need your feedback

I need to hear from you. Is this something that would benefit the community? Is there any better way to educate users about the ecosystem? Would you prefer an online video course instead of a book? In-person training? Something else? Would you be prepared to back the crowdfunding campaign? If yes, what amount would you be prepared to invest?

Please use the form below to share your thoughts. Thank you! I appreciate it.

Enjoyed this post? There is more! Join us at the next Drupal Media sprint at the Mountain camp in Davos! Playing with the Sculpin static site generator Results of the Drupal 8 media sprint
Last time we've learned how to create custom ctools content type plugin. In that post we've already created a module example_module where we defined the plugin. This time we will learn how to create custom ctools access plugin. This type of ctools plugins can be used as a selection rule for a panel variant or as a visibility rule for a panel pane. Please, read previous post before continue reading this. There is described how to create a module and integrate it with ctools.
Read more »
Ctools content types are an alternative to standard Drupal blocks. They are more comfortable and powerfull than blocks. Ctools content type plugins also known as panel panes. In this post you will learn how to create a configurable ctools content pane plugin.
Read more »

We've worked with many clients over the years, who all have very specific website development needs. While some clients may share common goals, each may approach those business goals in different ways. But, time and time again, we usually start by asking a client in what ways are they measuring their website's effectiveness. In this 4 part series, I'll discuss identifying purpose and overcoming obstacles, complaints of current site capabilities and establishing budget, metrics to success and selecting a vendor, then finally risk tolerance and disaster recovery planning.

DREC is a collection of basic bash scripts that work together to accomplish common development tasks for Drupal 8.x projects. In simple words drec uses shell commands, unix utilities, drush, drupal console, git, docker and other software that all together can install, update, clone etc a Drupal project.

The main problem I wanted to solve with drec is to setup and update a local development environment from scratch for a Drupal distribution on LAMP. So, you should probably use drec locally or on a development environment and not on a production server. I created this for Linux but it could also play well with any unix* system (hope so).

Some of the characteristics of drec is that it can run commands in chain and that it uses a configuration file (.drecfile) where each project can keep useful details about it that drec can (re)use when running.

Here is a list of the current drec commands:

Command Description git-clone Clone a site from a git repo create-folder Create the project folder delete-folder Delete the project folder create-vhost Create a virtualhost for project's domain delete-vhost Create a virtualhost install-drupal Install Drupal using drush prepare-install Prepare a Drupal site for installation (public files, writable settings etc) create-docker Create a docker container delete-docker Delete a docker container create-drush Create a drush alias delete-drush Delete a drush alias composer-install Run composer install on the project folder composer-project Run composer create-project ... on the project folder create-db Create a mysql database download-db Download a mysql database delete-db Delete a mysql database askme Asks user to continue or exit init Create a *.drecfile settings file on the ~/.drec folder delete-project Delete all project files, database, container, drush alias etc projects Show all *.drecfile filenames inside ~/.drec folder debug Show variables on cli

and here are some usage examples:

// Clone a project and start a docker container with mapping folders drec init,git-clone,create-docker // Clone a project from a git repo, create a virtualhost and create a new configuration file drec init,git-clone,create-vhost // Create a new database, clone from git repo, prepare for Drupal installation and install Drupal drec init,create-db,git-clone,prepare-install,install-drupal // Just debug a configuration file and read its values drec debug /path/to/MYFILE.drecfile drec debug filename/of/.drecfile


Issues, suggestions and your opinion are always welcome.


View drec on Github


Last year I had the chance to collaborate with a Drupal company in Greece for a large scale Drupal 8.x project. One of these that you say Drupal was made for!

It was early 2016 when Drupal 8.x had just arrives. At that time thing were a bit confusing (although promising) with the new Drupal version. Composer adoption was still in "alpha", popular Drupal contributed modules where not ready for production, new concepts in core had to be learned, Phpstorm (or another advanced IDE at least) was required etc. In general things were unclear and the development team needed a guide in order to avoid the "search on Google" disease.

One of my responsibilities for this project was to document the "best practices" and HowTo​ work with the new Drupal version, with software such as git, Docker, composer and all the software needed. In plain English I had to create, maintenance and update the official documentation of the project.

After some discussion we had internally we decided to publish these docs using the ReadTheDocs.org platform under an open source license (Open Publication License). We did this not only to make the things easier for us or reuse the knowledge we got but also to get help from anyone else that wanted to do the same. The audience are people that already know Drupal 7.x and want to dive into Drupal 8.x. In fact, I was also learning new concepts and methodologies (but, yes, with Drupal we never stop learning new things, don't you agree?)

Copying the first lines of the docs to get the purpose of the docs:

A useful manual for Drupal developers, themers and site builders that want to start collaboration work with the new Drupal 8.x stuff.

The initial documentation created to help us in the maintenance and development of a complex Drupal 8.x distribution but became more generic and public available in the future.

Common best practices are in place and new methodologies of development are proposed on this manual.

Before starting I 'd like to describe a bit the project I am talking about.

It was a multilingual portal with multidomains, unified Dashboard per (sub)domain, content workflows and many content types and fields. More about the parameters can be found at dropdog.readthedocs.io/parameters. We decided to use Features module and Drush make files, Github and the Git Flow model for the git branches. We were also using Docker for local development environments as also as other Shell scripts to automate the processes.

The Docs are separated into 11 major sections which are:

  1. Learn
  2. Parameters
  3. Infrastructure
  4. Development
  5. Theming
  6. Tests
  7. Reviews - Entity
  8. Reviews - Views
  9. Scripts
  10. Development thoughts
  11. Terminology


The titles of each section are self describing. Unfortunately some sections are incomplete and contain only the headers  (Scripts, Tests and Terminology).

One interesting thing I would like to promote here are the naming conventions we decided to use while developing the website (entities & fields, views, features etc).  Using the pattern field_CONTENTTYPE_SHORTNAME and other similar conventions, for example, allowed us to make changes in bulk, search for issues more easy, avoid Features issues and conflicts with configuration and "standardize" the theming. Furthermore, in order to make some human reviews for Entities and Views we created lists of checkboxes ready to be copied on a Github issue when a new Entity or Views is created.

Another one is the rules we had when setting User Roles such as that "Every custom module should define its own permissions. Never reuse an existing permission!" I still believe strongly that this rule should be implemented with Drupal core modules also but this is another issue that will not discuss now...

For the Theming we followed a variation of the Atomic Design approach (see Patternlab) and created our own "Drupal specific" folder structure expecially for the scss files. Of course for scss we set up some well known rules and linting to avoid development conflicts. Another useful thing here is that we followed the desktop first design. That means that we first designed for desktop but with mobile in mind and not the opposite since the mobile visits were a few (and there were no obvious signs that this would change in the future).

I could say a lot for the whole experience but it's better to let you "explore" the docs and take what you find may be useful. Pull requests and suggestions are always welcome.



Modern digital services need to integrate and interact with each other to provide a seamless user experience and data integrity in every…

News Read time: 6 minutes

January is always a time of conclusions. We evaluate a past year, remember its best moments, and hope that the new year will bring us even more positive moments. It’s also a time of different rankings. We at Vardot decided to contribute to the good vibe of the community by going through the best articles of the last year according to BuzzSumo and choosing those ones that had a better feedback from you. The blog post you read now lists, in ascending order, the 12 most shared articles about Drupal in 2016.


12. Happy birthday Drupal (924 shares)

On Drupal's 15th birthday, the community celebrated with an infographic that reminisces about the significant events and achievements in the past year. No open source project can survive and

even thrive for so long without a vibrant community. Scroll through the article and you will feel the urge to attend that next DrupalCon in some exotic location.


11. Drupal founder sets up Acquia Labs to research the future of the web (958 shares)

Celebration of the past 15 years aside, Dries Buytaert is never complacent with his brainchild. He is already thinking ahead and inventing the next-generation web user experience. To that end, Dries set up Acquia Labs to engage in R & D. If he has his way, the web of the future won't be browser based, and page views will be a thing of the past. The next generation of user interaction will be voice-controlled, visual in the style of VR (Virtual Reality) or AR (Augmented Reality), and adaptable to user situations.


10. Improving collaboration with forks (1.1k shares)

The success of the open-sourced Drupal project hinges on the collaboration of a large community of developers to enhance and customize the product. Drupal developers collaborate by writing and sharing code. When an upstream developer modifies code that has been previously forked, the changes often need to be propagated downstream in a controlled manner. This article is a brief introduction on pull requests created from a fork. You will find the link to a longer guide at the end of the original article.


9. Several critical remotely exploitable flaws found in Drupal modules, patch ASAP! (1.5k shares)

The Panama Papers refer to 11.5 million private financial documents which were leaked from a Panamanian law firm. These documents collectively implicate 72 current and former heads of state in fraudulent activities such as tax evasion. The leak was caused by vulnerabilities in Drupal and WordPress, two leading content management systems (CMS). Drupal site administrators did well for heeding the call of this article to patch the known vulnerabilities.


8. Drupal: 15 years old and still gaining momentum (1.7k shares)

This is a blog post written by Dries Buytaert on the day of the 15th anniversary of releasing Drupal 1.0. It gives us a glimpse, from the firsthand perspective, of the path the Drupal project has taken over the years. Dries even recounted some product decisions he made, both rightly AND wrongly, over that time period. He shared about his own professional development as a result of this journey, and his renewed commitment to building a better and safer web for all.


7. Panama Papers hack: Unpatched WordPress, Drupal bugs to blame? (1.8k shares)

The author of this article plays the role of investigative reporter on the Panama Papers leak. It discusses 2 possible entry points for the intruder (or intruders) into the Panamanian law firm's computer systems: a public WordPress website and a customer-only Drupal portal. Both installations were running outdated and unpatched versions of the respective CMS software at the time of the leak. The author advocates keeping your systems up-to-date in this article. He praises WordPress for automating security updates, and then chastises Drupal for lagging behind in this crucial process.


6. Is this how a hacker got the Panama Papers? (2.3k shares)

It is very difficult to pinpoint, without access to the system log files, how an intruder hacks into a web system. But, that does not stop the author of this article to put forth hypotheses in the Panama Papers leak, even identifying the plugin that may be the culprit. Site administrators should read this article for the long list of things that the Panamanian law firm did wrong, so that they can avoid making the same mistakes.


5. The security flaws at the heart of the Panama Papers (2.4k shares)

This is the Wired magazine's report on the Panama Papers leak. The article distinguishes itself from other similar reports because it conducts its own primary research. Specifically, it cites both named security experts and anonymous sources alike. It is obvious that this article does not target a technical audience. However, it compensates for the lack of technical depth by offering breadth in its research. It covers some lesser reported probable causes for the leak, including the possibility of it being an inside job.


4. From encrypted drives to Amazon's Cloud - the amazing flight of the Panama Papers (2.7k shares)

The Forbes article tells a great story, not on what can possibly cause the Panama Papers leak, but rather on what actually happens after the leak. After the hacker with a pseudonym of John Doe handed over the papers, the journalists had a huge problem in their hands: one with a volume of 11.5 million documents and 2.6 TB in size. The huge database had to be encrypted for confidentiality, and, at the same time, be accessible to a horde of journalists around the world. In addition, powerful text analysis tools were required to help make sense with that many documents. This article is a good read to find out how the journalists solved their big data problem with open-source solutions.


3. Five ways to speed up Drupal 8 sites (2.8k shares)

This article lists 5 ways to optimize the speed of a Drupal 8 website. Many of the tips are new and specific to Drupal 8 installations.


2. Panama Papers: Email hackable via WordPress, docs hackable via Drupal (3k shares)

WordFence is a leading web security company, and this article is their take on the Panama Papers leak. It illustrates how an intruder can potentially hack into the unpatched WordPress server hosting the Panama Papers, and from there, gain access to the corporate email server. It also summarizes how the outdated Drupal installation makes it easy for hackers to break into Drupal and steal documents.

More to this topic: 5 security modules that every Drupal website must have


1. How to configure your Drupal 8 ARM template deployment to Azure using existing MySQL Server (4k shares)

The most shared article about Drupal in 2016 explains the parameters required to configure Drupal 8 on the Microsoft Azure cloud computing platform.


The end of 2016 marks the first full year of Drupal 8.0 after its official release. With the buzz surrounding a major new release and some high-profile security flaws, the Drupal community was very active during the year. We are looking forward to more interesting blog posts in 2017. Don’t forget to share those ones you like most!

  Tags:  Drupal Planet drupal 8 Title:  12 most shared articles about Drupal in 2016

Google is leading the charge to a more secure web. The tech giant is taking steps in the way it handles non-secure websites in both search rankings and for its over 1 billion Google Chrome users. In search results, non-secure websites will now take a back seat to those that are secured with trusted SSL certificates. Texas Creative has answered the call by retroactively adding free SSL encryption to all of our Drupal websites.

What is SSL?

SSL (Secure Sockets Layer) is a web technology that creates an encrypted connection between the server and the browser to secure the data while in transit. Sites equipped with SSL signify this with a lock icon in the address bar. Until recently, you’ve likely only encountered this on your bank’s website or any site that is collecting personal information like credit card numbers.

Read More

آخرین ارسال ها

محتواهای محبوب

درباره ما

اینجا دروپال یعنی همه چیز. در مورد دروپال صحبت میکنیم. ماژول هامون رو به اشتراک میزاریم در مورد قالب دروپال ، فروشگاه دروپال، دروپال فارسی و تاریخ شمسی دروپال صحبت میکنیم و هرچیزی که در مورد طراحی سایت با دروپال میدونیم به هم انتقال میدیم. دروپالیون یک سایت شخصی نیست. ما دست همه کسانی که برای پیشرفت دروپال تلاش میکنند رو میفشاریم و با آغوش باز اونها رو در این سایت میپذیریم.

تماس با ما

با ما تماس بگیرید.