Lullabot: Bitmasks in JavaScript: A Computer Science Crash Course

One of the nice things about front-end web development as a career choice is that the software and coding languages are available on every modern machine. It doesn’t matter what operating system or how powerful your machine is. HTML, CSS, and JavaScript will run pretty well on it. This lets a lot of us in the industry bypass the need for formal education in computer science.

Unfortunately, this also has the side effect of leaving little gaps in our knowledge here and there, especially in strategies like bitmasking, which are seldom used in web development.

Lullabot: The Dangers of Inline Editing Structured Content

In our previous article, we went over the basics of how Drupal handles revisions and content moderation. But one of Drupal's strengths is what we call "structured content" and its ability to implement complex content models, as opposed to a big blob of HTML in a WYSIWYG field. Entities can have lots of different fields. Those fields can refer to other entities that also have lots of other fields. It is easy to establish content relationships. 

Lullabot: The Basics of Drupal Revisions and Content Moderation

Out of the box, Drupal offers some great tools for content moderation and basic editorial workflows. It is simple and flexible by design because there is no one-size-fits-all solution for every organization and editorial team. Drupal prefers to provide the tools. Your team can figure out how best to use those tools.

Publishing workflows and strategies are complex subjects, but we'll go over the fundamental concepts of how Drupal handles these concepts.

Lullabot: Making the Most of Display Modes In Drupal

One of Drupal's biggest strengths is the ability to define structured content, then display and edit it in a variety of ways without duplicating development or design work. "Display Modes" have always been a big part of that power. One piece of content can be displayed as a Teaser, as a Full Page, as a Search Result, and so on — each with its own markup and field presentation.

Specbee: The Dynamic Duo: Exploring Decoupled Drupal + React Connection

Now there are two types of people in the sandwich universe - people who like to order a sandwich off the menu and people who like to customize their sandwich by choosing their bread, filling, and sauce. We’d like to call the latter, ‘Sandwich Mavericks’, who would (most likely) prefer their websites to be as unique as their custom sandwiches. They’re not tied down to a specific front-end technology, or limited by templates and themes provided by the CMS. A Decoupled Drupal CMS architecture lets you be the architect of your web destiny. If you’re not craving a sandwich yet, jump into this article right away to learn more about Decoupled Drupal and using React as the front-end technology to craft absolutely delicious web experiences that your audience will love. What is Decoupled Drupal? The term decoupled means to be detached or separated. In terms of Drupal, it refers to a detached frontend from the Drupal architecture. Hence in a decoupled Drupal architecture, the contents are managed by Drupal and the frontend can be any frontend technology like React, AngularJS, VueJS, etc. Decoupled Drupal is also known as headless Drupal. Traditional CMS VS Decoupled CMS Some key differences between traditional Drupal and decoupled Drupal: Traditional Drupal uses Twig as the frontend tool, while decoupled Drupal can use any of the previously mentioned modern frontend technologies. Traditional Drupal provides us with many out-of-the-box features like content preview, layout builder, etc. In decoupled Drupal, it will need extra effort to build these features. Traditional Drupal has average page speeds, whereas decoupled Drupal has average to fast page speeds. Traditional Drupal uses monolithic architecture, while decoupled Drupal can use both monolithic & microservices architecture. Tech complexity is average in traditional Drupal, whereas in decoupled Drupal it is highly complex. Image source: drupal.org Should you consider decoupling Drupal? Choosing between the two isn't a straightforward decision. It depends on various factors, with a key one being that decoupled Drupal is more intricate and requires additional effort to replicate many features that come prepackaged with Drupal. This can lead to increased development costs and heightened technical complexity. However, it also allows you to seamlessly incorporate Drupal into various modern technologies such as single-page applications (SPAs), mobile apps, configuration-based user interfaces, IoT and offers reusable content capabilities. How does Drupal support headless As Drupal employs an API-first architecture, we can utilize its backend structure to store and deliver content through APIs. Drupal's core natively supports JSON:API/REST API, enabling us to present content as JSON and communicate with front-end technologies via REST. To know which one to choose: JSON API vs REST API vs Graph QL, you can refer to this article. Creating a decoupled Drupal with React Let’s get down to business and start building a decoupled Drupal project with React. This is what your Project folder structure will look like: Under the root directory, we are placing our Drupal project and React app. Sidenote: here docker-compose.yml  is for managing the docker container created for Drupal and the React app. Our Drupal project is created using:  composer create-project drupal/recommended-project my_site_nameAnd our React app is created with: npx create-react-app my-appSetting Up the Drupal application Step 1: On the Drupal side we need to configure a few things to get started: a) Enable CORs settings in services.yml # Configure Cross-Site HTTP requests (CORS). # Read https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS # for more information about the topic in general. # Note: By default the configuration is disabled. cors.config: enabled: true # Specify allowed headers, like 'x-allowed-header'. allowedHeaders: ['*'] # Specify allowed request methods, specify ['*'] to allow all possible ones. allowedMethods: ['*'] # Configure requests allowed from specific origins. Do not include trailing # slashes with URLs. allowedOrigins: ['*'] # Sets the Access-Control-Expose-Headers header. exposedHeaders: false # Sets the Access-Control-Max-Age header. maxAge: false # Sets the Access-Control-Allow-Credentials header. supportsCredentials: trueb) Enable Rest, Rest UI, Serialization modules By default, Restful Web Services & serialization modules are present out of the box in Drupal 9. You need to install Rest UI (which is a contrib module). composer require 'drupal/restui:^1.21'c) Click the configure settings on the Rest UI module. Then enable the “Content” Resource name.   When this is enabled, it converts the data received from Drupal into JSON. Step 2: In order to access it, go to any content page, like here we are opening an article page.   Now if you add ?_format=json query parameter, it will show the data in JSON format ( a feature of RESTful Web services). Step 3: Now let's create a view with the latest articles on Drupal (see screenshot) A few pointers on the creation of the view.a) Create a “rest export” view. This will be used for passing out our latest articles data to our React app. b) Under path settings, authentication is provided as a “cookie”. We can also use basic auth (i.e. verification with username/password). For that, you need to install the basic auth module. For this demo, we are only using cookie-based authentication since it is more user-friendly when working with mobile applications. Step 4: Once created, visit the view url (here: /articles/latest). You will see the data formatted into JSON. Note: You don't need the _format=json parameter for this view page. Setting Up the  Frontend Application (React) Now that we have set up our Drupal site, let's begin creating out React application. 1) Folder structureSince we are using create-react-app, it provides us with the boilerplate code to get started with react. Sidenote: It is better to use Vite than Create-react-app for improved performance. 2) Create the frontend scaffolding    React APP {setIsModalOpen(true)}}>Add Nodes {setIsModalOpen(false)}}>X Title setFormData({...formData, title: e.target.value})} value={formData.title}/> Short Description setFormData({...formData, shortDesc: e.target.value})} value={formData.shortDesc}/> Body setFormData({...formData, body: e.target.value})} value={formData.body}> If the structure feels overwhelming, worry not. There are mainly two components: Results - renders the result from the API call. Article - the article items on the listing. Results.js const Results = ({articleUpdated, setArticleUpdated}) => { // article listing state. const [articleList, setArticleList] = useState([]); useEffect(()=>{ const relative_path = "/articles/latest"; // adding intensional delay for UI. setTimeout(() => { getData(relative_path) .then(res => setArticleList(res)) .catch((error) => {console.log(error)}) }, 1000); },[JSON.stringify(articleList), articleUpdated]); return ( { articleList?.length === 0 ? : { articleList?.map((curr,index) => { return ( ) }) } } ) } export default Results;  Article.js // article item component. const Article = ({title,shortdesc,nid, ds, articleUpdated, setArticleUpdated}) => { const handleDelete = (nid) => { deleteData(nid) .then((response) => { if (response.ok) { setArticleUpdated(articleUpdated + 1) } }) .catch((error) => console.error(error)) } return (

{title}

{shortdesc}

{handleDelete(nid)}}>Delete ) }The Results component uses getData() and postData() to get/post data from Drupal. getData()  export async function getData(relative_path, query_params) { const hasQuery = query_params ? "?" + query_params : ""; const generated_URL = endpointUrl + relative_path + hasQuery; try { const res = await fetch(generated_URL); const get_response = await res.json(); return get_response; } catch(error) { console.error(error) } }postData() export async function postData(data_to_post) { try { const response = await fetch(tokenURL) const csrf_token = await response.text() const post_data = { "type": [{ "target_id": 'article', }], "title": [{ "value": data_to_post.title, }], "body": [{ "value": data_to_post.body, }], }; const generated_URL = endpointUrl + "/node?_format=json"; const post_response = await fetch(generated_URL, { method: "POST", headers: { "Content-Type": "application/json", "X-CSRF-Token": csrf_token, }, body: JSON.stringify(post_data), credentials: "include" }) return post_response; } catch(error) { console.log(error); } }State variables used const [formData, setFormData] = useState({ title: "", shortDesc: "", body: "", img_field: "", }); const [articleUpdated,setArticleUpdated] = useState(0);Form handler const handleAddSubmit = (event) => { event.preventDefault(); postData(formData).then((res) => { if(res?.ok){ setArticleUpdated(articleUpdated+1) }else { console.log('invalid form submission') } }) setIsModalOpen(false); }3) After adding all the React code and the CSS as per desired design (Note: CSS code is not included), Run npm start  This will start your React application. Now you can add data on the React app and it will get stored on Drupal. And via the get method, we can view the updated result on our React app. This is the final result: On the Drupal application, our test data is now stored. Final Thoughts In the current market trend for API-first architecture, the rise of modern frontend tools to better serve the customer, and the possibility to use Drupal capabilities along with other powerful architectures, the Headless/Decoupled Drupal is a step into that. Currently, the poor documentation for decoupled architecture using best practices and the complexities of extracting data from some commonly used Drupal features like layout builder, paragraph module, etc. make it challenging to implement a fully decoupled website. As Dries Buytaert (founder of Drupal) also suggests going with progressively decoupled is a better choice as of now. The decision to opt for decoupled architecture comes with both advantages and challenges, it’s a matter of which one weighs more as per the end product. Discover how Specbee can assist you in navigating these waters and building a tailored solution that meets your unique needs.

Talking Drupal: Talking Drupal #422 - Commerce Kickstart

Today we are talking about Commerce Kickstart, Commerce in General, and What’s new at Centarro with guest Ryan Szrama. We’ll also cover Navigation as our module of the week.

For show notes visit: www.talkingDrupal.com/422

Topics
  • High level overview of commerce kickstart
  • Is it a distribution
  • Will it move to recipes
  • Why use commerce directly over kickstart
  • Does kickstart lend itself to a specific type of site
  • Compare with Shopify
  • Do you ever recommend Shopify
  • Are there additional conditions or events being added
  • Can people contribute to kickstart
  • What is Centarro focused on now
  • What is the state of headless
Resources Guests

Ryan Szarma - ryanszrama.com rszrama

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Mark Casias - kanopi.com - markie

MOTW Correspondent

Martin Anderson-Clutz - @mandclu Navigation

  • Brief description:
    • Would you like to try out and give feedback on a proposed overhaul to how Drupal’s administration menu works? There’s a module for that.
  • Brief history
    • How old: project created in 2004, but the namespace was taken over earlier this year as a place to work on the proposed new navigation in the contrib space
    • Versions available: No releases yet, so you need to clone the repo into your custom modules
  • Maintainership
    • Very active development, commits in the past day
  • Number of open issues:
    • 46, 14 of which are bugs
  • Usage stats:
    • Officially 1 site is using it, but not recommended for production anyway
  • Maintainer(s):
    • Include Christina Chumillas, Sascha Eggenberger, Lauri Eskola, Mike Herschel, and more
  • Module features and usage
    • At this point, really a prototype, trying to define what the user experience should be
    • Worth noting that the latest release for the Gin admin theme also includes this new updated navigation as an experimental feature that can be updated, but still best to leave feedback on the Navigation project
    • The main idea is that instead of having dropdowns that fly out for deeper level menu items, the navigation is in a sidebar, with menu items that expand to reveal child items when clicked
    • It’s worth noting that dropdown menus with multiple levels handled in flyouts are a known usability pain point, and are often cited by industry experts like Jakob Neilsen as something to avoid
    • There are still some usability issues to be thought through with this approach, for example there is no longer a way to reach the top page of a section or subsection, because clicking on the link shows or hides the child items instead
    • This was a subject of some very active discussions at DrupalCon Europe last week, so I thought it would be good to cover this week, so our listeners can add their voices