Drupal: Getting Paid to Do What I Love
I’ve been planning and working toward this moment for long time. The latest Webform feature is not for the community, it is for me. This new feature, which I’m calling "Promotions," provides me with compensation to do what I love: collaborate and build free software that is used by 1000's of websites.
Getting paid to write open source software is a known challenge. I’ve been exploring many options and researching how other open source projects promote and charge for add-ons, support, and additional services.
Promise: Free of Charge
Please understand I have no intention of ever charging for add-ons. That said, if people in the Drupal community started sponsoring features, I’d be completely on board. Is offering paid support a viable option? I’m not sure. I think promoting additional services is a proven approach. Many companies provide SaaS solutions and hosting services for Drupal. I’ve spent the past year learning how to promote myself via my website, blog posts, and presentations at conferences. Promoting myself in all these ways led me to recognize that my best opportunity lies directly within the Webform module's user experience.
Research: Promotional Banner
Ninja Forms for Wordpress has an amazing user experience. When installing Ninja Forms, there is a "Ninja banner" which promotes the plugin's latest features. I have never seen a Drupal module display a promotional banner or callout within the actual module. Project pages rarely contain promotional callouts. Banners and splash screens are part of the typical software experience. I realized I needed to sell the Drupal community on having a promotional banner within the Webform module's user experience.
Challenge: Selling...Read More
This is the first in a series of articles that will document lessons learned while exploring using Ember as a decoupled client with Drupal.
You will need to have Ember CLI installed and a local Drupal 8 (local development assumed). This initial series of articles is based on Ember 2.14 and Drupal 8.3.5 but my initial development was over 6 months ago with earlier versions of both Ember so this should work if you have an earlier ember 2.11 or so installed.
Drupal 8 is the latest version of Drupal that receives a lot of attention among Drupal community. Its minor release Drupal 8.3.0 has already come out. Each its feature is interesting and is described in our collection of Drupal 8 articles. In today’s blog post Drupal 8 will also be in focus, however from the angle of SEO.Read more
Drop Guard is in a continuous process of optimization and development. As it is still a unique platform concept on the market place, we started years ago with a sketchy blueprint of what Drop Guard is today - and rather will be in future. With this post I will give you a quick overview of what is planned and something which is a little secret between you and me.
Drop Guard Drupal Drupal Planet announcements
It’s a small developer-focused conference for architects, developers, and businesspeople who are involved in implementing decoupled Drupal architectures in their various lines of work.Anli de Jager Tue, 08/08/2017 - 08:45
This 2-day conference will create a platform for those involved in decoupled Drupal architectures to come together to share their knowledge and insights during a single track of sessions about decoupled architecture strategies, technology, and best practices. There will also be opportunities to contribute to the learning experience through the building of open-source projects in sprints.
Decoupled Drupal Sites not only bring exciting new technologies to us. They also require a new way of thinking around local development and hosting. At Amazee our speciality is Decoupling Drupal with React and GraphQL and we have multiple Decoupled Sites running, all with enabled Server-Side-Rendering, CDNs and Reverse Proxies included!
Our very own Michael "schnitzel" Schmid will, therefore, be hosting a session, ‘Your PHP and Nginx won't be enough to host and develop your decoupled site’ that will address some of these questions that will undoubtedly come up, for example:
How to develop Node locally with multiple Node versions, test CORS and Server-Side-Rendering locally and make overall sure that my Node App behaves locally the same as in production.
How do I deploy, test and host that on a server when using ServerSide Rendering of my Decoupled Site built in Node.
How to use a CDN to cache my GraphQL/REST/JsonAPI requests and also the Server-Side-Rendering response.
In this session, Michael will also show you how the power of Docker allows to develop Decoupled Drupal Sites with Node and Server-Side-Rendering with a breeze and also how to use the same Docker Tools to run them in staging and production. No Docker Knowledge required :)
For more conference updates, you can follow the action here.
(This article was cross-posted from Medium.)
Every few weeks I hear from a colleague who’s dealing with the tangles of editorial tools on a web CMS project. Inevitably, someone on their team suggests that things will be easier if users can’t enter HTML at all. “We’ll use Markdown,” they say. “It’s simple.”
On most projects, it’s a terrible idea — and I’m going to rant about it. If you don’t care about the nerdy details, though, here’s the long and short of it:
Markdown turns common “plaintext” formatting conventions like asterisks, indentation, and so on into HTML markup. If you need anything more complicated (say, an image with a caption or a link that opens in a new window), you need to mix markdown and raw HTML. Markdown is easy to remember for simple stuff (blockquotes, italics, headings, etc) but more complicated structures require extensions to the standard that are just as tweaky as HTML.
It was designed to mirror the ad-hoc conventions of ASCII-only channels like Usenet, email, and IRC. As creator John Gruber said in his original introduction of the project:The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.
Markdown’s strength is that it speeds and simplifies the most common text formatting tasks, and does so in a way that looks correct even before the markup is transformed into visual formatting. Markdown accomplishes that by ruthlessly cutting most HTML structures — anything that can’t be turned into a fairly straightforward ASCII-ism is left behind. When it’s pushed beyond that role, things get just as ugly any error-prone as raw HTML: witness the horrors of Markdown Tables and CSS In Markdown.
In many ways, Markdown is less a markup language and more a way to hide basic formatting information in a plain text document. That’s great! I use Markdown for my Jekyll-powered blog. If your project’s body field needs are simple text formatting without complicated embedding, captioning, microformatting, etc? Markdown is probably going to work fine. But — and this is a big one — if that’s all you need, then using a WYSIWYG HTML editor will also work fine.
WYSIWYG editors aren’t a pain because they “hide the code” from content creators. They’re problematic because they’re often configured to give editors access to the full range of HTML’s features, rather than the specific structural elements they really need to do their jobs. I’ve written about this “vocabulary mismatch” problem before, but it’s worth coming back to.
When you decide to use Markdown, you aren’t just choosing markup that’s easier to read; you're choosing a specific restrictive vocabulary. If that vocabulary covers your editors’ real needs, and they’ll be using plaintext to write and revise stories during their editorial workflow, by all means: consider it!
But if what you really need is a way to reign in chaotic, crappy markup, invest the time in figuring out how it’s being used in your content, what design requirements are being foisted on your editors, and what transformations are necessary for real world usage. Modern WYSIWYG editors don’t have to be the “dreamweaver in a div” disasters they used to be — taking the time to configure them carefully can give your team a clean, streamlined semantic editor that doesn’t constrain them unnecessarily.
Photo by Lee Campbell
If you want an easy way to create engaging, content-driven websites for you and your customers, you should give Drupal 8 a try. And Drupal modules allow you to take things a step further and create highly customized functionality for your site.
In our new course, Code a Custom Drupal Module, Envato Tuts+ instructor Derek Jensen will get you up and running with modules in no time. You'll build a simple calculator module, and along the way you'll learn about creating routes, controllers, parameters, and more.
You can take our new course straight away with a subscription to Envato Elements. For a single low monthly fee, you get access not only to this course, but also to our growing library of over 1,000 video courses and industry-leading eBooks on Envato Tuts+.
Plus you now get unlimited downloads from the huge Envato Elements library of 200,000+ photos and 26,000+ design assets and templates. Create with unique fonts, photos, graphics and templates, and deliver better projects faster.
Looking for a shortcut? Try downloading some of the ready-made Drupal themes on Envato Market.
Here is where we bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll investigate Style Guide, a module which gathers common elements in one place, allowing you to more efficiently determine which need to be styled.
Modal dialogs are incredibly useful on websites as they allow the user to do something without having to leave the web page they are on. Drupal 8 now has a Dialog API in core, which greatly reduces the amount of code you need to write to create a modal dialog. Dialogs in Drupal 8 leverage jQuery UI.
For a long time I’ve been compiling my Sass into a single CSS file - styles.css, but recently, with our component based design/frontend process and Drupal 8’s lovely Library system I’ve been wondering if the single file was still a good idea. Looking at the amount of unused CSS loading into any given page was a little bit painful.
Some Best Practices in Drupal 7's Optimization in Performance can be achieved..heykarthikwithu Sunday, 06 August 2017 - 22:09:58 - IST, Asia/Kolkata