Blog posts

    … since the 2 frameworks are frustratingly similar. Their key features and provided functionality often overlap. So, you had better ask yourself, first things first: what are your development needs? Which is the main purpose that you need your framework to serve, whether it's WCF or Web API? This is THE question! Is it an internal web service or an external one that you need to develop? As you can see: it takes just one key question to entail one relevant and effective question after another. Questions that will lead you to the answer to your “thorny” dilemma...
    "And it's been right there, under my nose, the whole time!" This is you after I've revealed to you the solution to this "problem" (and this was my reaction, as well): how do you alter the out-of-the-box styling of your WYSIWYG editor in Drupal 8? How do you apply your own CSS styles without automatically modifying the CKEditor plugin settings (and without providing classes in the "Styles" menu)? It looks like the simplest solutions are both the most effective and the most difficult ones to notice. And where do you add that for this...
    Guess who's ready to be taken out for a “test drive”? The shiny and new (and still under intensive updating) Node.js 9! An "earlier" Christmas present for all those developers who're confident in the Node.js project's steady growth and who're still blown away by its high-impact features (think unmatched scalability, think superpower, think a heavy libraries collection at your full disposal...). So Node.js 9 turns into Node.js's current release line, becoming available to eager developers (like us) who're dying to take it for a spin...
    Power to the Drupal themers! Which implicitly means more power poured into the Drupal 8 sites that they work on, right? And this is precisely the driving principle behind the revolutionary theming experience and the asset library system in Drupal 8! Admit it now: are you still stuck with the never-gets-old “compiling SAAS into one single CSS file" (for your theme/module)” technique? Into the “one man show” type of library asset that should handle EVERYTHING? Which means that you allow (just be honest!) for unused JavaScript, as well, to get loaded and to...
    So you want them multi-leveled, usability features-loaded, packed with accessibility enhancements and (most of all) interactive, right? No problem! There's an easy way to build large, feature-rich drop-down menus in Drupal 8, and I'm talking about menus with a "splash" of jQurey "magic" added to, as well: the Superfish module! So, why should you trim down your expectations when you can meet them all? Since the module integrates the jQurey Superfish menu plugin with your Drupal site, why shouldn't you inject extra functionality into your menus? Why shouldn't you accept the "dare" to...
    What to expect from the “shiny new” Drush 9? The very first major Drush re-write in years (since 2008, to be more specific)!!! What's new and improved and what remains unchanged? How will this new version of Drush speed up your dev tasks even more and how much time and effort do you need to invest in getting into gear with it? Embracing a Composer-centric philosophy... switching to annotated Drush 9 commands... gradually moving away from CLI code to Symfony Console... And these are but some of Drush 9's buzz-generating changes.
    September 20, 2017! For most of us it was just an ordinary Wednesday, yet for the Drupal community and for everyone owing (or planning to own) a Drupal e-shop it was a major release day marked in their calendars: the stable version of Drupal Commerce 2.0 for Drupal 8 was launched into the wild (following no less than 6 beta "teasers") at that date! And along with it, 2 key promises were put forward: the whole Drupal commerce experience will be redefined and development teams will get more productive (since this new version of Drupal Commerce performs remarkably at scale)...
    What makes Node.js work so well in a serverless environment? Is it its lightness? Or its “plays well with all OS's” feature maybe? Or is it its high accessibility translating into a wide pool of developers for you, as a service technology(s) vendor, to select from? Is it the accessibility (again) which, empowers you, the developer this time, to break the skill level restriction and the back-end vs front-end strict delimitation? Why should you build out your serverless app with Node.js? As the headline clearly states, I'll start this post already presuming that...
    Let's play a little empathy game! One which will help you realize why you do need to bother making your Drupal admin UI content editor-friendly: Step into the shoes of a first time Drupal user, of an inexperienced content editor accessing your Drupal site's admin interface for the first time. What do you think? Is that intricate network of forms loaded with “alien” terminology and the “specific” clutter of defaults in the Drupal 8 admin user interface…“ welcoming” enough for you? So, what's your opinion, from your standpoint as a Drupal...
    It's got modular codebase, a whole new architecture, it comes “packed” with lots of new advanced solutions for rich text editing and (well, what do you know!) real-time collaborative editing. In short: in CKEditor 5's case we're talking about a totally new product when compared to its predecessor, Cheditor 4, that we've been using in Drupal 8. Looking forward to seeing the real-time collaborative editing features (in particular) brought to Drupal 8. And to be honest I look forward to an in-browser editor with an equally user-friendly interface, the same approach to...