Debugging techniques: the good, the bad, and the ugly 🔗 **Source:** [Debugging techniques: the good, the bad, and the ugly](https://www.youtube.com/watch?v=z45ahHt8Adk) > [!note]+ Document Notes > tags: [drupal, debugging, web-development] > author: Wendy Valano > source: Drupalcon Vienna > reference: https://www.youtube.com/watch?v=z45ahHt8Adk > date created: 2024-12-19 10:30 > > # 🏷️ Title: Debugging techniques: the good, the bad, and the ugly > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Set up proper debugging environment with Xdebug and IDE — 05:23 #debugging - [H2] Create repository of common debugging scenarios — 12:45 #learning - [H3] Document debugging solutions for future reference — 18:30 #documentation ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [Drupalcon Vienna Session](https://www.youtube.com/watch?v=z45ahHt8Adk) ## 📝 Summary - Two Drupal developers from Nicaragua present debugging strategies for web applications - Covers foundational knowledge, tools, strategies, and practical techniques for effective debugging - Emphasizes systematic approaches over random fixes - Demonstrates live debugging of Drupal migration issues - Bottom line: Debugging is a learnable skill requiring proper tools, systematic approach, and documentation ## 📖 Main Content The session presents a comprehensive framework for debugging web applications, specifically focusing on Drupal development. The speakers emphasize that effective debugging requires understanding the full technology stack, from languages (HTML, CSS, JavaScript, PHP) to infrastructure (web servers, databases, CDNs) to consumers (browsers, mobile apps). The core debugging process follows five key steps: prepare your tools, analyze the problem scope, reproduce the issue locally, simplify by eliminating variables, and divide the problem into manageable parts. The speakers stress the importance of forming hypotheses before making changes and documenting solutions for future reference. Technical debugging tools include IDEs with proper configuration, step debuggers like Xdebug, profilers, version control systems, database browsers, logging systems, and browser developer tools. The presentation includes a live demonstration of debugging a Drupal migration where links weren't displaying properly, ultimately traced to missing HTTPS protocol prefixes in the source data. ## 🗒️ Notes #### ⏱️ [00:00](https://www.youtube.com/watch?v=z45ahHt8Adk?t=0) — [H1] Introduction and Speaker Background - Key idea: Two Drupal developers from Nicaragua presenting debugging techniques at their first Drupalcon Vienna - Evidence: "This is my first Drupalcon, the first session in Vienna" #### ⏱️ [02:30](https://www.youtube.com/watch?v=z45ahHt8Adk?t=150) — [H1] Why Learn Debugging Techniques - Key idea: Bugs are inevitable in code, debugging serves two purposes: fixing issues and understanding applications - Evidence: "Is it possible to have several bugs code? Yes, it is. It's possible if you not write code at all" #### ⏱️ [04:15](https://www.youtube.com/watch?v=z45ahHt8Adk?t=255) — [H1] Foundation: Technology Stack Knowledge - Key idea: Effective debugging requires understanding the full technology stack from languages to infrastructure - Evidence: "The more you know the more the context you can fix that issues" #### ⏱️ [06:45](https://www.youtube.com/watch?v=z45ahHt8Adk?t=405) — [H2] Real-World Example: Image Not Loading - Key idea: Debugging requires asking the right questions across all layers of the stack - Evidence: "Someone had added an external link of the image for an external server and in any moment the image link was removed" #### ⏱️ [09:30](https://www.youtube.com/watch?v=z45ahHt8Adk?t=570) — [H1] Drupal as Layered Architecture - Key idea: Drupal sites are like onions with multiple layers that must be understood for effective debugging - Evidence: "Drupal sites are like an onions and if you saw the movie you know that onions are like a layers" #### ⏱️ [12:00](https://www.youtube.com/watch?v=z45ahHt8Adk?t=720) — [H1] Debugging Strategies Overview - Key idea: Systematic approach involves preparation, analysis, reproduction, simplification, and division - Evidence: "You need to prepare before finding an issue. Hopefully you have some prior experience in particular with debugging tools" #### ⏱️ [15:30](https://www.youtube.com/watch?v=z45ahHt8Adk?t=930) — [H2] Migration Debugging Anecdote - Key idea: Complex debugging may reveal issues in unexpected modules, documentation prevents future problems - Evidence: "We were able to trace the issue to a contributed module not related at all with the migration" #### ⏱️ [18:45](https://www.youtube.com/watch?v=z45ahHt8Adk?t=1125) — [H1] Essential Debugging Tools - Key idea: Proper tools include IDEs, debuggers, profilers, version control, database browsers, loggers, and watches - Evidence: "Xdebug is my tools of choice and pair with DD as we're going to see in the demo" #### ⏱️ [22:15](https://www.youtube.com/watch?v=z45ahHt8Adk?t=1335) — [H2] Time Management in Debugging - Key idea: Set time limits for debugging attempts and take breaks to avoid frustration - Evidence: "Spend up to two hours trying to solve an issue. And if you cannot do that in two hours take a pause" #### ⏱️ [25:30](https://www.youtube.com/watch?v=z45ahHt8Adk?t=1530) — [H1] Practical Debugging Techniques - Key idea: Every bug has a deterministic cause, read error messages carefully, form hypotheses before changes - Evidence: "Every bug have a cause. Bugs are computers are deterministics. Things do not happen just randomly" #### ⏱️ [28:45](https://www.youtube.com/watch?v=z45ahHt8Adk?t=1725) — [H2] Step Debugger Demonstration - Key idea: Step debuggers allow inspection of variables, call stacks, and conditional breakpoints - Evidence: "Use a step debugger for PHP. You can see all the variables that are available in at this point in the debugging process" #### ⏱️ [32:00](https://www.youtube.com/watch?v=z45ahHt8Adk?t=1920) — [H2] Twig Template Debugging - Key idea: Enable Twig debugging to identify specific template files responsible for markup - Evidence: "You can specifically and directly go to the one file that is responsible for producing the markup" #### ⏱️ [35:15](https://www.youtube.com/watch?v=z45ahHt8Adk?t=2115) — [H2] Browser Developer Tools - Key idea: Browser tools are essential for debugging JavaScript, performance, and network issues - Evidence: "Learn to use your browser tools. This is particularly useful for debugging JavaScript" #### ⏱️ [38:30](https://www.youtube.com/watch?v=z45ahHt8Adk?t=2310) — [H3] Advanced Debugging Techniques - Key idea: Search codebase for error messages, examine tests, inspect database structure - Evidence: "When you get an error message, one of the very first thing that I do is copy the message and try to look for it in the codebase" #### ⏱️ [42:00](https://www.youtube.com/watch?v=z45ahHt8Adk?t=2520) — [H1] Live Debugging Demonstration - Key idea: Practical demonstration of debugging Drupal migration issue with missing link data - Evidence: "My migration didn't work. So, let's start like debugging" #### ⏱️ [50:15](https://www.youtube.com/watch?v=z45ahHt8Adk?t=3015) — [H2] Solution: Missing HTTPS Protocol - Key idea: The migration issue was caused by missing HTTPS protocol in link URLs - Evidence: "URI something something is invalid. You must use a valid URI schema" ## 📚 References - [Drupalcon Vienna Session](https://www.youtube.com/watch?v=z45ahHt8Adk) - [Learn WordPress](https://learn.wordpress.org/) - [Developer Docs](https://developer.wordpress.org/) ## 🗣️ Paraphrase - Debugging is a systematic skill that can be learned through proper preparation, tools, and methodologies rather than random trial and error - Understanding the complete technology stack from front-end to infrastructure is crucial for identifying the root cause of issues across different system layers - Effective debugging requires forming hypotheses before making changes, documenting solutions, and knowing when to take breaks to maintain clear thinking ## 📰 Newsletter **Master Debugging Techniques for Better WordPress Development** Two experienced developers shared comprehensive debugging strategies at Drupalcon Vienna that apply perfectly to WordPress development. Their systematic approach emphasizes understanding your full technology stack and using proper tools rather than guessing at solutions. **Key Learning**: Every bug has a deterministic cause. The most effective debugging follows a five-step process: prepare your tools, analyze the problem scope, reproduce locally, simplify by eliminating variables, and systematically divide the issue. **Practical Benefit**: Their live demonstration showed how a missing HTTPS protocol caused migration failures - a systematic approach with proper debugging tools identified the issue quickly rather than hours of guessing. **Essential Tools**: Set up Xdebug with your IDE, master browser developer tools, use database browsers, implement logging, and always document your solutions for future reference. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### WordPress - Core: Implement debugging workshops in contributor onboarding, establish debugging documentation standards - Documentation: Create debugging guides for common WordPress scenarios, add troubleshooting sections to developer docs - Training: Develop debugging curriculum with hands-on exercises, create video tutorials for debugging tools - Community: Host debugging office hours, create debugging challenges for skill building - CLI: Document debugging flags and techniques specific to WP-CLI commands #### DevRel - Education: Create debugging workshop series, develop hands-on debugging exercises with WordPress scenarios - Developer experience: Document debugging setup procedures, create debugging toolchain recommendations - Developer marketing: Promote systematic debugging approaches, share debugging success stories - Community management: Moderate debugging forums, create debugging challenge programs ## 🧪 Hypotheses - Systematic debugging approaches reduce time-to-resolution compared to ad-hoc troubleshooting methods - Proper debugging tool setup correlates with developer productivity and job satisfaction - Documented debugging solutions significantly reduce repeat issue resolution time - Step-by-step debugging education improves overall code quality in development teams ### 📊 Methodology - Survey developers on debugging time before/after systematic training - Track issue resolution times with proper debugging tools vs without - Measure repeat issue frequency with/without documentation practices ### ❓ Questions - How can debugging education be integrated into standard developer onboarding? - What debugging scenarios are most common in WordPress development? - How do debugging practices differ between experienced and novice developers? ### 🔮 Future Research - Comparative analysis of debugging tools effectiveness across different development environments - Development of AI-assisted debugging tools for common WordPress issues - Investigation of debugging practices in remote vs co-located development teams ### 💡 Implications - Practice: Establishes systematic approach to problem-solving that improves development efficiency - Education: Demonstrates need for formal debugging training in developer curriculum - Tooling: Shows importance of proper development environment setup with debugging capabilities - Documentation: Emphasizes value of documenting solutions for knowledge sharing and team efficiency ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade #### 👀 Visual learners - Present: IDE screenshots, browser developer tools interface, database structure diagrams - Improve: Flow charts of debugging process, visual comparison of before/after states #### 🔊 Aural learners - Present: Video presentation with clear narration and explanation - Improve: Audio-only version for commuting, podcast format discussion #### 🗣️ Verbal learners - Present: Clear definitions of debugging terminology, step-by-step explanations - Improve: Glossary of debugging terms, analogy-based explanations #### 🧩 Kinesthetic learners - Present: Live coding demonstration, hands-on debugging exercises - Improve: Interactive debugging sandbox, step-by-step practice environments #### 🧠 Logical learners - Present: Systematic five-step debugging process, cause-and-effect analysis - Improve: Decision trees for debugging scenarios, logical flowcharts #### 🧑‍🤝‍🧑 Social learners - Present: Two-person presentation format, Q&A session - Improve: Pair debugging exercises, group debugging challenges #### 🧘‍♀️ Solitary learners - Present: Self-paced video content, individual practice repository - Improve: Self-assessment quizzes, personal debugging journal templates #### 🌿 Naturalistic learners - Present: Systematic categorization of debugging approaches - Improve: Ecosystem analogies for understanding interconnected systems ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive link text in slides - Improve: Alt text for code screenshots, structured navigation landmarks #### Keyboard navigation - Present: Standard video player controls - Improve: Keyboard shortcuts for code navigation, accessible code examples #### Contrast and readability - Present: High contrast code examples in IDE - Improve: Ensure 4.5:1 contrast in all slide text, larger fonts for code #### Text resizing and reflow - Present: Video scales appropriately - Improve: Responsive code examples, scalable interface demonstrations #### Media and captions - Present: Video format available - Improve: Professional captions, downloadable transcript, audio descriptions #### Forms and interactions - Present: Basic Q&A interaction - Improve: Accessible feedback forms, structured Q&A format ### 🌍 DEIB Assessment #### Cultural breadth - Present: Speakers from Nicaragua providing global perspective - Improve: Examples from diverse development contexts, multilingual error messages #### Inclusive language - Present: Gender-neutral technical language, defined jargon - Improve: Plain language summaries, avoid cultural idioms #### Neurodiversity support - Present: Structured presentation format, clear section breaks - Improve: Content warnings for flashing screens, consistent navigation patterns #### Representation - Present: Diverse speaker backgrounds, collaborative presentation style - Improve: Varied examples beyond single demographic, inclusive imagery #### Psychological safety - Present: Encouraging tone, "everyone makes mistakes" messaging - Improve: Explicit statement that debugging struggles are normal, supportive community resources ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Strong logical progression from preparation through execution - Inductive strength: Well-supported generalization from specific debugging examples - Causal reasoning: Clear cause-and-effect relationships in debugging process - Analogical strength: Effective onion layer analogy for Drupal architecture #### Fallacies - Hasty generalization: Occasional assumption that all debugging follows same patterns, addressed by providing multiple techniques - Appeal to authority: Minimal, mostly evidence-based approaches #### Tone of voice - Overall tone: Professional, encouraging, practical with appropriate humility about debugging challenges ### 🛡️ DARVO Analysis - Deny: No denial patterns present - Attack: No attacks on opposing viewpoints - Reverse <!-- deep-read:sections end --> ## 📺 Video  --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=z45ahHt8Adk)* **[00:01]** Um, welcome everybody. Thanks for being here. This session is about debugging techniques. I'm Wendy Valano. My pronouns are she here. Uh, I go by online. I work as a Drupal developer at Anttech. And this is my first Drupalcon, the first session in **[00:32]** Vienna. And I'm glad to share this session with Mauricio Dinart. His pronouns are he and him. He goes by Dinaron online and he's a senior software engineer at Agari and also he's an expert on migration and his first session at Drupalcon uh was also here in Vienna. a fun coincidence. Um, we are from Nicaragua, a be **[01:03]** beautiful tropical country. Um, known as the land of lake and volcanoes. Uh, as I mentioned, uh, we work at Agaric and MTech. Um, both are Drupal agencies based in the US and also they have offices in Nicaragua and in Germany. and Mauricio Mauricio is passionate uh about teaching. So he has a personal blog understand **[01:34]** there are a lot of resources about uh Drupal uh in different languages English, Spanish and French and you can check out the the blog. So let's get started. Uh why should we learn debugging techniques? Uh let me ask you a question. Is it possible to have several bugs code? >> No. >> Yes, it is. It's possible if you not **[02:07]** write if you not write code at all. So it's possible and um we deo deote code uh for one to fix issues. This is the most common reason. And second to understand how the application works. This is an important technique because if you are introducing a project that you don't know too much about it uh by using the vog the voggers **[02:40]** and knowing the techniques that we are going to cover today um you can have a sense of what is the the issue and how to fix them. And I would like you to remember this phrase by Leah Vo that said understanding the process of finding a solution is far more valuable than the solution itself. This is the objective of this uh presentation. is **[03:12]** not to give you a set of steps to follow up uh in all kind of the the errors uh but instead is give you some tools and strategies that you can use to fix issues. So in order to in order to be effective uh at the bugging you need to start with a solid foundation. you need to consider uh the technology **[03:42]** stacks. So we need to know about the languages. If we are using HTML, CSS, JavaScript, PHP, the framework that we are using, Drupal, WordPress or React, the infrastructure that we are also working with, web servers, database servers, caching, CDNs and also consumers, browsers, mobile application, external web services and um it might it might be **[04:14]** uh you It might you be thinking that you don't need uh why why you why do you need to know all of these things if you just only want if you only uh needed to fix the bug? Because the more you know the more the context you can fix that issues. And let me give an example. This is a real example in my daily life. **[04:49]** Um, I was tasked with an issue that said image not loading. And to start working on this, uh, first I need to check if the image tag was presented on the HTML markup. And also um and also I asked a lot of questions um in order to determine what was the the issue. If the **[05:20]** problem uh was part of the framework is Drupal rendering uh the media field or or if this is a problem of in infrastructure is the storage service Amazon S3 properly configured or this is something related to consumers is there are a browser extension blocking the request and let me say that was none of these questions Um the the real um issue here **[05:54]** was that um someone had someone had added an external link of the image for an external server and in any moment or in any point the the image link was removed. That's why the images do didn't appear on the site. And Drupal empower empowers you if you start as a site builder, if you evolve **[06:25]** to a developer also learn from the community and expand your knowledge uh beyond Drupal. Um learning more about G composer and some tools that are necessary in this in this field. Developers need to learn the language syntax, control structures, logic operators, the API of the framework and we also need to level up our skills **[06:56]** uh learning about version control, debugging techniques like the session today, database management, testing, API integration, security and performance. And let me let me talk about debugging in Drupal. We need to know what things we need to know about Drupal. We need to know about site building concepts, nouns, nouns, users, views, blogs, theme regions, **[07:27]** about the core APIs, fields, entity, forms, database, extension points, about hooks, events, plugins, and services. And we also know uh about the s the ecosystem if this is something related to core or contrib or this is custom modules of things and let me get focused on on site building concepts uh because Drupal sites are like an onions and if you saw **[07:59]** the movie you you know that onions are like a layers And one quick example here is that if you have a Drupal site and you have a the sidebar for example and you are rendering the the most recent the most recent articles, you have the title and you also have the the teaser or like the summary. Those are fields and these **[08:32]** fields belongs to node and these nodes also are part of the view and this view also we can have a block to display and this block also can be rendered in in whatever part of the of the side in the region in the thin region and to swap uh also this example Uh we also can have the users instead of **[09:04]** node. We can have for example um the username. Uh we can have the username and we also can have the profile picture and this follow this this follow the the same example as this uh related to layers in in Drupal. >> Okay. Uh thank you. And now I'm going to talk about some strategies. And just for the record at the end there will be a link to a repository with a fully **[09:35]** configured datab environment that you can you know follow along what we will be doing as part of the demo. But for now and tools and strategies strategies uh you need to prepare uh before finding an issue. Hopefully you have some prior experience in particular with uh debugging tools and we're going to talk about them in a moment. having a proper ID, having a proper uh debugger, profiling tools and such and so on. But again like you don't you don't want to **[10:06]** just find an issue and do not know what to do or do not have any tools available. So first you know prepare with you with your tools then you need to analyze the problem to understand the scope. Wendy was talking about different layers and different uh elements that can be involved in a problem. Is this about the language itself? Is this a specific Drupal problem? Is this about infrastructure? Is this about something else outside of my control like in in a in a local environment? So, you need to be able to at least get an idea of where **[10:38]** the problem might be. Then, and this is very important, you need to be able to reproduce the issue hopefully in a local environment. Like sometimes people report something in production and this is not working. But are you able to reproduce that locally? And if so um how you need to give a steps then you need to simplify the issue to eliminate variables uh with the objective to reduce a scope something that I uh normally do if I have a Drupal **[11:08]** site with 100 modules and this has never happened of course uh something broke and I don't know where at least I get an idea of where things could go wrong. I start you know getting suspicious about a specific module. So sometimes I'm going to install a fresh Drupal site, a clean Drupal site with just Drupal core and only that module and try to replicate the issue there. If I am able to replicate it there, it means that I have pinpoint at least uh you know out of a 100 modules the one that is giving me the error and I can focus on that **[11:40]** specific uh area. Once you simplify the problem you you you divide it which means you know break break it down. There is a phrase in development uh that we say you know divide and conquer and that's what we we want to do. We let's say a model has different routes which of the routes is causing the issue or which of the services or which of the plugins like you need to get an idea or um you know sometimes guessing to be honest but uh most of the time with the tools that we're going to see and with **[12:11]** the techniques that we're going to see in a moment you will be able to at least get a sense of the code path that gets executed up to the point where the errors occur. So after you divide the problem, you solve it with the debugging techniques that we're going to cover and very important you document it because inevitably you're going to encounter this problem again sometime in the future very likely and you want to save yourself some time. And in this last point I want to share an anecdote from probably two weeks ago. Uh as Wendy said **[12:42]** I work a lot on migrations and very big migrations projects. There is one project in particular that for to run a full migration we spend at least three days and there was one specific field that was not working and we didn't want to wait 3 days in order to debug this. So you know we we started following this approach and it went like this. It was a migration problem. We had a Drupal 7 database and a Drupal 11 database. Okay, is this a database problem? Then we **[13:14]** started checking the migrations and the migrations seemed to be okay. Then we started looking at at at the PHP code and the PHP code seem to to be okay as well. In the end, we were able to trace the issue to a contributed module not related at all with the migration. Uh what what's happening is that we were dduplicating files on the fly and we were using the file name to match to know if something had already been uh migrated or not and we noticed that **[13:46]** there was an extra space in all of the cases where things weren't working and the reason was we were migrating files in Drupal 7 into media entity in Drupal 11. So we were doing conversions uh of entity types on top of that we were generating the the file name the excuse me the media name on the fly with uh automatic entity aliases and that module has a line of code which makes a lot of sense to remove extra or double or triple white spaces but that part was **[14:19]** breaking our complete logic about how to uh deduke files. So once we figure out the problem which again was not related to the migration but probably or assumptions wrong assumptions about how this other module worked uh we were able to patch our migration process and um and solve the issue. What I why I am mentioning this as part of documenting the problem because when I wrote that that specific migration for media, I left a handy comment saying **[14:49]** the file name is overridden by the entity label module. So that gave me the clue to know where to look at later on. Like we spent a good amount of time trying to reproduce the error because there were so many variables and that single comment saved us a lot of time in the end. So again like document it in code in the issue in the release notes document it somewhere because at some point you can be hit by that in the future. Now uh in terms of uh tools you know ids **[15:21]** it might be obvious but even some of the things that we can cover that we're going to cover today IDs give you syntax highlighting llinters a lot of things that are you know nowadays you give for granted they will just give you a give a big warning if something is completely like off. So have your IDs properly configured. uh debuggers. Xdebug is my tools of choice and pair with DD as we're going to see in the demo. It's very easy to set up and you get a lot of information about that uh about **[15:53]** problems. You can have profilers. Uh this is useful when you have performance issues. Um XH Prof is a common one. There is another called SPX. But again like it it is not about which tool you use. It is about having the proper tools to do the job. the the debugging, the researching, then version control. And why do we talk about version control as a tool for debugging? Um, again, this is part of the examples. But Drupal, you know that **[16:25]** it uses JAML files for a lot of things. And if you have been a longtime Drupal developer, you probably know by heart that the extension of JAMAL file is YML. But other communities not necessarily Drupal might use a different extension for the same type of files. I was I remember once debugging a problem like everything looked good and after doing a G status and seeing that the file name was wrong. I realized okay this is this is just the file extension that is **[16:56]** causing the whole problem. So again version control is yet another tool like looking at the file system is yet another tool that you can use to debug problems. database browsers. Um, you know, I will be saying this over and over. I work a lot with migrations and I need to understand that data, the content model, the structure of at the database level to be able to understand how to translate how things work in Drupal 7 to how things work in Drupal 11. So for me, a database browser, whether it is using **[17:26]** a CLI or a a GUI, uh, it is indispensable for my day-to-day job. Loggers and observability. So this can be as easy as a print f statement. You can have a show a drupal status uh on on the on the page. You can have something more fancy like new relic or just like dblog or syslog. You need to have information so that you are able to trace back uh the problem. uh digital journal again like probably **[17:59]** getting a little bit of a school showing my age here but uh you know just being able to take notes either on paper or in my case I just have a plain text file in which I start dumping ideas of what could go wrong what could be the issue that is uh that helps me a lot in like trying to understand and debug the problem and a watch um and this might seem weird but why do we want a watch because we need to know where when to take a break. Debugging can take hours **[18:29]** or days. And uh my usually rules of uh rule is spend up to two hours trying to solve an issue. And if you cannot do that in two hours and maybe that is too much already, take a pause, talk to someone, talk to your rubber dog on the table, ask Chad GPT about, you know, what could uh be the issue. But do not just keep going because you know you get stuck, you get frustrated and you stop making progress. So again like some some of **[18:59]** that uh tools are technical and so some of them are just about uh how you work and everybody works differently but you know know yourself and how you work best and in in in the state of mind that you have to be more effective uh with these type of uh of challenges. Okay. Uh, someone told me that there were issues with the projector. Oh no. Oh no. We got a bug. **[19:31]** We got a bug right in the middle of the session. Okay. Well, as you can see, we have a full party. So, don't panic. Don't panic. We will we will we will be able to make it. So, when something happens, something unexpected happen like this. Totally unexpected. Every bug have a cause. Bugs are computers are deterministics. Things do not happen just randomly. Um so it is very likely that you will you will be able to find a solution. Um if and this **[20:02]** is not always true but if you have an error message please read it carefully. Time and again I have seen people because uh I I give supporting like asking for something and the answer is in the same message that they paste. they get a a link to a documentation page that gives them exactly the steps that they need to follow to solve the issue, but they didn't take the time to read it. So even though it seems simple and obvious, please read the message and read it. Read it completely. Another **[20:34]** thing uh make a list of what you think could be the issue. Again like I have worked on projects in which I start with an idea. I know this is database related and in the end it is not. it is a module or it's PHP or it is you know caching or it's something completely different but that's why having a journal is useful you you jot down ideas you start um you know thinking about different options and you like explore them one at a time then this is super important before making any change form a hypothesis do **[21:07]** not do something hoping for the best like if I'm going to change this line of code what is my expectation And why I am doing this? You make the change and then you verify your hypothesis. If it didn't work, go back. Uh you don't want to be changing many things at the same time because if you do so, you will not know what was the line of code or the specific uh action that you took that actually solved the issue. So one thing at a time if you are **[21:38]** changing code and it is not always code when you just described an issue with in which uh it it was about content the content editors hot link to an external site and that is not something that is not code that we control that is something uh that was stored at the database uh and it was like kind of hard to track to be honest but point being if you are changing code one change at a time and commit every step along the Okay. Making uh I I like I like making **[22:09]** commits like the other day send a pull request with like 154 commits because I like to be very detailed and this is for my future self. If if I include a 100 changes in one commit and something goes wrong rolling back reverting that change is going to blow up the whole thing. But if I am very like specific you know this is doing this this is doing that I can I can you know individually revert commits and in the end like yes the pull request can have 100 plus commits but you can **[22:41]** squash them when you when you merge and it is just a simple commit but for people reviewing the change it is also easier because in every commit it's going to be a handful of line of codes and a handful of files and it is just like a better process for everyone but to be honest for yourself and you know as I said before uh talk to friends, talk to a robber dog, talk to checkd or cloud code or something like that. Uh do not try uh you know do not do not go in the wild alone. You need to **[23:12]** go with your friendly Pokémons and friendly uh other people that can help you along the way. So uh let's focus a little bit on some u practical debing techniques. Uh these are screenshots. I'm going to actually demo this uh uh later, but just to mention it, use a step debugger uh for PHP. Um on the bottom right, you have uh the option to to see and explore all the variables that are um um available in at at this **[23:45]** point in the debugging process. On the bottom left, you can see all the stack trace, all the functions that led you to this point in the code execution. uh the break point which is the red dot um you can actually make it conditional uh so that it only hits when specific conditions are met like when you're looking for a specific value uh and again like this is useful when you're migrating thousands of records and you know the specific ID causing the problem you don't want to step to stop in every **[24:16]** record you don't want to stop in that particular node for example and you also have the option to evaluate code on the fly So again this is going to be demoed later. But one thing one very nice thing about uh using a proper debugger which is like the right tool for the job is that you cannot only debug PHP but also tweak. So like you can set break points on tweak files and similarly you will be able to see the variables that are available objects that are available and you can call methods on those objects **[24:47]** and this is another way to to debug uh tweak uh just a little bit about this this is something that works out of the box with each storm but if you have a different ID of choice let's say BS code and there are two models that you can use uh one is lel and one is called twig debug. Uh that is going to give you a uh a statement like a line that you add to your twig file and uh that will work across every uh IDE but if you are using **[25:18]** PHP storm it is something that is available out of the box. Point being um the same way that you debug PHP, the same way that you debug Tweak, which ultimately Twix gets uh compiled to PHP, but you know that is a little bit back of the story, but uh it's also an option. Speaking of tweak, uh if you're aur, you might want to debug um templates. So, you know, Wendy mentioned like Drupal sites are built one layer on top of another. So you have the region **[25:48]** template. Inside of that you have the block template. Inside of that you have the view template and the note template and the fill template. And there are so many templates. Uh I used to do counts before and last time it was like Drupal core had in one of the base themes like 180 uh template files. So it's a lot. You don't want to be manually checking 180 files. So if you enable um the the tweak debugging you can specifically and directly go to the one file that is uh **[26:20]** responsible for producing the markup that you are looking in the screen. Now uh what you see here is the browser tools uh with the comments and speaking of that learn to use your browser tools. Um this is particularly useful for debugging uh JavaScript like you can basically step debug directly in your browser but do not like ignore the rest of the tabs. Uh I have used this to debug performance. I have used this to debug networking issues like what when was saying everything else looks right **[26:51]** but the image still doesn't load. Like if you go to the network tab you look at the URL not being loaded. you click on click on it and then you realize that you know something is not wrong with the source of the image and then okay yeah it it is not there anymore. Um the console tab is going to give you like JavaScript errors and such. So by all means like get familiar with uh the the developers tools that come included in your browser. Login uh again login can take many **[27:22]** shapes and forms. uh in this example I am setting a status of message that I can see in the in the Drupal UI but this can be something as a print f or uh or a bar dump or something like that. In general you want to have a way to log something and after the fact be be able to read it. Uh whether that goes to the database uh with DB log or to the syslog with the syslo module or with something else. Point being uh again um this is **[27:53]** yet another technique um something that I do more often that I would like to admit is blow up everything temporarily. Drupal is a complex application like it is built on top of symfony and a lot of other projects and some point and sometimes like you don't know what to do like you are out of ideas and how do I know if this code execution path is actually being hit so I just put a bomb explode everything for one second verify that I **[28:24]** actually hit the execution point and then I removed that line and I at least you know got confirmation that I am the right track to solve that issue. At least I am in the in the proper execution path. Uh one thing about die, Drupal tries to save you from dying and many times you need to clear the cache for die to actually take effect. But after one or maybe two uh cash uh reveals, usually you will see the bomb if you actually are in that execution **[28:56]** path. And um another thing uh search for the whole codebase. When you get an error message, one of the very first thing that I do is like I copy the message and try to look for it in the codebase. Uh in this case I am using my IDE but you can use GE like in the console. Um the one thing to remember is that many times error messages have placeholders. So you might not be able to find exact match but I start like removing some strings and then I find partial matches that are **[29:28]** useful. In this case I was getting uh a validation contains error and what I found was actually very useful. This string only appears twice in the whole of Drupal core. One in code that gets executed uh while the application is running and the second one uh in a test. So I know for a fact what is the execution path that is getting um followed but do not uh neglect the use the benefit of taking a look at the **[29:59]** test. The the test coverage in Drupal core is very helpful. Uh it has a lot of examples. It has a lot of comments. I remember the other day I was trying to debug a problem with uh uh form states API in um hierarchical uh taxonomy vocabulary and it was very messy and the solution and the example that I needed was in a Drupal test. So by looking at that test I was able to figure out the solution to my problem. Again like I am **[30:30]** saying a lot of things you know search the the code base look for test but ultimately uh debugging is not a straight path. You need to have you know some instinct you need to have several tools that you can uh leverage as needed and uh you know put them in to good use when when things uh go wrong. And similar to searching the whole codebase uh you can also search the whole file system. In in this case, I was looking for recipes and yes, I could use my ID, but something more useful was um using **[31:04]** my terminal, the find command to look all the recipes in Drupal core. I uh strip out anything that is a feature because that is a test recipe and then I sort alphabetically. So, this gave me an idea of what things I got available uh when working with recipes. And as you can see, like we go from the very technical to the crazy stuff to something more like manual, if you will, but in the end, all of these are tools at your disposal uh to be able to trace problems. And you won't be using everything all the time, but at least **[31:34]** knowing that they exist will give you an idea of what you can do uh you know along the way. So uh the last one that I want to share is uh inspect the database. Um in this case uh it is useful if you know the database structure of Drupal. So I can give you an an example. Every field in Drupal 11 creates two database tables. Uh one for uh the primary like the current data and one for revisions. The the the name of **[32:06]** the table is for notes node the machine name of the field that is for the current version node_revision fielding uh the machine of the field for all the history and it it comes with a specific uh you know table structure. So looking at this helps me understand how things work in Drupal 11. And if you were to look at something similar in Drupal 7, the naming combination is different. The columns might be different and ultimately we are doing transformation from one system to another. You need to understand how **[32:38]** things are wired under the hood. So um with all of that, we already got a a bug. Now we're going to do a live demo. Let's see how it goes. Uh by the way, that's the link. Uh and again it uh two things I want to point out. one um everything that we're doing is already available at the end. We're going to share links to the slide deck and the repo and everything. But two, Drupal is always evolving. Uh we saw yesterday a lot of innovation uh that there is no uh **[33:08]** but point being we have had over time um changed this uh repository because some of the books that bugs we found had already been fixed. So what I show today might not be working in the future uh or something uh got fixed but anyways we we try to keep this uh up to date with real examples that you can use of to actually test your skills. So with all of that I am going to change to my **[33:40]** browser one second. So this is my very complicated Drupal site. Um, I have one content type. I have two nodes. And these nodes were created using a migration because migrations are very fun to me. Um, and if I look at one of the nodes, I have a title and I have a link. Great. If I look at the other node, I have a title, but the link is empty. So, my migration didn't work. So, **[34:11]** let's start like debugging. If it is a migration, the first thing to to to look at is the migration file itself. Um, so what things to consider? One second. Of **[34:43]** course it's hard. Okay. Is this big enough? >> Yes, there is aation. >> Yeah, there used to be a shortcut but doesn't seem to be working in the debugging session. Of course. Well, we we we'll go with this. So, few things to to check. Um my migration is being detected. Um I can I can verify by doing a ddeb draw uh ms resources **[35:15]** and yes the migration is being detected two and I'm able to execute it. Yes because I already got some data and I can prove that I am not cheating by rolling back the migration and if I refresh the my page the items are not there. So for one my migration uh is being detected. It is possible to execute it. Uh by doing this I already discarded a problem with the file extension. Um I can look at the at the **[35:46]** code at the file itself. Um so I uh you know this is a very simple migration but I have an ID a title and the link that I want to show. Anybody knows what the problem is? >> Okay. about four people know about it but just for the sake of the example we're going to pretend that we don't know so first thing that I want to demo is using a debugger and again the debugger is the **[36:16]** tool you need to know how to use the tool and in particular with a debugger you need to know where to place the break point and this comes with trial and error this come with experience it comes uh with coming to sessions like this but point being uh if you go to migrate executable and you look for import you place a break point here and in X debug uh in PHP Storm this is how you enable the debugger **[36:47]** then one second you say DD X debug on and that's all that you need one command to enable debugging uh in within DEB and one click in the in the IDE to to say that you want to debug. So now I can run uh my migration with the debug flag. The debug flag is necessary. If you are using the draw 13 or later, if you are **[37:17]** using draw 12 or before, there is no debug flag. You don't need to use it. But we started with Dr. 13. Uh you need to be explicit when you want to uh enable debugging features uh when running Drush commands. So when I do this I I I hit a break point and again like why do I see here? This is my complete call stack. Uh I can see all the variables that are available. In this case, I know there is a row variable with a source array and **[37:51]** this contains the information that I am um you know hoping to import. I said before that you can evaluate uh code. So if let's say it's a row here and then you can you know any code get source property um then check unique ID ID and you get the value. Point being what do you have here? You have um **[38:23]** uh an you can execute evaluate code. You can see all the variables that are available. You can see your call stack and the break point if you right click on it you can make it conditional. So for example I can say I only want to hit this break point when this value is the the specific number that I am interested in debugging. So that that is how you make it conditional. If I let it run again like this time it hit the break point one because the the condition evaluated to true. If I execute this again, I am in **[38:55]** node 10,0002 and that's why I was able to hit it. If not, like if I were to roll back and import again, instead of hitting the break point twice, I will only do it once. Okay, all of this is to get a sense of of the debugger. And the debugger has the proper data. If I look at this, like Drupal is being able to read the data. Now, um, what else could go wrong? maybe something in the database like the migration thinks it is working but it is actually not storing it in the database. **[39:26]** So this is where the the the explorer work uh comes handy. So I'm using PHP uh my admin for the sake of it. This is a way to re review your database and remember uh what is the the the pattern node and then the machine name of the field. So in this case filled in and I see that my data is at the database in the database too like both of them are there yet something is not working as expected. Uh so I discarded a **[39:57]** second program it is not about the database. Now what field type is this? If I go to the content type, it is uh of type link. And in Drupal core, there is a pattern that um the class that defines a field, it is like the name of the field type plus item. So if I look for link item, this is the class that defines that specific field. And again like how do I know that I am on the right track? Uh **[40:28]** let's see the methods that are available. I am going to um check this get URL maybe I don't know die >> phone exactly >> it will we will we will this is just like part of the part of the exercise but we will put a break point at first I just want to know if at least I am on the right track and if I am on the right track then I can put a break point and start looking deeper into the problem so I come here and come to the content to **[41:00]** put or boom. So yes, I am on the right track. No need to clear cash this time. If I remove it and I refresh. Okay, now we follow the recommendation. We put a break point. So like one step at a time. I put a break point and I figured out that my breakpoint is not being hit. And this is where I said before sometimes Drupal is too good and it caches stuff. So you need to clear the cache for for this to take effect. So I'm going to clear the cache. the brush here. **[41:32]** I hide this and I have the I hit the break point now. At least I know I am in the right place. So let's inspect what we have available. URI URI I see something. But if I try to execute the whole thing myself, sorry, I get an error. And this is what people who raised their hands knew about. URI something something is invalid. You must **[42:02]** use a valid URI schema. So this is enough to give me a clue of what might be wrong. If we look again at the migration file, these two are not the same. This one has the HTTPS at the beginning. This one does not. So how do I solve the problem? I put the protocol. And to be fair, that message is not that helpful to determine this. But bear with me. We're going to to to do this in a bit. Um I'm going to add it here. And **[42:32]** before running rolling the migration again, I want to point out something else. If I click edit, yeah, I can see that there is data. And if I click save, sorry, I I get I get the uh a similar error um at the beginning here. you know something should start with these characters and again like sometimes error messages are kind of cryptic they might not be always helpful but just by **[43:04]** making some guesses uh you know things seem things things are looking like promising so I'm going to remove my break point one and I'm going to roll back the migration I'm going to clear the cache because if you change the yaml file you need to clear the cache for changes to be detected Ed and I run the migration again. This time without the XD box flag. So it is just going to run and I come back to content and I go to this and to this and my link is there and my **[43:36]** link is there. So again like yes uh Drupal 11 is more uh salos with how you pro uh enter links and you need to provide the schema in this case the HTTPS was missing and that was breaking the whole thing and as you saw the migration was working at the database level things were there um the problem ended up being um how the validation logic for rendering that the link item ended up uh important just you know for **[44:07]** for your own homework there are other exercises like you can go to this reposit clone it and there are the explanation of what is wrong and if you want to cheat you can also click the solutions and it's going to tell you the solutions I'm going to show them here for you to try at home but uh you know this repository has been evolving over time to have different examples that you can use to practice your debugging skills and uh yeah with that the demo didn't go that bad thankfully. So I just **[44:40]** want to uh you know Wendy gave a beautiful shared a beautiful quote by Leos. I'm going to share one too. A great way to learn something is finding a working example and breaking it on purpose. And if you haven't heard this before is because I just made it up right now on the spot. But in all seriousness uh this is how I learn. This is how I learn. Like I look for something that works. I start breaking things like changing in in the jumble file, change the file extension, it breaks. If you get familiar with the type of errors that you get, the next time that you see **[45:12]** them, you're it's going to take you less time to debug the problem with uh in one of the examples, the solution is you didn't indent the Java file properly. Another example, the file extension is different. Another example, you are missing a semicolon. You know, it's like if you find something that works and you start breaking it on purpose, get used to the errors that you that you that get generated, the next time that you encounter something in the wild, in the real life, in a production website, you are going to be better equipped to solve **[45:43]** those problems. And the other thing that I want to uh mention is uh let's debug all the things. Uh thank you very much to Randy Fay. is a proficient developer but more than that an amazing human being. We worked together on a similar session and many of the things that we we show today actually was collaboration with him and he's actually the lead maintainer of DD which saved me hours of time. So thank you for that. And I also want to invite you to the mentoring. This is happening all week long but **[46:14]** especially on Friday if you will be here uh by all means come and you know something I didn't say but another way to learn is by teaching and uh in mentoring we're going to teach you not only debugging techniques but also how to get involved in Drupal how to learn from the community and um you know um it is a a great learning experience from learning from others and yeah thank you very much the slides are available and my is available **[46:44]** I think we are right on time, but if there are questions, we're happy to to stay a little bit longer to answer them. >> Yes, >> I have uh one comments. Um a tool that I also use. >> Thanks. Yeah. So, I have more of a comment. So, one tool that I like to use for debugging as well is the Drush PHP shell. So that's also very helpful. >> Yes, that actually reminds me just for the recording uh Dr. PHP eval gives you **[47:15]** a Drupal CLI where where you can actually like directly from there call services load entities and all of that. So if you have not looked at that before in the documentation look for uh PHP val and they have examples how to load nodes and call services and yeah that's another very useful way to thank you for sharing. Any other comment or question? Yes. >> What do you do with a 3 kilometer long back trace error? **[47:46]** >> Okay. What do I do with a 3 km back trace? Uh to be honest, those are a little bit harder to to figure out. Uh and not because they are long, but because Drupal the execution path sometimes takes some detours that are crazy. uh my what I start doing is like you know I put a break point start looking back back and if you know five levels before I don't find something useful I try a different technique sometimes uh you know I try to look for the error like like copy the the copy of **[48:17]** the of the error and look for that instead of using directly the debugger and that you know that's an option in the end like again like there is no one technique that will solve all the issues but if you are able to combine them um you get there. But in the case of crazy stack trace like you know I basically give up with that approach like five levels deep and after that I try something different. >> Thank you. >> Yeah. Anything else? **[48:47]** >> I guess we're good. Thank you very much.