Last week we were asked to disable the "threads" in the comments and display them as a plain list in one of our projects, so checking in the Comment field settings we found an option which says:
"Threading: Show comment replies in a threaded list."
Which basically display the comments as a threaded instead of a list of comments. This option is marked on by default, so it seemed that it was just a matter of unchecking this option, but there was a problem with this, that setting did display the comments as a plain list, but in the code they were still being saved as a thread.
The main problem with this is if a comment is deleted and it has replies (even if the option of the thread is unchecked) all the replies are going to be deleted as well.
This is not a new problem there is an 11 year old issue and it seems that this has been happening since Drupal 4. The way to fix this so far was by using a contrib module called: Flat Comments The problem is that this module hasn't been ported to D8 yet.
We decided to fix that and port the module to help others with this problem. You can check the code here: https://github.com/agaric/flat_comments and we are in contact with the module's maintainer to create the D8 branch in drupal.org soon.
Expecting that this can help someone else.
The monthly core patch (bug fix) release window is this Wednesday, July 05. Drupal 8.3.5 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.3.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.3.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.3.x commit log.
Other upcoming core release windows after this week include:
- Wednesday, July 19 (security release window)
- Wednesday, August 02 (patch release window)
- Wednesday, October 5 (scheduled minor release)
Let's picture this: you've created a custom content block type (let's say, Ad block) in your shiny new Drupal 8 installation and you want to automaticaly create a fresh new block of that type each time you create a taxonomy term (Ad group), so that every ad group has a ...
Hi, fellow Drupalers. Today, I’d like to share with you a project of ours that allows automating web server setup for Drupal-powered websites.
At Drupal Admin team, we often set up and fine tune servers for Drupal websites, so it was only natural for us to develop a routine that automates the related processes. We picked Ansible configurations management system for initial setups and further servers maintenance.
Why Ansible? This systems allows:admin Tue, 07/04/2017 - 07:19 Теги
Today's new release of Drupal Remote Dashboard (DRD) introduces a big new feature which allows anyone to manage Drupal site updates in a protected and automated framework without having to get any third party involved in the process. Just in time for Independence Day, July 4th 2017. For Drupal site owners this brings independence from external service providers without compromising quality of service or reaction time.
Throughout the first month of GSoC, my mentors Skyred and Naveenvalecha and I worked on the feasibility and worth of integrating Google Cloud Machine Learning Engine to Drupal. We have used Googles php library to interact with ml-engine to perform training, deployment and prediction. When we complete this project successfully, we can use data in Drupal for predictions and analysis similar to the one shown in this video. We have created a prototype of this integration. Please see the video demo below.
An ML task has three parts, training, deployment and prediction. In this demo, we have created an app with Drupal that can perform these tasks in few clicks. We have used the data in Drupal to get predictions for future data, powered by ml-engine.
Digging deep into it, we have used Views to select the required data and a contributed module, View Data Export to get it as csv. Our automated task runner get it by HTTP request. With the data in hand, Google Cloud Storage service we added to Drupal will upload it to Cloud server. Now the ML engine can access it. We use ml-engine jobs, model and version API for training and deployment. Our module will set up a Cron job to update the status of these tasks in the background. Finally, we can use the model and version names to predict the probabilities.
Jobs API returns the status of the training job, whether it is running, completed, failed etc. The training data is an argument to the trainer python code, so we don't get the accuracy in the response. We need to access the log in Google Cloud Console to obtain it. Here is screen shot of the job's log.
The Google Cloud Console provides a detailed log of the tasks. Towards the top, we can see the training iterations (evaluations) whose count can be set while setting the job. More the number of iterations more is the chance of high accuracy. Towards the middle, highlighted in blue, we can see the accuracy. This process had an 83.1 percentage accuracy.
Now let us see the prediction part.
In this demo, our task was to predict the income bracket (category) of the person given his education, age, marital status etc. The income bracket is a binary attribute, whether it is greater than 50K dollars or less than 50K dollars. This is a prediction screenshot we got for the person attributes,
"workclass": " Public",
"education": " 11th",
"marital_status": " Never-married",
"occupation": " Machine-op-inspct",
"relationship": " Own-child",
"race": " Black",
"gender": " Male",
"native_country": " United-States"
Here, in the probabilities sub array, we have two indices. As I said this is a binary attribute, we have the zero'th index corresponding to income bracket less than 50k and index one greater than 50K income bracket. Just see the category index set in the python code.
The screenshot indicated that there is a 98% chance that, this person has an income lesser than 50K.
Finally, to conclude, we have successfully worked on creating a prototype on integrating Google ML Engine to Drupal.
Editors have always been able to choose a specific Image Style to use when embedding images in content with CKEditor, but it required quite a bit of setup by the site builder. Specifically, the site builder needed to create a view mode for each image style and then configure the view modes so that they would display the appropriate image style. Those view modes were then exposed as display plugins to Entity Embed. So the site builder then needed to configure the Media Browser embed button to allow those display plugins.
Once this was all done, editors would see a select list in the Entity Embed dialog that allowed them to choose which View Mode should be used for the embed:
In 2.1.6, Lightning introduced a new display plugin that allows editors to select an image style, alt text, and other settings each time you embed an image with CKEditor, rather that needing to rely on view modes.
When Lightning detects that an image is being embedded, it will automatically select this new display plugin (Media Image). The embed dialog, using the new display plugin, looks like this:
New installs of Lightning will also hide the "Diaplay as" select list and the manual update instructions for 2.1.6 suggest that existing sites do the same. We created an option to leave the existing behavior though for sites that have an established workflow that includes selecting view modes for embedded images.
See the 2.1.6 Release Notes for more information.
One of Drupal’s biggest strengths is its flexibility and extensibility, allowing developers to create, for example, custom-tailored editorial workflows. In this article, we will examine Entity Browser, a powerful component of Drupal’s contributed ecosystem of modules for managing digital media assets.
To make it easier to follow along with the article, let’s consider two fictional characters: Bob, who works as a copy editor for a big news website, and Sylvia, the Drupal developer in charge of the website Bob uses to do his job.
Bob is not very happy with the current solutions he has when editing an article, because:
- When uploading an image, he is unable to re-use an image uploaded in another article.
- When uploading an image to a gallery field, he has to upload them individually, and he wishes he could bulk-upload several images at once.
- When Bob needs to relate articles, he uses an auto-complete field which only accepts the title, forcing him open a new tab to search for articles by author, category or date, because he doesn't remember all past articles' titles by heart.
- Sometimes Bob wants to relate an article to a “quote” content type that doesn't exist yet, but he is going to create. Now he needs to stop his work, open a new tab, create the quote content, come back to the article, and then reference the quote. It bothers him a little bit having to switch so often between tabs and contexts.
- Other things (Bob always wants more).
Sylvia knows how to solve all those needs, but she is not satisfied because the solutions she previously used in Drupal 7 were not standardized, sometimes “overkill," and often difficult to maintain and extend. However, she heard that the Entity Browser module solves all these needs (and more) in a generic and powerful way.undefined
Sylvia already discovered that this module was deliberately created with a very abstract, flexible and “pluggable” architecture. While this allows for powerful tools and workflows to be implemented, the price is often an increased learning curve about how to properly configure it for the different user needs.
This article is intended to help Sylvia (and you) discover Entity Browser. Here you will find:
- A brief description of the architecture of the module and the central concepts with which you need to be familiar.
- A list of “browser” examples that can help you understand what is possible.
- A step-by-step tutorial for configuring a browser from scratch, identifying common pitfalls that often occur in that process.
Note: The following description uses concepts and terminology not very easy to understand at first sight. It’s OK if not everything is 100% clear after the first read. The configuration steps below will certainly help you confront this challenge. In any case, I would highly recommend you take the time to go over the documentation indicated in each of the links below and check the examples there. It's always easier to grasp the concepts with some images and real examples.
If this is your first contact with the Entity Browser module or if you are still wrapping your head around its configuration, there are some key concepts that you should start familiarizing yourself with, indicated below.
The “browser” is a configuration entity that can be created through the UI by the site-builder, or imported from a configuration YAML file. This config entity will base its behavior on the settings defined by the following four plugins:
- The Display plugin, which is responsible for presenting the entity browser to the end user (editor), in different contexts. Examples of this are “iFrame” or “Modal.”
- The Widget plugin, which is the tool the editor will use to effectively browse/search/select or create the piece of content they are looking for. Examples of this plugin that ship with the module is “File Upload” or “Views.”
- The Widget Selector plugin, which as the name suggests, is responsible for providing a mechanism for the end user to select a specific widget, among a set of available ones. Selector examples could be “Tabs” or “Dropdown.”
- The Selection Display plugin, which allows a “temporary storage area,” where the editor will be able to have visual feedback about the entities they've selected.
Check some existing examples…
Once all these are plugins, other contributed modules (and also your custom code!) can easily provide new ones. So don’t be surprised if at some point you encounter more options than the ones listed above.
Many modules and distributions showcase what is possible to build using Entity Browser. The following video is based on the File Entity Browser module, which provides a pre-configured browser, along with some nice front-end adjustments.Videos require iframe browser support.
This is an excellent way to become familiar with the module and the different use cases. These are some of the existing examples you can explore:
Modules that provide pre-configured browsers:
- File Entity Browser (for managing files and images)
- Content Browser (for managing nodes)
- Media Entity Browser (for managing media entities, when using the Media Entity module)
- Entity Browser Enhance(d|r) (improves the styling of the views being used as widgets)
- Slick Browser (uses the slick library to provide some nice UX improvements on certain browser plugins. Compatible with several entity types: files, images, media entities, etc.).
Full-featured Drupal distributions that showcase entity browsers:
Even if you are using one of the pre-packaged solutions mentioned above, it’s always good to understand how things work behind the scenes. For that, there’s no substitute for creating an entity browser from scratch and seeing for yourself all of the details involved. Doing this will help you discern whether a packaged solution or a custom browser will best address the particular use case involved in your project.
To create a browser from scratch, the first thing to do, after enabling the module, is to navigate to:
Configuration -> Content authoring -> Entity browsers
or go directly to the URL /admin/config/content/entity_browser and click “Add Entity browser”undefined
The module does not depend on the Ctools module to work. However, the multi-step wizard that helps you create and edit entity browsers using the UI does. This means that in order to create a browser as shown here you need to have Ctools enabled on your site. It’s not necessary to leave it enabled afterward though. Once your browser is finished, and no modifications are foreseen, if you don’t need Ctools you can safely disable it in your production environment.
The wizard will walk you through five steps, each of them intended to define the configuration options for the different plugins we saw before.Step 1 - General browser configuration undefined
In this step, you define the basic configuration of your browser, and depending on what you choose here, some of the subsequent steps may not need any configuration or will ask for different information.
If you are in doubt on what to choose here, the default values suggested may be just fine for many use cases. In our case, to make the most of the example, we will select:
- Modal display
- Tabs selector
- Multi-step selection display
If you plan to use this browser as part of an embedding workflow using the Entity Embed module, you must choose the iFrame display plugin.Step 2 - Display configuration undefined
This step will ask you for some information that refers to the display type you selected in the first step.
In our case, we are asked to indicate the width and height of the modal window, the label of the link/button to launch the browser, and an option to automatically open the browser, when possible (not always recommended).
For our example, we will leave the defaults.Step 3 - Widget selector configuration undefined
Because we are using the “Tabs” widget selector type, there's no additional configuration needed.
Note that when using the multi-step wizard, the config values won’t be effectively saved until you go to the last step and click “Finish”. Even if some steps have no configuration, or you just want to edit the configuration of a single step, for now, you always need to go to the last one and click “Finish”. You can refer to this issue if you want to help to improve this.Step 4 - Selection display configuration undefined
Because we selected “Multi-step” in a previous step, we have some configuration to do.
In our case, we will define that we'll be working with “File” entities (images), and this “work-in-progress zone” for the entities selected (the Selection display) should show the images as Thumbnails, using the “Thumbnail (100 x 100)” image style.Step 5 - Widgets configuration undefined
This is the final and most important step to configure our browser. Here we will add as many widgets as we want to expose to the user when they are using the browser.
In our example above, we have added two widgets:
- Upload: which will allow the user to upload a new image to the site
- View: allowing the editor to select a pre-existing image from a gallery (which is a view you can customize as well)
When using a view as a widget, not all views can be selected here. You must have created beforehand a view with the following characteristics:
- It shows entities of the type being selected by this browser
- It has a display of type “entity_browser"
- It has at least one field of type “Entity browser bulk select form.” This is what will make the checkboxes appear and allow the entities to be selectable.
As long as these traits are present, the view can do any additional filtering and show any information you want to make the selection process easier.
View widgets have an additional setting “Automatically submit selection” intended to save the user one click when sending the entities to the “work-in-progress selection area.” Note though that this option should only be used when the Selection Display is set to “Multi-Step.” Failing to do so may produce an error on your site such as:
Drupal\Core\Config\ConfigException: Used entity browser selection display cannot work in combination with settings defined for used selection widget. in Drupal\entity_browser\Form\EntityBrowserForm->isFunctionalForm()
You can refer to this issue if you want more information or are interested in helping the site-builder experience here.Browser created. Now what?
Now you can use it! As mentioned before, there is a lot of abstraction involved so that the browser can be used in many different contexts. Maybe one of the most common scenarios is to use the browser as a field widget to populate entity field values, but the same browser could also be used to support embedding workflows, in a custom form that you build yourself, or other scenarios you can think of.
Moving on with our example, let’s consider we have a node content type (let’s say the “Article” content type) with an image field where we want to stop using the default core upload widget and start using our brand-new browser instead. All we need to do is head over to:
Structure -> Content types -> Article -> Manage form display
or go directly to /admin/structure/types/manage/article/form-display to change the field widget settings.undefined
Click on the dropdown, select “Entity browser” and then click on the cog on the right to open the browser widget options.undefined
Different browsers may have different options here. In any case, the most important operation you want to perform here is to select from the dropdown list the entity browser you want to use.
Once done, your node creation form should have been updated to use the new field widget!undefined
When you click on “Select entities”, your browser will open:undefined undefined
Note that, as expected, we have two widgets (labeled here “upload” and “view”), displayed as Tabs, presented to the user in a Modal window.
As seen above, the browser is a “piece” you configure and then plug into other parts of your site. Once it is very abstract, sometimes you can still plug it into some places, but it won’t work if the configuration you created for the browser is incompatible with the context you want to use it in. The following are two examples of this:
Misconfiguration scenario 1
Widgets don’t enforce entity types based on the context they are used in. This means that you could potentially use a widget to select an entity of a type incompatible with the field where that widget is being used, resulting in an error such as “The entity must be of type <type>”. You can refer to this issue for more information on this situation.
Misconfiguration scenario 2
Field widgets have a setting that allows you to define how the selection should be handled during the update process. This is called “Selection mode” and you can choose between the options “Append to selection,” “Prepend selection,” and “Edit selection”. As somewhat expected, if you choose an option like “Edit selection,” your browser must have been configured to have a “selection” available, which currently is only possible with the “Multi-step Selection Display” plugin. For example, if you choose the “No selection” plugin in the browser configuration while leaving this “Edit selection” setting on the field widget, you will end up with an error such as “Used entity browser selection display does not support pre-selection.” You can refer to this issue for more information on this.
As you can imagine by now, there are many opportunities to add variations to the process and to the final result. Your view can have other filters, show the elements in a grid instead of a table, etc. The definite best way to understand all capabilities of this tool is to play around with it yourself and explore some examples provided by others.
DropzoneJS is a very nice open-source library that improves the user-experience for file uploading. You can replace the standard Drupal upload widget…undefined
... with a more user-friendly drop zone area:undefined
At the moment of this writing, the module DropzoneJS only provides the widget shown above to be used inside entity browsers or other module integrations. After this issue is solved, you’ll be able to use it stand-alone in normal Drupal fields too, if you don’t want to have an entity browser around.
Did you know that…
In Drupal 8 the standard file upload widget can handle multiple files and drag-and-drop out of the box?undefined Create entities “on the fly” with the integration with Inline Entity Form
One very powerful integration of the Entity Browser module is with the Inline Entity Form contributed solution. This will allow you to use the very same entity creation form as a widget in your browser.
Please refer to the documentation for more details on how to configure the two ways in which this integration can be implemented on your site. The important thing to keep in mind here is that this can open the door for creating related content without having to leave the main context!Videos require iframe browser support. Conclusion
I hope this article helped you (and Sylvia!) in identifying the possibilities behind Entity Browser, and some of the most common issues when configuring it.
Do you have anything else you wish you knew when you first tried it out? Join the conversation! Please leave a comment below and let’s reduce the learning curve together.Acknowledgements
- Ways to help the D8 Media initiative
- How to Embed Just About Anything in Drupal 8 WYSIWYG with Entity Embed and URL Embed
Hero Photo by Barn Images
This blog post summarises my fifth week of working with Google Summer of Code 2017 with Drupal.Sandbox to implement the file encryption
This week I created a sandbox page in the router to test standalone file encryption. It utilised the HTML5 FileReading API to get the contents of the selected file that needs to be encrypted.
var reader = new FileReader();
An alternative would be:
var reader = new FileReaderSync();tameeshb Wed, 07/05/2017 - 23:05 Tags GSoC Google Summer of Code 2017 Drupal Drupal Blog
The new drupal database API (known as DB:TNG) is built atop PHP's native PDO engine. The main objective behind Drupal’s database API is to allow developers to write one query that will work across different types of databases. So instead of writing specific queries for MSSQL, PostgreSQL, MongoDB, you can write one query. Then, a plugin is written to translate that query into native style and write the query in the initial language which is Database Abstraction layer.
What are the new changes in Drupal 7’s new database API?
One of the biggest changes is Drupal 7's new database API, an object-oriented system which change the way most developers will build…
The first phase evaluation of GSoC'17 is over. I had been working on integrating Google Cloud ML Engine to Drupal. Till now we have worked on creating a demo with Census example to illustrate that we can make predictions for our data in Drupal with ml-engine. Please check my first evaluation blog for details. After the evaluation, we worked on integrating standard pre-trained Tensorflow models to Drupal.
Pre-trained models are machine learning models trained on some dataset. As data is the key to classification accuracy, most of the standard pre-trained models available are trained on huge datasets. Our primary source of research was tensorflow/models. This repo had around 30 models but most of them needed training. In my inquiry, we found that Tensorflow lacks a gallery of trained models. Let me provide the link to some of the pre-trained models found.
Name link study Inception gz file Inception is an image recognition model trained on imageNet (a hierarchical classification of millions of images). It classifies the image into thousands of classes. Users have to do transfer learning to get their custom classes. VGG tar.gz file VGG(Visual Geometric Group) is a deep CNN developed by Oxford for image classification based on ImageNet. It is a model similar to inception. https://www.quora.com/What-is-the-VGG-neural-network Syntaxnet blog1 and hblog2) for details. Facenet MS-Celeb-1M and CASIA-WebFace. Please check this report for details.
Finding lack of good pre-trained Tensorflow models is a serious drawback. Most of the natural language models we found needs training. For example, Syntaxnet is a highly accurate language parser. But we need to train on top of this to create a custom model for text summarizer and models useful for the end users. We don't have many ready-to-use natural language models suitable for Drupal.
To use standard models for our project, we have to do transfer learning. It is learning on top of what is already learned. In the Tensorflow for poets example, we remove the last softmax classification layer and train a layer on our own, for custom classification. Please refer to this in-depth video on how to create a custom image classifier.
The major challenge we face is to create an abstraction to transfer data, train model, and to do the prediction for a variety of data types. We have to give the user flexibility to use any type of data (image, nominal, ordinal, numeric, ...) for training and prediction with ml-engine. For that, we have to create an abstraction that handles all data types. In the coming week, we will be exploring on how to create this abstraction.
DrupalCon Vienna is approaching quickly and if you haven’t done so far, it’s a good time to book your travels and accommodation. Even for an insider it is hard to keep track of everything that is going on, so in this post I would like to share an overview of what’s planned so far to keep in mind when planning your stay in Vienna.Josef Dabernig Thu, 07/06/2017 - 08:47
Until Sunday, 24 September - Cyclists will be gathering again on the way to DrupalCon as part of Tour de Drupa Vienna. The Danube river allows for scenic flat rides from the west (Germany - Linz - Krems - Tulln - Vienna) or east (Budapest - Bratislava - Vienna). On Sunday 11am we will be meeting at the webshapers office in Tulln and in the afternoon cycle the last 40 kilometres together along the Donau to reach the Riesenrad in Vienna at 6pm. Join the conversation on g.d.o to get all the details.
Monday, 25 September - Drupal Austria together with the global Drupal Community are organizing summits and trainings. Those who have been to the DrupalCamps in 2013 or 2015 will remember FH Technikum Wien being supporter and host of these community organized activities. In terms of summits, we are planning for a great variety: Community Summit, Publishing Summit, Business Summit, Open Social Summit.
On the trainings side we are currently planning for a Docker workshop and a Drupal 8 module development course. Finally, there will be room for sprints thanks to sponsorship from Acquia and a CXO Dinner in the evening. Here’s some more information about the Monday program.
Tuesday, 26 September - The day kicks off the official DrupalCon program with the keynote by Dries Buytaert, Drupal Project Founder and will start 3 days of sessions, BoFs and social events. In the evening there will be the Open Minds Award (a regional open source award) and a ball celebrating Open Source as the official community party.
Wednesday, 27 September - Together with the keynote, other sessions and BoFs, there will also be the Drupal Association Public Board Meeting as well as the Women in Drupal social event and a CEO Dinner.
Thursday, 28 September - So far confirmed is that there will be Drupal Trivia Night. More details to follow as soon as it’s available.
Friday, 29 September - This is the last day of the conference and it’s all about Sprints: Join the community to learn how you can contribute to Drupal.
This sums up the main activities planned so far for DrupalCon Vienna. Alongside of the official important dates, hopefully this helps you to plan and organise your visit. Speaking from my own experience, DrupalCon with thousands of community members attending is a very special event: basically a week full of events. The above is only what we are aware of so far, you can be sure that various other individual events will be organized along the way.
Apart from the conference, Vienna has a lot to offer. If your schedule permits, I would definitely recommend adding a few days to explore the city. Some suggestions and ideas can be found on the official DrupalCon Vienna travels page. See you in Vienna.
A month ago I received the honour to present at DrupalJam 2017. What a wonderful event! I had been invited to talk about deploying Drupal 8 onto kubernetes, which can be found as a hosted service in Google Cloud.
Our move to Google
Recently, we made the decision at Dropsolid to move from regular virtual machine instances in Gandi towards instances and services in Google Cloud, as we believe that the capabilities of such a cloud provider offer possibilities that are unprecedented. GC is not only offering affordable virtual machines (instances) but also affordable and competitive offerings regarding hosted MySQL. But that’s not all... Since we like our R&D environment and are looking for achieving greater and bigger goals, it is in our interest to see that Google is publishing new AI and data-analysis APIs at a pace that we don’t see anywhere else.
So... Back to the technicalities. I wanted to run an experiment on how I could run Drupal on an infrastructure that did not need any humans behind the wheel, nor any maintenance. I found this in the way of three components:
- Kubernetes as a service
- Pre-built Docker/LXC containers from Wodby, including a webserver stack (PHP, Nginx)
- MySQL as a service
An overview of Kubernetes and the setup can be seen in the following video:
One component that I found to be missing, was a shared filesystem between the two ‘Pods’ (Containers). Drupal relies on user files or images and these should be stored somewhere. We do not want to alter the behaviour of Drupal or get into the application itself, as that introduces risk. Not all the websites that we would like to host, are modifiable.
- We could map the folder to an AWS S3 bucket or Google Cloud Storage bucket, but that would be too slow for our needs. What we actually wanted is a competitor of AWS EFS, but unfortunately Google Cloud did not have this available.
- We can work our way around it by setting up a NFS server or Gluster server in kubernetes, but that drives us away from our initial goal - less maintenance, so we can focus on building awesome experiences, which is the Drupal application.
If you are interested how I did the setup of the NFS, the slides go into deep detail how to set up this NFS cluster. The code is also available at https://github.com/nickveenhof/drupal-docker-with-volume
I recorded a video how this deployment works. Caution, I did speed it up quite a bit.Key findings
Now, what is the key take-away from all this? That I moved the particular website back to regular hosting, eg a shared space with a human behind the wheels here at Dropsolid. The reason was that for a single site, the cost outweigh the benefits and even though it is claimed to be fault-tolerant, I had numerous occasions where my pod did not want to recover, since the ‘failed’ one refused to be deleted. This ate up precious CPU space - on a server that barely had enough CPU. This can be solved with throwing more money at it, but that was not the intent.
I also discovered that constraining a pod to a fixed amount of CPU is not very useful when sharing a single server between multiple Drupal sites. Websites can have variable load and for small to medium sites with little traffic it is hard to justify the cost of pre-allocating those resources. I am curious to explore and test the Vertical Pod Autoscaling once they are finished, as this could certainly help applications with burstable workloads.
Having said that, I did learn a lot about what the future could hold. Going towards a system like this gets us really close to the 12-factor app ideology and I am completely in favour of a future like that.
Comments, questions? I'm curious to find out your take on this. Let me know in the comments box below or reach out directly on Twitter via @Nick_vh
Make sure to check out my the slides from this presentation here:
How to setup Multiple Drush's in your machine, to manage the drupal 6, drupal 7 and drupal 8 sites..heykarthikwithu Thursday, 06 July 2017 - 14:06:12 - IST, Asia/Kolkata