Hello our valued visitor, We present you the best web solutions and high quality graphic designs with a lot of features. just login to your account and enjoy ...
<none>
Hello our valued visitor, We present you the best web solutions and high quality graphic designs with a lot of features. just login to your account and enjoy ...
Tech News
| News ID | Title News | Details |
|---|---|---|
| 144,154 | Cindy Garcia; Discovered Drupal, hooked a new career |
It’s been an interesting path to finding professional and personal fulfillment for the decidedly bold and curious Cindy Garcia. She graduated with a degree in biomedical engineering from Florida International University in 2012, landed a job as a Quality Assurance Engineer in the medical device industry shortly thereafter, and then realized she was more interested in, and really well suited for IT; specifically web development. This time of transition was not just one of wrestling with her professional journey, as she was also starting to pivot her athletic interests, explaining, “I started participating in an adult wrestling class because I wanted to enhance my jiu jitsu.” She had been competing in Brazilian Jiu jitsu during and after college, and was preparing for additional competitions. She was also readying herself to move into the web development space, and so enrolled in an application architect program, which led into her first foray in web development using WordPress; quickly becoming a Wordpress site builder/SEO strategist. Turns out Wordpress, according to Cindy, has limits that made her realize it was, for her, a stepping stone and not a career destination. She was still on the hunt for the platform that would satisfy her interests, provide a challenge and offer a fulfilling career. Concurrently, she explains, “a friend of mine who I practiced jiu jitsu with and was a college wrestler asked me to become a referee with her.“ She completed that program, worked and gained experience, and quickly earned a spot refereeing for USA Wrestling at venues all over the United States. After some considerable research, she found Drupal, and realized she had also found her professional passion, but admits “I found it very difficult to learn Drupal on my own…” She heard about the Drupal Association’s Discover Drupal program, applied and so began her formal Drupal training when she applied and was accepted to DrupalEasy’s 12-week Drupal Career Online certificate program. In addition to devouring the Drupal Career Online materials, fully engaging in class and religiously attending the DrupalEasy office hours, she connected with several Drupal mentors, for whom she clearly has boundless appreciation. “...I would have never grown as quickly as I did without their help,” she muses of Ryan Price, Darren Oh, Phil Frilling, Matt Obert and Mike Anello, who all mentored her during her Discover Drupal experience. Once she completed the DCO, she fed her ongoing desire to learn more and advance by registering for DrupalEasy’s Professional Module Development program. It was just the course she needed to feed her hunger for coding challenges, interest in module development, as well as her love of networking and connecting with other developers. She also believes community is another key to her success, citing DrupalEasy office hours, virtual meetups, and attending a DrupalCon once a year as the most important elements of community that those new to Drupal should prioritize. Additional advice she has for aspiring Drupal developers considering applying for Drupal Career Online is “Don't be afraid to ask questions; reach out to your mentors as much as you can. Network as much as you can and build your Drupal profile on drupal.org,” she says. She added, “Having good communication skills is important to be successful in Drupal. Being able to explain what the problem is, how to solve it, and how long it will take is crucial.” She also feels a positive mindset, even when things are tough, is a huge contributor to learning and building a Drupal career. Which, she is doing with a part-time gig at Ironistic, a full service digital agency that assists organizations with strategy consulting, website design and development, integrated marketing and hosting and maintenance services. She hopes to get into module development, with a long term goal “to write a module, get it published on drupal.org and be a module maintainer,” she explains. Meanwhile, through her other passion, she also now travels all over the country for USA Wrestling as a referee in the Fall/Winter season for Folkstyle and women's college Freestyle Wrestling, and during the Spring and Summer season for mostly freestyle and Greco wrestling events. She looks back on the journey and contemplates where she is now, and can’t help but reflect on the connections that becoming a referee and her career shift to IT & Drupal have. She explains, “Wrestlers are grinders. They never quit no matter how hard something gets, and I have used that mindset to overcome my feelings of imposter syndrome.” She continues, “In less than 10 months I have worked on 4 professional Drupal sites, have two contribution credits on drupal.org and meeting credits and have attended a DrupalCon!” Her full schedule of sessions and events at DrupalCon Pittsburgh included DrupalEasy’s alumni-community lunch bash. Asked about her favorite part of DrupalCon, she quickly responds that it was the code sprint with “My favorite was contributing to open source because I was able to enhance my knowledge of writing single directory components.” Adding, “I look forward to traveling to DrupalCons all over the world and deepening my knowledge of Drupal.” Like Drupal, refereeing wrestling continues to inspire her and enrich her life. “I like that it challenges me physically, mentally, and emotionally. It challenges my decision making as well, as I always have to make split second decisions in regard to how I score the bout. I get to travel all over the country and some of my closest friends are referees.“ Her gratitude to everyone who has helped to guide her along the path to becoming a Drupal developer is evident as she adds about Discover Drupal and Drupal Career Online, “Thank you for creating this program. It added so much value to my life and changed it for the better.” The next Professional Module Development Course Full and Lite sessions begin soon, register here. To Learn more about the PMD join us for a mini-webinar! The next semester of Drupal Career Online begins soon. To be considered, apply to Drupal Career Online, and if interested in any scholarship that are available, be sure to add to the application. |
| 144,155 | DrupalEasy Podcast S15E4 - Jordan Powell - Cypress - Javascript-based testing framework |
We talk with Jordan Powell about Cypress, an open-source, javascript-based testing framework. URLs mentioned
We're using the machine-driven Amazon Transcribe service to provide an audio transcript of this episode. SubscribeSubscribe to our podcast on iTunes, Google Play, iHeart, or Spotify. If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page. |
| 149,921 | DrupalEasy Podcast S15E5 - Andy Blum - Drupal Smart Snippets for Visual Studio Code |
We talk with Andy Blum about the Drupal Smart Snippets extension for Visual Studio Code. The extension brings some really useful Drupal-y features to Visual Studio Code including hook completion, form and render array element completion, and service and service method autocomplete. URLs mentioned
Suggested Visual Studio Code settings to go along with Drupal Smart Snippets extension: "editor.snippetSuggestions": "top", [this used to be the default behavior until 1.6.0] "php.suggest.basic": false, [source]DrupalEasy News
We're using the machine-driven Amazon Transcribe service to provide an audio transcript of this episode. SubscribeSubscribe to our podcast on iTunes, Google Play, iHeart, or Spotify. If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page. |
| 149,922 | DrupalEasy Podcast S15E6 - Cameron Eagans - Composer Patches |
We talk with Cameron Eagans about Composer Patches, an open-source, Composer plugin to assist with applying patches to code files. URLs mentioned
We're using the machine-driven Amazon Transcribe service to provide an audio transcript of this episode. SubscribeSubscribe to our podcast on iTunes, Google Play, iHeart, or Spotify. If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page. |
| 154,499 | Mentoring a team of new contributors at DrupalCon Lille 2023 |
One of the signature events of every Drupalcon (IMHO) is contribution day, when community members from around the world gather to work together in the same physical space to advance various aspects of the project - from strategic and community initiatives to contributed modules and themes as well as non-code contributions like Promote Drupal and, of course, core contributions. As part of this, space is always set aside for new contributors, with community volunteers helping to organize, train, and mentor community members new to project contribution. This space strives to be a welcoming environment to those of all skills and skill levels, and includes a "First time contributor workshop" to introduce new contributors to contribution areas and tools. tl;dr The team I mentored managed to complete the core issue we selected and get it committed to core by the end of the day - something that hasn't happened at a Drupalcon in several years! Setting a goalThis year, I volunteered to be a mentor in the Mentored Contribution room. Some mentors are provided with a free ticket to Drupalcon, with the understanding that they will not only volunteer a full-day of their time during contribution day, but will also dedicate several additional hours of their Drupalcon experience to attending a mentor orientation, helping out at the Community Mentoring table (graciously provided by Kuoni in the main expo area,) among other tasks. I've mentored at community events previously (DrupalEasy also provides mentoring services for hire,) so going into the day, I knew exactly what the goals for my "team" were going to be:
It is important to note that not all tasks at Mentored Contribution are code and/or project related. The mentoring team does a great job of mentoring other forms of contributions as well. Finding the right core issueHaving some previous experience, I knew that the first task would likely be time-consuming, so I took it upon myself to spend a couple of hours prior to contribution day to browse through Drupal core issues tagged "Novice" . Finding the right issue to work on during a contribution day is always tricky. Newer core issues tend to be very dynamic with active contributors working on them. Older core issues tend to be more difficult for various reasons - sometimes consensus isn't reached, other times the issue is too complex to be approached by a group in a single day. Prior to the Mentored Contribution day, organizers perform issue triage to narrow down potential issues. I eventually settled on an issue from November, 2020 titled Add autocomplete attributes on login form and password reset form. The task involved adding some HTML attributes to a couple of core forms to help password managers more reliably target username and password fields. There was an existing merge request (MR) for the issue, but it was without tests (and about two years old.) This issue seemed to have the criteria I was looking for - something approachable and a relatively straight-forward end goal, something that would allow us to utilize merge requests, and something that required some, but not too much, coding so we had a chance at finishing before the end of the day. The teamGenerally, mentors declare the types of tasks they'd like to work on, then volunteer greeters welcome folks as they show up for the day and bring them to a table to get to work once the "First time contributor workshop" is complete. Our team consisted of eager new contributors, including: guzmanb, maxime.rffd, hexaki, samuel_orhan, rauch, guiu.rocafort.ferrer, mullzk, and binnythomas. Using DrupalPodThe mentoring organizers recommend that we use DrupalPod during contribution day. DrupalPod is a browser extension and a set of scripts that make it super-easy to spin up a core development environment on GitPod. DrupalPod utilizes DDEV (something I know a little bit about) and runs completely in a browser, making it very convenient for contribution events like this. We took some time to ensure everyone was able to spin up their DrupalPod environment for the existing MR, but quickly faced some challenges, as the DrupalPod environment was not launching cleanly. We worked together to eventually determine that the main issue was the fact that the issue fork was over 2 years old and didn't have an 11.x branch, so the DrupalPod scripts were unable to properly set up the development environment. This allowed our team to learn about diagnosing and correcting issue fork challenges. This also allowed our team to learn about (and practice) the necessary configuration and workflow for pushing commits from a Gitpod environment back to drupal.org. This involved setting up a temporary .ssh key set (with assistance from DrupalPod) and using Visual Studio Code's Git UI for making pushes (and not the command line.) These tasks took several hours to complete - ensuring that all team members were staying engaged. The issue codeOnce we had the development environment and issue fork configured properly, it was time to discuss our approach to completing the issue. Several of our team members had to leave after lunch, so we were left with a core group of individuals, with new contributor guiu.rocafort.ferrer volunteering to take the lead. We planned out the change (and actually expanded the scope of the issue a tiny bit) and I received some guidance from an experienced core developer on what would be a reasonable PhpUnit test for this issue that I relayed back to the team. I provided some guidance to the team to figure out where the test code should go (a new test class wasn't necessary; we just had to figure out the best existing test class to add to) and an overview of what the (relatively simple) test should look like. At that point, I felt the existing team members had things well-in-hand, so I stepped back and let them get to work. Getting to RTBCBy now, it was mid-afternoon and I was very hopeful that we'd at least be able to get the issue to "Needs review" with an outside chance of "RTBC." While the team worked on the code, I recruited a couple of experienced code contributors to review the code as soon as it was ready. The team had some minor questions as they proceeded, but no blockers. They were all experienced PHP developers, so for them, this was the easiest part of the task, I suspect. When they felt they had completed the task, I did a line-by-line code review with them, suggesting several minor changes, before they committed and pushed to the MR. I then alerted our reviewers (jurgenhass and lostcarpark) and they both agreed that it looked good. While this was going on, I alerted the mentoring organizers that we would potentially have a core issue at RTBC. Live Drupal core commitAs long as I've been a part of the Drupal community, during Drupalcon contribution days, "live core commits" have always been a thing. From what I've been told, there hasn't been one for "several years" for various reasons, so I was quite proud of our team when nod_ showed up to congratulate our team and commit their changes to Drupal core on the big screen at the front of the mentored contribution room. RetrospectiveLooking back at the event, the only thing I would have changed is something that was completely out of my control - the fact that over half of our team wasn't able to stay for the full day and get the sense of pride that the rest of the team clearly had watching a Drupal core committer accept their contribution. Personally, core mentoring is incredibly rewarding, and I always get more out of it than I expect. Along the way, I learned some additional details about DrupalPod as well as the pitfalls (and solutions) when working with old issue forks. If you're an experienced Drupal developer, I encourage you to make a commitment to dedicate your time to helping to grow the next wave of contributors. If you're interested, say hello in the #mentoring-team channel of the Drupal Slack workspace. Photos courtesy of Andy Blum. |
| 154,500 | Test-driving GitLab CI templates for Drupal contributed modules |
Earlier this year, the Drupal Association (DA) and various community contributors announced the general availability of GitLab CI (Continuous Integration) for Drupal contributed modules. The goal of this project is to replace the existing, bespoke, Drupal CI for running automated tests for both Drupal core and contributed projects with GitLab's existing CI tools, thus saving community and DA resources in the long-term. For contributed module maintainers, this means being able to specify more flexible tests and code validations, depending on the module's unique needs. Much of this functionality will be made readily available to module maintainers via GitLab templates that offer a rock-solid starting point for module maintainers. What can GitLab CI do?First, some basics. The general idea is that for every commit to a contributed module project (including on issue forks,) GitLab CI will run a maintainer-defined process to run various checks on the code. These checks normally include validation steps like ensuring the project's composer.json file is valid, coding standard checks via phpcs, and static code analysis checks via PhpStan. The checks will often include testing steps that run the module's PhpUnit tests in various Drupal environments (different versions of Drupal core and PHP.) By default, these checks - called jobs in GitLab CI parlance - are divided into three stages: build, validate, and test. Upon completion of the pipeline (all of the defined jobs in all the stages), GitLab CI will display the results. The previous image shows a completed passing pipeline for the Markdown Easy module (note that I opted the Markdown Easy module into additional jobs - more on that below.) If any of the jobs fail, then the project's contributors have access to detailed logs to help diagnose and correct any issues. Module maintainers can also decide which, if any, failures are not deal-breakers and decide to accept the changes anyway. It is clear that the system was built with flexibility in mind. How does a module maintainer get started?This is the best part - it's ridiculously easy. The DA and community contributors have created a set of templates to get you started with a basic pipeline. From the GitLab interface for a contributed module project (via https://git.drupalcode.org/ - be sure that you're logged in!) all a maintainer has to do it click to add a new file, name it ".gitlab-ci.yml" and a "Template" dropdown will automagically appear for them to select the template:
Once the template is selected, all the maintainer has to do is commit the file to the repository and the module will have a basic pipeline up-and-running. The basic pipeline provides both validation and PhpUnit jobs in the current version of Drupal core. But wait, there's more!Want to run more tests against different versions of Drupal core (past or present) or versions of PHP? The variables template includes documentation on variable overrides to add/remove/modify pre-defined jobs. Two of the most useful groups of variables provided by the Drupal GitLab CI templates are of the form SKIP_* and OPT_IN_* - these allow module maintainers to easily skip some jobs and opt-in to others. For example, want to skip the PhpStan validate job? Simply add the following to your module's .gitlab-ci.yml: SKIP_PHPSTAN: 1For an example of the OPT_IN_* variables, let's go back to the initial image above for Markdown Easy, all of those jobs shown were run by adding only the following to the module's .gitlab-ci.yml file: OPT_IN_TEST_PREVIOUS_MAJOR: 1 OPT_IN_TEST_MAX_PHP: 1 OPT_IN_TEST_PREVIOUS_MINOR: 1 OPT_IN_TEST_NEXT_MINOR: 1 OPT_IN_TEST_NEXT_MAJOR: 1 # Show more log output _PHPUNIT_EXTRA: --verbose # Convenient, and we have no secrets. _SHOW_ENVIRONMENT_VARIABLES: 1OPT_IN_TEST_PREVIOUS_MAJOR refers to the previous major version of Drupal core (Drupal 9). But wait (again,) there's even more!Because all of this stuff is built on-top of out-of-the-box Gitlab CI functionality, module maintainers who are comfortable with .gitlab-ci.yml syntax can implement any CI process they can dream up. In the past few weeks, there have been discussions (and successes) of adding Yarn, generating GitLab pages that generate a documentation page for the module, and more! What's the downside?As far as I can tell, there are at least two potential issues that the DA and contributors are keeping their eyes on:
Absolutely not. The DA and contributors have regular Gitlab Acceleration Initiative meetings (normally every-other-week) in the #gitlab channel of the Drupal Slack workspace. Also, the issue queue is the place where most of contrib work happens; so file an issue, work on an existing one, test where possible to help accelerate even further. Much of the recent effort has been toward adding features (like PhpStan and Drupal 7 support) to the default templates as well as looking for ways to optimize the pipeline for both speed and resources ($$$.) Thanks so much to Fran Garcia-Linares, one of the main developers of the Drupal GitLab CI templates, for reviewing (and adding to!) this blog post. |
| 154,501 | Using DrupalPod for core and contrib development |
DrupalPod is a browser extension and GitPod configuration that allows Drupal contributors to quickly and easily spin up a personal development environment in their browser without pre-installing anything. Before we go any further, let's break down some of these concepts a bit more… GitPod is a cloud development platform - meaning that everything necessary for development is installed in the cloud and the only thing that needs to be installed on one's local machine is a modern web browser. Developers can customize their cloud development environments virtually any way they see fit depending on the nature of their project. GitPod cloud development environments are sometimes called personal development environments, as they are normally created as an alternative to a developer's local development environment. While GitPod environments will sleep after 30 minutes of inactivity, their current state will not be deleted for 2 weeks (and when pinned, will never be deleted) and can be re-launched via the GitPod Workspaces page. GitPod is a freemium software-as-a-service with a free tier that includes 50 hours/month of usage. DrupalPod has two main components - a browser extension (for Firefox and Chrome only) and a set of configuration scripts that customizes a GitPod personal development environment for Drupal core and contributed project (modules, themes, etc…) development. The DrupalPod browser extension provides a quick way for a Drupal contributor to launch a new personal development environment on GitPod from virtually any Drupal issue queue issue. The DrupalPod configuration scripts for GitPod include just about everything a modern Drupal development environment needs, including the drupal/core-dev dependencies (which includes PhpStan, phpcs, and PhpUnit), a complete DDEV-based environment, Xdebug setup out of the box, and a useful tool to help set up a temporary ssh keys for using Git to push changes back to issue forks on Drupal.org in a secure manner. In addition, every DrupalPod environment includes Drush as well as the Admin Toolbar and Devel modules - all with the idea of making it as easy as possible to focus on the task at hand. DrupalPod was created and is maintained by Ofer Shaal, who also reviewed this blog post and provided answers to my many questions. Thanks, Ofer! It is important to emphasize that DrupalPod can completely replace one's local development environment for core and contrib development. Who is DrupalPod for?DrupalPod is not just for Drupal contributors who write and commit code changes. It also (and possibly more-importantly) allows non-coders to get more involved in the contribution process by making it easy for them to perform common issue queue tasks like testing merge requests (or patches) and reproducing reported issues. It can also be used for user experience and accessibility reviews, among other tasks. Getting startedThere's a few steps that are required before launching a Drupal issue queue merge request in DrupalPod. Luckily, both are relatively straight-forward:
Note that if you're not interested in making code changes to an existing issue, then the steps marked with an asterisk (*) can be skipped. Launching a development environmentNext, find an issue on Drupal.org that you'd like to work on. If you're planning on making a commit and pushing it back to the issue fork, be sure to click the green "Get push access" button near the top of the issue. I've created a test issue in the Markdown Easy module issue queue with an issue fork if you'd like to test DrupalPod on an inert issue. The rest of this article will assume you're testing with this issue. In your browser, click on the DrupalPod browser extension and you should see the interface shown in the screenshot earlier in this article. You'll see that the project (Markdown Easy) and the issue fork for this issue ("markdown_easy-3403460") are pre-selected. Select the "3403460-drupalpod-test-issue" branch, "10.0.9" for the Drupal core version, and "Standard" for the install profile. Since this issue only contains an issue fork and no patches, the "Choose a patch" dropdown can be left blank. It should be noted that the options for "Drupal core version" are not automatically updated whenever a new version of Drupal core is released, and there may be a delay before the DrupalPod browser extension is updated with the most recent version of Drupal core as an option. Then, click on the "Open Dev Env" button and accept the default GitPod configuration settings by clicking the "Continue" button on the GitPod configuration page. By default, GitPod will launch an in-browser version of Visual Studio Code. Next, GitPod builds your personal development environment using the configuration provided by DrupalPod - depending on several factors, the process to create the environment normally takes just a few minutes. Keep an eye on the terminal output in the Visual Studio Code interface to see when it completes. GitPod is still setting things up.GitPod is ready to go. Another big sign that your personal GitPod development environment is ready is when a web browser opens in the Visual Studio Code interface on the development environment's version of Drupal!
To login into Drupal in the GitPod-powered personal development environment use the credentials:
A fairly common occurrence (especially when working with older issues) is that during the DrupalPod/GitPod setup phase, a Composer error occurs. This is normally not an issue with DrupalPod, but rather with the issue fork (or patch) being out-of-date and in need of update. Setting up ssh keys for pushing Git commitsThis step is not necessary for those just looking to test patches or merge requests and not make code commits. Hopefully, improved integration between DrupalPod, GitPod, and git.drupalcode.org will soon render this manual temporary ssh key setup obsolete. At the current time, in order to push commits from a GitPod personal development environment back to a Drupal.org issue fork, a temporary ssh key pair must be set up. While DrupalPod does an admirable job of trying to streamline the issue, there are still a couple of manual steps involved and the process isn't super-smooth. Luckily, the process is outlined in the "Contribution Guide" document that automatically opens in a DrupalPod environment (see previous screenshot). Step 5 of this guide instructs the user to run a script in the terminal in order to kick off the process of creating the temporary ssh key pair. Currently, the script launches a pseudo-GUI in the terminal app, which leads to the instructions-template.md file being displayed with the necessary steps. At this point, it is important to click on "< OK >" in the "If you completed the instructions above - click OK" box. Note that this will kick off a command line task that requires your input, requesting you to enter your desired passphrase for your temporary ssh key (I normally just hit "Return" to leave the passphrase blank). Only once this is step complete will you see your new, temporary ssh public key appended to the instructions-template.md document. After this, proceed with steps 1-9 listed in the document. Once complete, click to < Exit > the pseudo-GUI in the terminal app, then complete step 10 to confirm that the temporary ssh key is working as expected. I have found that the resulting message is semi-clear at best, but as long as you see "Setup was successful" somewhere in the message, you're probably good-to-go. At this point, I normally close the ssh-related .md documents open in Visual Studio Code and get to work. Using Git from inside a DrupalPod environmentOne aspect of using DrupalPod that is quite important for anyone interested in code contribution is understanding at least a little bit about how the code base is organized. Here's the short version - the directory that you should pay the most attention to is repos. This is where the project of interest (the one whose issue fork or patch you're working on) is available to you for editing and (more importantly) for performing Git operations on. DrupalPod uses symlinks to ensure everything is running smoothly, and the repos directory is automatically symlinked to the project of interest (regardless if it is a module, theme, or Drupal core). When DrupalPod is opened for a Drupal core issue, https://github.com/joachim-n/drupal-core-development-project is used for the code base. Inside the repos directory is the project of interest. To modify a project file, navigate to the file inside the repos directory. If/when you're ready to make a code commit to the issue fork, you may use the Visual Studio Code's Git GUI or the command line (after navigating to the project inside the repos directory.) Assuming that you properly set up a temporary ssh keypair from the previous section, you should be able to perform a git push from either interface. The use of the repos directory is the same regardless of if you're working on a contributed module or Drupal core - the project of interest is in the repos directory. As a matter of practice, once the GitPod environment is up-and-running, the first thing I do is navigate to the repos/<project-name> directory on the command line. Code quality toolsWhile Drupal's core-dev dependencies are automatically provided in all DrupalPod configurations, they do not work out-of-the box without some configuration (much like as if you installed them yourself in a local development environment.) Setting up code quality tools like phpcs, PhpStan, and PhpUnit for core or contributed modules involves a little bit of configuration that is out-of-scope of this article. More information is available on drupal.org - this material (and much more) is also covered in DrupalEasy's 15-week Professional Module Development course. What's next for DrupalPod?Based on conversations with Ofer Shaal, the primary maintainer of DrupalPod, users can expect the following improvements in the coming months:
|
| 154,496 | Introducing the Markdown Easy Drupal module |
Markdown is a text processing library that takes readable text and converts it into HTML. Started over 20 years ago, it is now a widely-used library that makes it easy for people to write text documents that can be easily and predictably converted into HTML. Quick example - the Markdown syntax "this is **important**" converts to "this is important" after passing through a Markdown converter. There are many "flavors" of Markdown today - most include the basic syntax and many include their version of "extended Markdown". Examples include Github-flavored Markdown and CommonMark. Predictably, there have been Markdown-related Drupal contrib modules for a number of years, with the standard being the predictably named Markdown module. Started in 2008, it is currently used by about 5,000 Drupal sites (down from a high of more than 12,000 sites a few years ago). Unfortunately, as of the publishing of this blog post, the current iteration of the Markdown module does not yet have a full release compatible with Drupal 10, although there are efforts ongoing to remedy this. Why a new module?DrupalEasy.com uses the Markdown syntax for some of its content. During our effort to upgrade DrupalEasy.com, the Markdown module became our last blocker to achieving that goal. We took the time to review the current state of the Markdown module and its effort to be upgraded for Drupal 10, and in the end, we decided to pursue a simpler (in terms of module configuration,) less-time-consuming (in terms of contribution time,) and sustainable (in terms of ease of future upgrades) solution. The existing Markdown module is configurable - really configurable. Some might say "too configurable". One of the main configuration choices one has to make when using the Markdown module is choosing which Markdown library to utilize. The various open-source Markdown-processor libraries implement their own flavor of Markdown (like the Github and CommonMark libraries mentioned above). In fact, the Markdown module allows you to utilize multiple Markdown processor libraries. Once a library is selected, there are a myriad of additional configuration options available for each library and for each text format where the Markdown filter is utilized. Configuring the Markdown module in a secure manner is (in our experience) a bit of a chore. I have no doubt that there are users of the Markdown module that require that level of control and fine-grained configuration. In those cases, the Markdown module is probably their best choice. But, what about users who don't need that level of control? Users who just want to process Markdown formatted text into basic HTML with a minimum of fuss using a tried-and-true Markdown library. It is for these users that the Markdown Easy module was created. What makes Markdown Easy different?In short:
It was decided early on that the CommonMark library would be a dependency of Markdown Easy. It has more than 150 million installs on Packagist.org and is considered by many as the "gold standard" of Markdown libraries. In addition, it comes with the "Github-flavored Markdown" option as well. Selecting between these two "flavors" of Markdown is the only configuration option you have in Markdown Easy. The module is preconfigured to be as secure as possible. Configured incorrectly, a Markdown library will output virtually any HTML tag - some that can be abused by bad actors. For example, the Markdown Easy module (by default) does not allow unsafe links or HTML tags to be processed (both of these options can be overridden with a Markdown Easy hook implementation). Additionally, validation of any text format utilizing the Markdown Easy filter requires that both the "Limit HTML" and "Convert line breaks" Drupal core filters be enabled and set to run in a prescribed order to ensure secure usage and consistent results (again, this can be overridden with a hook). What features are planned for future versions of Markdown Easy?Not many. The goal is to have an easy-to-maintain (between major versions of Drupal core,) easy-to-configure (for site-builders,) and easy-to-customize (via Drupal hooks) module. The only feature that we are currently interested in adding is the option of a GitLab-flavored Markdown library. Is this module ready for prime-time?We think so. In fact, the article that you're reading was written in Markdown and processed into HTML by the Markdown Easy module (with the exception of the logo - standard HTML was used for styling purposes). Full documentation, including examples for overriding default validation and configuration, is available on drupal.org. Markdown Easy's code base is primarily validation and automated test code. The filter plugin is 129 lines of code while validation and automated tests include over 700 lines of code. We are using Drupal.org's Gitlab CI to run the tests in both Drupal 9 and Drupal 10 on every merge request and the module is covered by Drupal's security advisory policy. We invite you to check it out and let us know what you think! |
| 154,497 | Test driving the new DDEV Manager extension for Visual Studio Code |
Introduction If you use Visual Studio Code and DDEV, there's a new extension that may increase your efficiency. The DDEV Manager extension provides a user interface within Visual Studio Code for just about every conceivable DDEV command. As I am a user of both tools, and I often teach and present on the topic of maximizing one's efficiency related to Drupal development when using DDEV and Visual Studio Code, a thorough review of this new extension was a no-brainer for me. InstallationInstallation of the extension is typical of any other Visual Studio Code extension - from the "Extensions" sidebar, search for "DDEV manager" and then click to install. No restart of Visual Studio Code is necessary. Upon successful installation, the DDEV icon will be present in the sidebar. Basic functionalityThe default view of the DDEV Manager extension is a list of all DDEV projects on the machine. The counter-intuitive thing about it is that if Visual Studio Code is already open to one of the listed projects, its entry on the list isn't highlighted. In fact, from this default view, any DDEV project on the machine can be started. But, there's an icon at the top of the sidebar window that provides the ability to toggle between "All DDEV projects" and "Workspace projects"; I think the latter should be the default. I opened a feature request for this, but it was quickly rejected ☹️. However, there is a "DDEV: Show Projects List" setting in the Visual Studio Code configuration (via the "Code | Settings" menu) that allows the default to be changed. Each entry in the list has options to start, stop, restart, rename, configure, delete, launch restart, and even a button to open an ssh connection to the DDEV web container. In addition, the contextual menu (see image) provides access to virtually all project-related DDEV commands. Granted, these are all things that basic DDEV commands do, but it is rather nice to have them all represented in the UI. Most of the options work the way you would expect. For example:
One standout, in my opinion, is the Add Services option. It provides a popup dialog listing all of the available DDEV addons. I really like this feature, as discovering these addons is a relatively new feature in DDEV and I think this will really provide a lot of value to the DDEV community. For example, did you know that you could add a Solr or PDFreactor service to DDEV with a single command? Well, now you can do it with a couple of clicks - fantastic! Clicking the angle bracket to the left of each project name in the interface provides an overview of the current status of the project. A nice surprise was the ability to modify the version of PHP and/or NodeJS used in the DDEV web container via a standard Visual Studio Code popup dialog (see image). This detailed view of the DDEV project also provides nice touches like buttons to ssh into the project's various service containers, the ability to open the project directory in the OS's native file explorer, and the ability to open the MailHog interface in a browser. How does this compare with the PhpStorm DDEV plugin?The DDEV Integration plugin for PhpStorm offers similar functionality, but it is more focused on only the currently opened project. It also includes super-useful CLI integration so that tools like phpcs and PhpStan can be run inside the DDEV web container with their results exposed to the PhpStorm UI. This is not a feature that the DDEV Manager extension provides. SummaryWho should use this extension? If you use DDEV and Visual Studio Code, this seems like a no-brainer especially if you enjoy your user interfaces. But, there is one caveat: if you connect to the DDEV web container via the Visual Studio Code Dev Containers extension, then the DDEV Manager extension is irrelevant for your use case. The developer, Biati Digital, acknowledges that this is a new project and bug reports and feature requests are welcome in the issue queue. Note: there is an older, seemingly no-longer-maintained DDEV-related extension available for Visual Studio Code called "ddev". At the current time, this extension is not recommended for use. |
| 154,498 | Debugging all the things with Xdebug, DDEV, PhpStorm, PhpUnit |
Over the past few years, we've published a couple of blog posts about setting up Xdebug for Drupal module development. But, like all things in tech, there's always more to learn as tools and technology evolve. The setupI was recently working with one of our Professional (Drupal) Module Development students trying to determine why she wasn't able to use Xdebug to debug a PhpUnit-based functional test. To be clear, the breakpoint wasn't set in the actual test class, the breakpoint was set in some custom module code that was called by the test class. In functional tests, Guzzle is used by PhpUnit to make calls like: $this->drupalGet('<front>')So, in a way, there isn't a direct PHP connection between test class and the code under test. It is in this circumstance that the breakpoint wasn't working. Xdebug was working fine for this student to debug other aspects of the same project - it just wasn't hitting breakpoints during functional tests. The solutionThis was one of those instances that I had seen (and solved) previously, but to be honest, PhpStorm/Xdebug solutions have often involved numerous trips into the (extensive) PhpStorm settings area. By the time the problem is fixed, I was never 100% sure exactly which change I made had actually solved the problem. But, this time, I was more careful… Obviously, Xdebug must be enabled in DDEV, and PhpStorm's almost-magical auto-configuration for Xdebug needs to have configured a new "Server" with proper path mappings (especially for the project root). The PhpStorm configuration settings related to Xdebug that I now recommend are:
With these settings, functional PhpUnit tests can be effectively debugged. |