<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Development — Articles | WebPro Company OÜ</title>
    <link>https://webpro.company/blog/tag/development/</link>
    <atom:link href="https://webpro.company/blog/tag/development/rss.xml" rel="self" type="application/rss+xml" />
    <description>WebPro Drupal development projects — building new websites and applications from scratch or on top of an existing codebase.</description>
    <language>en-US</language>
    <lastBuildDate>Thu, 18 Jun 2026 06:00:00 GMT</lastBuildDate>
    <item>
      <title>Drupal admin interface as an editorial workbench</title>
      <link>https://webpro.company/blog/drupal-admin-interface-editorial-workbench</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-admin-interface-editorial-workbench</guid>
      <pubDate>Thu, 18 Jun 2026 06:00:00 GMT</pubDate>
      <category>Development</category>
      <category>Drupal</category>
      <category>Maintenance</category>
      <description>Drupal is a strong platform for complex digital services, but its long-term value depends on how well people can use it every day. The admin interface should support the editorial team, not slow it down. The admin interface is part of service quality Public-facing user experience usually receives most of the attention. That is understandable. Visitors, residents, students, customers or partners see the public website first. But there is another important user group: the people who create, update, translate, review, publish and archive content. When their work happens in a slow or confusing admin interface, the impact appears quickly: content is updated less often; errors remain visible for longer; editors need more support; developers are asked to handle changes the content team should…</description>
    </item>
    <item>
      <title>Drupal CMS 2.0 and Canvas in a client project</title>
      <link>https://webpro.company/blog/drupal-cms-20-canvas-client-project</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-cms-20-canvas-client-project</guid>
      <pubDate>Thu, 18 Jun 2026 06:00:00 GMT</pubDate>
      <category>Drupal</category>
      <category>AI</category>
      <category>Development</category>
      <description>Drupal CMS 2.0 promises a faster start, visual page building and AI-assisted workflows. In a client project, the important question is not only how good the demo looks, but how the solution behaves two years later. Drupal CMS 2.0 was released on 28 January 2026. Its main themes are Canvas, AI tools and site templates. Drupal.org describes it as a way for marketing teams to launch branded sites faster. This is an important shift for Drupal. Drupal has long been strong for complex systems, but getting started has often required more technical work than simpler CMS products. Drupal CMS is an attempt to reduce that friction. What changed in Drupal CMS 2.0? Drupal CMS 2.0 is not a separate technology branch. It is still Drupal, but with a new starting point. The main changes include: Canvas…</description>
    </item>
    <item>
      <title>Component-based Drupal — how it is built in practice</title>
      <link>https://webpro.company/blog/component-based-drupal</link>
      <guid isPermaLink="true">https://webpro.company/blog/component-based-drupal</guid>
      <pubDate>Mon, 08 Jun 2026 06:00:00 GMT</pubDate>
      <category>Development</category>
      <category>Drupal</category>
      <description>Drupal has several ways to build a page from components. Which one fits depends on whether the layout decision belongs to the editor or the developer. Component-based development means that page content and design are built from reusable blocks — each block is self-contained, tested and usable in multiple places. The opposite approach is page-by-page design: every page has its own layout, there are no shared components, and code is duplicated. In Drupal, this is an architectural choice made at the start of a project. Changing it later is expensive. Why it suits Drupal particularly well Drupal is strongly content-oriented. Content is structured — fields, content types, taxonomy. That structure provides a natural foundation for components: when content is defined as fields, the same…</description>
    </item>
    <item>
      <title>Contact form without reCAPTCHA — catching bots without Google</title>
      <link>https://webpro.company/blog/contact-form-without-recaptcha</link>
      <guid isPermaLink="true">https://webpro.company/blog/contact-form-without-recaptcha</guid>
      <pubDate>Mon, 08 Jun 2026 06:00:00 GMT</pubDate>
      <category>Development</category>
      <category>GDPR</category>
      <description>Most spam on contact forms does not come from humans — it comes from bots. Bots behave differently from humans, and that difference is enough to build protection on without Google&apos;s help. Why replace reCAPTCHA reCAPTCHA v3 works — that cannot be denied. Google&apos;s model is trained on billions of signals and the score-based approach is intelligent. But it comes at a price that is not paid in money. Privacy. reCAPTCHA loads a script from Google that tracks the user throughout the browser session. Google learns which site the user visited and when. This is not hypothetical — it is their business model. GDPR. Because of the third-party tracking, using reCAPTCHA formally requires user consent. In practice many sites ignore this requirement, but that does not make it compliant. Load time. The…</description>
    </item>
    <item>
      <title>Headless Drupal — when it actually makes sense</title>
      <link>https://webpro.company/blog/headless-drupal-when-it-makes-sense</link>
      <guid isPermaLink="true">https://webpro.company/blog/headless-drupal-when-it-makes-sense</guid>
      <pubDate>Sun, 07 Jun 2026 06:00:00 GMT</pubDate>
      <category>Development</category>
      <category>Drupal</category>
      <description>Headless has been a popular term for a few years. Like all architectural choices, it suits some projects well and others not at all. Headless Drupal means Drupal serves only as the backend — managing content, users, permissions and delivering data through an API. The frontend — what visitors actually see — is built with a separate technology: Next.js, Gatsby, Vue, React or another framework. The alternative is &quot;coupled&quot; or traditional Drupal, where Drupal manages content and also renders HTML directly to the browser. When headless is justified Multiple channels, one content source When the same content needs to reach a website, a mobile app, digital signage and partner APIs — headless is the natural choice. Drupal manages content in one place and each channel consumes it in its own…</description>
    </item>
    <item>
      <title>How much does a Drupal website cost?</title>
      <link>https://webpro.company/blog/drupal-website-cost</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-website-cost</guid>
      <pubDate>Fri, 05 Jun 2026 06:00:00 GMT</pubDate>
      <category>Development</category>
      <category>Drupal</category>
      <description>&quot;How much does a Drupal website cost?&quot; — there is no single answer, because Drupal is a platform, not a product. Here is what the price actually covers. Drupal website pricing cannot be approached like buying a car. The same question can mean a simple informational site, a complex information system with CRM integrations, or a hospital where hundreds of editors with different roles manage content. Option A and option B differ by a factor of ten. This is why honest developers will not give you a price before understanding what you actually need. What affects the price Functional complexity Drupal contrib modules cover many common needs — news feeds, events, multilingual support, user management, search. If you need something that off-the-shelf modules do not cover, it needs to be…</description>
    </item>
    <item>
      <title>AI builds your site and deploys it. But who&apos;s responsible?</title>
      <link>https://webpro.company/blog/ai-builds-and-deploys-sites</link>
      <guid isPermaLink="true">https://webpro.company/blog/ai-builds-and-deploys-sites</guid>
      <pubDate>Thu, 04 Jun 2026 06:00:00 GMT</pubDate>
      <category>AI</category>
      <category>Development</category>
      <description>OpenAI Codex Sites builds a website and hosts it automatically — no server to manage, no web developer needed. Sounds great. But who&apos;s responsible when something goes wrong? OpenAI recently launched Codex Sites — a tool that lets you describe what you want and receive a working, hosted website in return. No server to set up, no code to publish, no web developer to call. It sounds like a revolution. And in some ways, it is. What Codex Sites actually does Codex Sites builds web projects and hosts them automatically on Cloudflare&apos;s infrastructure. You describe what you want, the tool writes the code and puts it live. It comes with a database, file storage, and settings management built in. In short: idea → working site, in minutes, without opening a single terminal. Currently available to…</description>
    </item>
    <item>
      <title>Drupal multisite — one platform, multiple websites</title>
      <link>https://webpro.company/blog/drupal-multisite</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-multisite</guid>
      <pubDate>Mon, 01 Jun 2026 06:00:00 GMT</pubDate>
      <category>Development</category>
      <category>Drupal</category>
      <description>When an organisation runs multiple websites — different brands, regions or products — that does not necessarily mean multiple separate platforms. Drupal is one of the few CMS platforms that supports multisite configuration natively in core. This means a single Drupal installation can serve multiple websites with a shared codebase, shared modules and a shared update process — but with separate content, users and configuration per site. When multisite makes sense Works well when: The organisation runs multiple structurally similar sites — regional offices, subsidiaries or separate brands The sites share functional requirements — common modules, shared design logic, shared integrations You want security updates and Drupal version upgrades to happen for all sites at once, not separately…</description>
    </item>
    <item>
      <title>Modern website checklist — security, performance, GDPR and AI readiness</title>
      <link>https://webpro.company/blog/modern-web-requirements</link>
      <guid isPermaLink="true">https://webpro.company/blog/modern-web-requirements</guid>
      <pubDate>Sat, 30 May 2026 06:00:00 GMT</pubDate>
      <category>Development</category>
      <description>The question is no longer only whether a website works. It must meet a range of parallel requirements — some regulatory, some technical, some tied to how search engines and AI agents read the web. The context for running a website has shifted significantly over the past few years. Some changes have accumulated gradually: security headers, HTTPS, cookie consent, accessibility requirements. Others are newer: AI agents retrieve information directly from the web, search engines evaluate pages across different signals, and user devices are more varied than ever before. The result is that a website today must meet multiple requirements simultaneously — requirements that are largely independent of each other, each owned by a different part of the team, and all affecting whether the site works…</description>
    </item>
    <item>
      <title>Who builds a modern website — the skills and roles involved</title>
      <link>https://webpro.company/blog/modern-website-team</link>
      <guid isPermaLink="true">https://webpro.company/blog/modern-website-team</guid>
      <pubDate>Sat, 30 May 2026 06:00:00 GMT</pubDate>
      <category>Development</category>
      <description>When a website must meet security, performance, accessibility, privacy and SEO requirements at the same time, it is no longer a one-person job. Each layer needs its own expertise — and those areas of expertise must fit together. When a web project starts, the question often comes up: &quot;Do we just need a developer?&quot; The answer depends on what the website has to do. If it only needs to exist — perhaps. If it must work, be secure, findable, accessible, fast and legally sound — no. A modern website is a layered system. Each layer has its own specialist and its own area of responsibility. In a small team, one person carries several roles. In a larger team, those roles are separated. Either way, the skills must be present. Product owner or project manager Someone must know what the website…</description>
    </item>
    <item>
      <title>How WebPro built its website — custom build, AI-assisted, honest review</title>
      <link>https://webpro.company/blog/how-webpro-website-was-built</link>
      <guid isPermaLink="true">https://webpro.company/blog/how-webpro-website-was-built</guid>
      <pubDate>Thu, 28 May 2026 06:00:00 GMT</pubDate>
      <category>Development</category>
      <category>Custom development</category>
      <category>AI</category>
      <description>The WebPro website is not Drupal and not a ready-made framework. It is a Node.js static generator written from scratch, with most of the code written by AI. This is an honest account of how that happened and what it actually meant. Why not Drupal Drupal is what WebPro works with every day. But Drupal makes sense where there is complex content management logic, multiple user roles, integrations or a need for non-technical people to manage content. The WebPro website has none of those needs. There are about a dozen pages, no content editors, and content changes infrequently. Drupal would have brought all its obligations along — security updates, modules, a database, a deployment process — with nothing to gain. It would have been the wrong tool. Why not a ready-made framework The next…</description>
    </item>
    <item>
      <title>AI as a developer-guided assistant</title>
      <link>https://webpro.company/blog/ai-as-developer-assistant</link>
      <guid isPermaLink="true">https://webpro.company/blog/ai-as-developer-assistant</guid>
      <pubDate>Sat, 16 May 2026 06:00:00 GMT</pubDate>
      <category>AI</category>
      <category>Development</category>
      <description>AI is not a tool that should act alone inside a client system. It is most useful when a person guides, checks and decides. Drupal projects often have many layers: content types, views, permissions, modules, custom code, external connections and older decisions. AI can help find first patterns faster, but it does not know which decision is commercially right or technically responsible. Where AI helps Understanding and mapping code. When a project arrives without documentation, AI can help faster with understanding what custom modules do, which external integrations are in use and where the risky areas are. It does not replace reading the code, but it reduces the time needed for initial mapping. Checklists and processes. Migration, upgrades or security incident response all require a…</description>
    </item>
    <item>
      <title>AI in code review: benefits, limits and responsibility</title>
      <link>https://webpro.company/blog/ai-in-code-review</link>
      <guid isPermaLink="true">https://webpro.company/blog/ai-in-code-review</guid>
      <pubDate>Wed, 13 May 2026 06:00:00 GMT</pubDate>
      <category>AI</category>
      <category>Development</category>
      <description>AI works well as a code review assistant when it helps raise questions. It should not be the final authority on whether a change is safe and business-correct. What AI notices well AI tools such as OpenAI and Anthropic can quickly find repetition, inconsistent patterns and places where reviewers should ask more questions. In code review, AI helps: summarise a large diff; find missing error handling; compare a change with existing patterns; suggest test cases; notice missing documentation. Where responsibility stays human AI does not always know the project history, client workflow or server constraints. It can suggest a solution that is theoretically correct but wrong in this project. WebPro uses AI as an assistant in Drupal work, combined with tests and developer review. If a change…</description>
    </item>
    <item>
      <title>Why we automate Drupal work as much as possible</title>
      <link>https://webpro.company/blog/git-composer-and-automated-drupal-workflow</link>
      <guid isPermaLink="true">https://webpro.company/blog/git-composer-and-automated-drupal-workflow</guid>
      <pubDate>Tue, 12 May 2026 06:00:00 GMT</pubDate>
      <category>Drupal</category>
      <category>Development</category>
      <category>Testing</category>
      <description>Good Drupal work is not only about writing code. It is also about how a change moves from a developer machine to a test environment and then to the public website. Drupal projects can easily drift into a risky pattern: small fixes are made directly on the server, files are moved manually and nobody remembers exactly what changed or when. That may feel fast at first, but it becomes dangerous when the website is business-critical, includes an online store, uses integrations or has more than one developer. That is why WebPro tries to make as much work as possible automated and repeatable. This does not remove people from the process. The opposite is true: people stay responsible, while repeated steps are written down and can be checked. Git gives the project memory Git is not only a…</description>
    </item>
    <item>
      <title>Drupal go-live checklist</title>
      <link>https://webpro.company/blog/drupal-go-live-checklist</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-go-live-checklist</guid>
      <pubDate>Fri, 08 May 2026 06:00:00 GMT</pubDate>
      <category>Development</category>
      <category>Drupal</category>
      <description>A new or updated Drupal site goes live more smoothly when the final day is not driven by memory. Go-live starts before launch day A Drupal go-live is not only pointing a domain or uploading code. By that point, the team should know exactly what is being released, how the result will be checked and how to roll back if needed. A good checklist keeps attention on the things that are often missed during the final rush. Before going live Before the public change, at least these points should be ready: a fresh backup of database, files and code; a known rollback plan; tested forms; checked administrator permissions; correct email settings; reviewed redirects from old URLs; checked titles, meta descriptions and sharing images; sitemap and robots.txt; a cache clearing plan. If the site is…</description>
    </item>
    <item>
      <title>Website budget: work that is often missing</title>
      <link>https://webpro.company/blog/hidden-work-in-a-website-budget</link>
      <guid isPermaLink="true">https://webpro.company/blog/hidden-work-in-a-website-budget</guid>
      <pubDate>Tue, 28 Apr 2026 06:00:00 GMT</pubDate>
      <category>Development</category>
      <description>Website cost is not only design and development. Budget is also affected by content, migration, testing, accessibility and maintenance after launch. What is often forgotten Quotes can easily show only the visible part. A real project also needs work the user does not directly see. The budget should include: content cleanup and entry; old content migration; testing forms, emails and spam protection; SEO metadata and structured data; WCAG checks; backups, staging and release planning; maintenance after launch. Why it should be visible early If necessary work is left out of the quote, it does not disappear. It returns later as a change request, debugging cost or weaker result. WebPro helps map scope before a decision through audit and testing. In Drupal projects, we usually connect the…</description>
    </item>
    <item>
      <title>What to ask a web developer before signing</title>
      <link>https://webpro.company/blog/what-to-ask-a-web-developer-before-signing</link>
      <guid isPermaLink="true">https://webpro.company/blog/what-to-ask-a-web-developer-before-signing</guid>
      <pubDate>Tue, 14 Apr 2026 06:00:00 GMT</pubDate>
      <category>Development</category>
      <description>Web project problems do not come only from code. They often come from failing to agree how the result will be tested, handed over and maintained. Questions before starting Before development, ask concrete process questions. They are not a formality. They help assess whether the project will be maintainable later. Ask: whether source code will be handed over in Git; how the staging environment will work; which manual or automated tests are planned; how backups are made before release; who handles security updates after launch; whether standard tools such as Composer are used. Why this matters in Drupal projects Drupal is a long-lived platform. If the workflow is weak at the start, the client pays for that later during maintenance, migration or debugging. WebPro approaches new work so…</description>
    </item>
    <item>
      <title>What a good web project brief contains</title>
      <link>https://webpro.company/blog/web-project-brief</link>
      <guid isPermaLink="true">https://webpro.company/blog/web-project-brief</guid>
      <pubDate>Sat, 11 Apr 2026 06:00:00 GMT</pubDate>
      <category>Development</category>
      <description>A brief is not a formality — it is an agreement. The more precisely it describes what needs to be done, the less room there is for interpretation, surprises and extra costs later. Many web projects start with a vague description: &quot;we need a new website&quot; or &quot;we want to redesign the site&quot;. That is not a brief — that is a wish. A brief is a document that describes precisely what needs to be done, and on the basis of which an accurate estimate and work plan can be made. What a good brief contains Business goal The most important question is: what does this website need to do from a business perspective? Not &quot;which pages are needed&quot;, but &quot;what changes when this website is ready&quot;. Is the goal to find new clients? Is it self-service for existing clients? Is it sharing internal information…</description>
    </item>
    <item>
      <title>Technical debt in web projects — how it builds and what it costs</title>
      <link>https://webpro.company/blog/technical-debt-in-web-projects</link>
      <guid isPermaLink="true">https://webpro.company/blog/technical-debt-in-web-projects</guid>
      <pubDate>Sat, 04 Apr 2026 06:00:00 GMT</pubDate>
      <category>Development</category>
      <category>Maintenance</category>
      <description>Every web project accumulates technical debt over time. That is not a failure — it is inevitable. The question is whether it is managed consciously or left to grow until it becomes an obstacle. Technical debt is a metaphor borrowed from finance: like financial debt, technical debt accumulates interest. The longer it is left unaddressed, the more expensive it becomes. What technical debt is Technical debt is the gap between how something is built and how it should be built. That gap forms through: decisions made under time pressure — a tight deadline, a simple solution that works but is not sustainable; gaps in knowledge — the best approach known at the time, which later turns out to be wrong; changing requirements — the original architecture did not account for later needs;…</description>
    </item>
    <item>
      <title>When Drupal needs refactoring, not only an update</title>
      <link>https://webpro.company/blog/when-drupal-needs-refactoring</link>
      <guid isPermaLink="true">https://webpro.company/blog/when-drupal-needs-refactoring</guid>
      <pubDate>Tue, 17 Mar 2026 06:00:00 GMT</pubDate>
      <category>Development</category>
      <category>Drupal</category>
      <description>A Drupal upgrade improves the platform&apos;s technical state, but it does not automatically fix a poorly designed workflow, data model or custom code. Signs that an update is not enough Updating Drupal is necessary, but sometimes refactoring must happen before or alongside it. Warning signs include: every small change breaks something unexpected; custom modules mix business logic with presentation logic; content types duplicate each other; editors rely on workarounds; testing depends only on manual clicking. Refactoring must have a reason Refactoring is not making code prettier for developer preference. It must reduce risk, simplify maintenance or make future changes cheaper. WebPro usually assesses this during audit and testing. If the problem is clearly in custom code or the data model,…</description>
    </item>
    <item>
      <title>Drupal Search API — search that actually works</title>
      <link>https://webpro.company/blog/drupal-search-api</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-search-api</guid>
      <pubDate>Thu, 18 Sep 2025 06:00:00 GMT</pubDate>
      <category>Development</category>
      <category>Drupal</category>
      <description>Search is often the most-used feature of a site — and the most often done poorly. Here is how to set it up properly in Drupal. Drupal Core includes a basic search function built on MySQL full-text search. This works for a few hundred pages. But when a site has thousands of content items, multilingual content, complex filters and autocomplete suggestions — a different solution is needed. Search API module Search API is Drupal&apos;s de facto standard for advanced search. It decouples the search index from the database and allows using external search engines. Search API provides: Indexing — define which content types and fields are indexed Server abstraction — the same configuration works with Solr, Elasticsearch or database search Views integration — search results displayed via Drupal…</description>
    </item>
    <item>
      <title>Drupal Paragraphs module — flexible content builder</title>
      <link>https://webpro.company/blog/paragraphs-module-drupal</link>
      <guid isPermaLink="true">https://webpro.company/blog/paragraphs-module-drupal</guid>
      <pubDate>Thu, 14 Aug 2025 06:00:00 GMT</pubDate>
      <category>Development</category>
      <category>Drupal</category>
      <description>Paragraphs makes content structured and editor-friendly — but requires thoughtful component design upfront. Paragraphs is one of Drupal&apos;s most widely used contributed modules. It enables building page content as components: a text block, image + text, video block, CTA button, accordion, table — each as a separate component that editors can reorder and configure. Why Paragraphs instead of a plain text editor? A plain long text field (WYSIWYG) is flexible but problematic: Design depends on what the editor puts in the WYSIWYG Styles diverge across different editors Layout can break unpredictably on mobile Content is hard to restructure later Paragraphs solves this with structured components: each component is a separate entity with defined fields. Editors cannot accidentally apply the…</description>
    </item>
    <item>
      <title>Drupal Layout Builder vs Paragraphs — when to use which</title>
      <link>https://webpro.company/blog/drupal-layout-builder-vs-paragraphs</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-layout-builder-vs-paragraphs</guid>
      <pubDate>Tue, 10 Dec 2024 06:00:00 GMT</pubDate>
      <category>Development</category>
      <category>Drupal</category>
      <description>Two common approaches to flexible page building in Drupal. Here is what sets them apart and when to use which. Why this question comes up Most Drupal projects need flexible page building at some point — editors need to add different blocks, sections, text and images without calling a developer every time. The two most common solutions are Paragraphs (a contributed module) and Layout Builder (a Drupal core feature since 8.5). Both work, but in different ways. Paragraphs — what it is Paragraphs is a module that adds a list field to content types where different types of &quot;paragraphs&quot; can live — text block, image block, quote, video block, CTA, etc. Editors build a page by adding paragraphs in sequence. Each paragraph is a separate entity with its own fields. Strengths: Simple for editors…</description>
    </item>
    <item>
      <title>Drupal Views — what it is and when it falls short</title>
      <link>https://webpro.company/blog/drupal-views-when-it-falls-short</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-views-when-it-falls-short</guid>
      <pubDate>Mon, 18 Nov 2024 06:00:00 GMT</pubDate>
      <category>Development</category>
      <category>Drupal</category>
      <description>Views is at the heart of Drupal — almost every listing, search result and archive is powered by Views. Here is what it is and where it falls short. What Drupal Views is Views is a Drupal core module that lets you query the database through a visual interface — without writing SQL. You choose which content types to show, which fields to include, which filters to apply, how to sort, and whether to paginate. Practically every &quot;listing&quot; in Drupal is a View: News listing on the homepage Blog post archive User list in the admin interface Search results Related articles at the end of a post Views is one of Drupal&apos;s biggest strengths — it dramatically reduces the amount of code that needs to be written. What Views does well Simple filtering — show only published content of a certain type,…</description>
    </item>
    <item>
      <title>Drupal Migrate API — how to bring content from another system</title>
      <link>https://webpro.company/blog/drupal-migrate-api</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-migrate-api</guid>
      <pubDate>Thu, 24 Oct 2024 06:00:00 GMT</pubDate>
      <category>Migration</category>
      <category>Drupal</category>
      <category>Development</category>
      <description>Content migration is part of every significant Drupal project. Migrate API is the right tool for the job — here is how it works and what to plan for. What Migrate API is Drupal Migrate API is a core framework for importing content from different sources in a structured way. It has three parts: Source — where data comes from (old Drupal database, CSV, JSON, XML, REST API, Excel file, etc.). Process — how data is transformed (renaming fields, converting values, filtering, resolving references). Destination — where data goes (Drupal node, taxonomy term, media entity, user, etc.). Common migration scenarios Drupal 7 → Drupal 11 The most common migration. Drupal provides official migration modules (, ) that understand Drupal 7&apos;s data structure. These migrate automatically: Content types and…</description>
    </item>
    <item>
      <title>Drupal configuration management — why config sync matters</title>
      <link>https://webpro.company/blog/drupal-configuration-management</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-configuration-management</guid>
      <pubDate>Thu, 05 Sep 2024 06:00:00 GMT</pubDate>
      <category>Development</category>
      <category>Drupal</category>
      <description>Drupal configuration — content types, views, fields, roles — lives in the database. Config sync moves it to git. Here is why that changes everything. The problem without config sync A classic scenario: a developer makes changes in the development environment — adds a field, modifies a view, creates a new content type. Now this needs to go to production. Without config sync the options are bad: Make the changes manually in production (double work, error-prone) Hope you remember exactly what you changed Export the database from development and import it to production (which wipes production content) What config sync is Since Drupal 8, configuration can be exported from the database to YAML files. These files can be committed to git and synchronised between environments. The result: all…</description>
    </item>
    <item>
      <title>Drupal custom module development — when it makes sense and what it costs</title>
      <link>https://webpro.company/blog/drupal-custom-module-development-cost</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-custom-module-development-cost</guid>
      <pubDate>Wed, 14 Aug 2024 06:00:00 GMT</pubDate>
      <category>Development</category>
      <category>Drupal</category>
      <category>Custom development</category>
      <description>Drupal has thousands of contributed modules — but sometimes none of them cover the exact need. Here is when a custom module is the right choice and what it means. When a custom module is the right choice Drupal.org has over 50,000 modules. Before commissioning custom development it is always worth checking: Is there an existing module that does this? Can an existing module be configured to cover the need? Can the module&apos;s behaviour be extended through hooks or plugins? If the answer to all three is &quot;no&quot; — a custom module is the right choice. Typical reasons to build a custom module: Integration with a specific external system (ERP, CRM, payment gateway) Business logic unique to the organisation Performance-critical functionality that a general module does not optimise enough You need…</description>
    </item>
    <item>
      <title>How long does a Drupal project take — realistic timelines</title>
      <link>https://webpro.company/blog/drupal-project-timeline</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-project-timeline</guid>
      <pubDate>Mon, 22 Jul 2024 06:00:00 GMT</pubDate>
      <category>Drupal</category>
      <category>Development</category>
      <description>The Drupal project timeline is one of the most asked and most underestimated topics. Here are realistic estimates and what actually drives the schedule. Why timelines slip Before the numbers — why Drupal projects (and IT projects in general) take longer than planned: Content arrives late — the client promises to send content &quot;quickly&quot; but it takes weeks. Without content you cannot finish design; without design you cannot finish development. Decisions are delayed — &quot;should the logo go here or there&quot; can halt development for days if the decision-maker is unavailable. Scope creep — new features are added during the project. Every &quot;small thing&quot; adds days. Testing is underestimated — &quot;testing will take a week&quot; is rarely true. A complex project needs several weeks of testing. Realistic…</description>
    </item>
    <item>
      <title>Fixed price vs hourly rate — which suits a Drupal project</title>
      <link>https://webpro.company/blog/fixed-price-vs-hourly-drupal</link>
      <guid isPermaLink="true">https://webpro.company/blog/fixed-price-vs-hourly-drupal</guid>
      <pubDate>Wed, 15 May 2024 06:00:00 GMT</pubDate>
      <category>Drupal</category>
      <category>Development</category>
      <description>&quot;How much will it cost?&quot; — the answer depends on how the contract is structured. Fixed price and hourly rate are both reasonable, but in different situations. Fixed price The client and developer agree: &quot;this functionality, at this price, by this deadline.&quot; When it works Scope is clearly defined — a detailed brief, design is ready, requirements are written down Risk of change is low — the project is simple and of a familiar type Client has a hard budget limit that cannot be exceeded Hidden costs of fixed price The developer carries the risk — if the work takes longer, they lose. To cover this risk, a risk premium is added to the quote — typically 20–40%. You pay this whether the project runs over or not. Additionally: if scope is not precisely defined, disputes arise about what is…</description>
    </item>
    <item>
      <title>How Drupal projects stall — and how to avoid it</title>
      <link>https://webpro.company/blog/why-drupal-projects-stall</link>
      <guid isPermaLink="true">https://webpro.company/blog/why-drupal-projects-stall</guid>
      <pubDate>Wed, 10 Apr 2024 06:00:00 GMT</pubDate>
      <category>Drupal</category>
      <category>Development</category>
      <description>A Drupal project is not just stalled when the code does not work. It is stalled when invoices keep growing, deadlines keep slipping, and nobody knows what happens next. Reason 1: The brief is vague &quot;We want a modern Drupal site with everything we need&quot; is not a brief. It is a wish. The developer starts, does their best guess, the client sees the result and says &quot;that&apos;s not what we had in mind.&quot; Both sides are frustrated and neither is strictly at fault. Solution: A written functional brief before development begins. At minimum: which pages are needed, which features, who the users are, what integrations are required. Reason 2: Decisions are delayed The developer is waiting for the client: &quot;should this button be red or blue, and should the form send email to HR or management?&quot; The…</description>
    </item>
  </channel>
</rss>
