<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Maintenance — Articles | WebPro Company OÜ</title>
    <link>https://webpro.company/blog/tag/maintenance/</link>
    <atom:link href="https://webpro.company/blog/tag/maintenance/rss.xml" rel="self" type="application/rss+xml" />
    <description>Drupal website maintenance — module updates, security patches and long-term technical support keeping your site stable.</description>
    <language>en-US</language>
    <lastBuildDate>Thu, 02 Jul 2026 06:00:00 GMT</lastBuildDate>
    <item>
      <title>Why does Drupal get slower over time?</title>
      <link>https://webpro.company/blog/why-drupal-gets-slower-over-time</link>
      <guid isPermaLink="true">https://webpro.company/blog/why-drupal-gets-slower-over-time</guid>
      <pubDate>Thu, 02 Jul 2026 06:00:00 GMT</pubDate>
      <category>Performance</category>
      <category>Drupal</category>
      <category>Maintenance</category>
      <description>Many Drupal sites are fast when launched, but become heavier over the years. The cause is usually not Drupal itself, but how the platform is maintained, extended and filled with content over time. Slowness rarely comes from one change A Drupal site does not usually become slow overnight. It is usually a gradual process: more content is added; more images and files are uploaded; new modules are installed; small custom features are built; analytics, marketing and chat scripts are added; cache or server configuration falls behind; old solutions remain in place next to new ones. Each individual change may seem small. Together, they can make the site slower, harder to manage and more expensive to develop further. Content growth has a bigger impact than expected A large organisation&apos;s Drupal…</description>
    </item>
    <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 1 to Drupal CMS 2 upgrade</title>
      <link>https://webpro.company/blog/drupal-cms-1-to-2-upgrade</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-cms-1-to-2-upgrade</guid>
      <pubDate>Thu, 18 Jun 2026 06:00:00 GMT</pubDate>
      <category>Migration</category>
      <category>Drupal</category>
      <category>Maintenance</category>
      <description>Drupal CMS 2.0 brings a new starting point, Canvas and site templates, but an existing site created from Drupal CMS 1 does not automatically become the same thing. Before changing it, you need to understand what the site actually uses. Drupal CMS 2.0 raises an obvious question: if a site started from Drupal CMS 1, can it simply be upgraded to Drupal CMS 2? The short answer: carefully. Drupal CMS is not a product version in the same sense as a Drupal Core major version. The Drupal CMS project page describes it as a starting point for new sites. Once a site has been created, what you have is a Drupal site with selected modules, configuration and content. That means Drupal CMS 1 to 2 should not be treated as just a Composer command. It should be treated as a technical change to an…</description>
    </item>
    <item>
      <title>Hiring a Drupal agency outside your country — what actually matters</title>
      <link>https://webpro.company/blog/drupal-agency-outside-your-country</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-agency-outside-your-country</guid>
      <pubDate>Sat, 06 Jun 2026 06:00:00 GMT</pubDate>
      <category>Maintenance</category>
      <description>When you search for a Drupal partner, geography is often the first filter. It should probably be the last. Drupal projects fail because of unclear scope, untested deployments and partners who disappear when something breaks. None of these are caused by the agency being in a different country. Still, hiring outside your own market raises real questions. This post answers them directly. The concerns that are worth taking seriously Timezone If your agency is in a timezone more than two hours away from you, day-to-day collaboration gets harder. Stand-ups, quick calls, same-day feedback loops — all of these become friction. An agency in Estonia is in EET/EEST — the same timezone as Finland, one hour ahead of Sweden and Norway. For Nordic organisations, this means a full overlapping workday…</description>
    </item>
    <item>
      <title>Drupal hosting requirements — what to expect from a server</title>
      <link>https://webpro.company/blog/drupal-hosting-requirements</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-hosting-requirements</guid>
      <pubDate>Tue, 02 Jun 2026 06:00:00 GMT</pubDate>
      <category>Maintenance</category>
      <category>Drupal</category>
      <description>Wrong hosting does not take a Drupal site down — but it makes updates harder, performance worse and maintenance more expensive. Here is what to check. Drupal runs in many server environments, but not all environments work equally well. A simple site may run on minimal hosting, but as the platform grows — more modules, integrations, content — limitations from the wrong hosting start to show. PHP version Drupal 11 requires PHP 8.3 or newer. Drupal 10 supports PHP 8.1–8.3. Check which PHP version the hosting provider offers and whether it can be changed when needed. Some cheaper packages stay on older PHP versions — which means Drupal cannot be updated in the future without switching hosting providers. Minimum requirement: PHP 8.3 (for Drupal 11) Memory limits Drupal needs sufficient PHP…</description>
    </item>
    <item>
      <title>Maintenance contract or one-off fix for a Drupal site</title>
      <link>https://webpro.company/blog/maintenance-contract-or-one-off-fix</link>
      <guid isPermaLink="true">https://webpro.company/blog/maintenance-contract-or-one-off-fix</guid>
      <pubDate>Tue, 21 Apr 2026 06:00:00 GMT</pubDate>
      <category>Maintenance</category>
      <category>Drupal</category>
      <description>Not every website issue needs a maintenance contract. At the same time, some Drupal sites carry business-critical risk if support is only occasional. When one-off work is enough A one-off fix fits when the problem is clear, limited and does not depend on the wider technical state. Examples include a small form defect, content change or isolated styling fix. Regular maintenance makes sense when: the site supports sales or a public service; many contrib modules are used; Drupal or PHP needs regular updates; there are several editors and permission levels; changes need staging and a release plan. Maintenance means responsibility Drupal security updates do not always arrive at a convenient time. If responsibility is not agreed, updates are often postponed. WebPro Drupal maintenance fits…</description>
    </item>
    <item>
      <title>Why an old website can be a business risk</title>
      <link>https://webpro.company/blog/why-an-old-website-can-be-a-business-risk</link>
      <guid isPermaLink="true">https://webpro.company/blog/why-an-old-website-can-be-a-business-risk</guid>
      <pubDate>Tue, 07 Apr 2026 06:00:00 GMT</pubDate>
      <category>Maintenance</category>
      <category>Security</category>
      <description>An old website is not only a problem when it breaks. Often the real risk is that nobody can change it safely anymore. What risks accumulate Security risk is the most visible one, but not the only one. An ageing website can affect sales, recruitment, customer support and legal compliance. Typical risks include: software no longer receives security fixes; forms or checkout do not work in all browsers; content management depends on one person; WCAG requirements are not met; a new developer cannot understand the system quickly. How to choose the next step Not every old website needs immediate rebuilding. Sometimes maintenance and small fixes are enough. In other cases, it is cheaper to plan migration before the issue becomes an emergency. WebPro helps choose the path through audit and…</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>Drupal security updates — why they cannot be postponed</title>
      <link>https://webpro.company/blog/how-drupal-security-updates-work</link>
      <guid isPermaLink="true">https://webpro.company/blog/how-drupal-security-updates-work</guid>
      <pubDate>Sat, 28 Mar 2026 06:00:00 GMT</pubDate>
      <category>Maintenance</category>
      <category>Security</category>
      <category>Drupal</category>
      <description>Drupal has one of the more mature security processes among open-source CMS platforms. But applying a security update is not simple — it is technical work that requires planning. Many website owners assume that &quot;updating&quot; means pressing a button. In Drupal projects, that is not how it works — and for good reason. Understanding how security updates work helps explain why regular maintenance is technical work, not an automated process. The Drupal Security Team Drupal has a dedicated volunteer security team responsible for evaluating vulnerabilities and publishing security advisories. The process works as follows: Someone reports a vulnerability privately to the Security Team. The team assesses severity and coordinates a fix with the module maintainer. On a scheduled date, the fix and the…</description>
    </item>
    <item>
      <title>What happens when a Drupal site is not updated</title>
      <link>https://webpro.company/blog/what-happens-when-drupal-is-not-updated</link>
      <guid isPermaLink="true">https://webpro.company/blog/what-happens-when-drupal-is-not-updated</guid>
      <pubDate>Sat, 14 Mar 2026 06:00:00 GMT</pubDate>
      <category>Maintenance</category>
      <category>Security</category>
      <category>Drupal</category>
      <description>Nothing happens to an unmaintained Drupal site — until something does. Accumulating known vulnerabilities, ageing dependencies and rising remediation costs are real consequences, not theoretical risks. An unmaintained site often runs for years with no visible problems. This creates a false sense of security: if everything works, why update? In reality, every unpatched month adds risk that is invisible until it materialises. Security vulnerabilities accumulate Drupal publishes security patches regularly — roughly once a month. Each patch resolves specific known vulnerabilities. When a patch is not applied, the vulnerability stays open. What makes this especially critical is that security flaws are disclosed after the patch is released. This means attackers know exactly which versions…</description>
    </item>
    <item>
      <title>Drupal migration, upgrade or maintenance — how to choose</title>
      <link>https://webpro.company/blog/drupal-migration-upgrade-or-maintenance</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-migration-upgrade-or-maintenance</guid>
      <pubDate>Sat, 07 Mar 2026 06:00:00 GMT</pubDate>
      <category>Drupal</category>
      <category>Migration</category>
      <category>Maintenance</category>
      <description>Many Drupal site owners know something needs to be done — but not exactly what. Maintenance, upgrade and migration solve different problems and cost differently. Three main situations come up in the lifecycle of a Drupal site, each requiring a different kind of technical response. Choosing the wrong service does not fix the problem — it delays it. Maintenance Maintenance suits a site running on Drupal 9, 10 or 11 that is fundamentally healthy but needs ongoing technical attention. Maintenance covers: applying security updates to Drupal core and modules; keeping PHP, server and dependencies current; managing performance, backups and certificates; fixing small bugs and making content changes; monitoring and responding to issues. Maintenance is not a one-time job — it is an ongoing…</description>
    </item>
    <item>
      <title>PHP version and Drupal hosting</title>
      <link>https://webpro.company/blog/php-version-and-drupal-hosting</link>
      <guid isPermaLink="true">https://webpro.company/blog/php-version-and-drupal-hosting</guid>
      <pubDate>Fri, 06 Feb 2026 06:00:00 GMT</pubDate>
      <category>Maintenance</category>
      <category>Drupal</category>
      <category>Security</category>
      <description>A website may appear to work while the server already runs an outdated PHP version. That quiet risk should be visible before major upgrades. Drupal depends on PHP Drupal is written in PHP. This means Drupal security and reliability also depend on the PHP version running on the server. The official PHP site lists supported PHP versions. If the server uses a version that no longer receives security fixes, updating Drupal modules is not enough. The site may still work. The risk is that old PHP blocks future upgrades and may leave security issues without fixes. What to check in hosting At the start of Drupal maintenance, hosting should be checked together with Drupal itself. The important questions are simple: which PHP version is used; whether the server allows a newer PHP version;…</description>
    </item>
    <item>
      <title>How to choose a Drupal maintenance partner</title>
      <link>https://webpro.company/blog/how-to-choose-a-drupal-maintenance-partner</link>
      <guid isPermaLink="true">https://webpro.company/blog/how-to-choose-a-drupal-maintenance-partner</guid>
      <pubDate>Tue, 20 Jan 2026 06:00:00 GMT</pubDate>
      <category>Maintenance</category>
      <category>Drupal</category>
      <description>Drupal maintenance is not just having a developer available in an emergency. It is recurring work that keeps the platform secure, tested and maintainable. What to ask before signing A Drupal maintenance provider should understand both Drupal security updates and the client&apos;s business process. The question is not only whether someone can write code. Ask: how updates are tested in a staging environment; whether the project uses Git and Composer; how backups are made before larger changes; which tests run before release; who is responsible if an update breaks an existing workflow. Maintenance is a process A one-off fix can be enough for a small bug. A long-lived Drupal site needs regular review because modules, PHP versions, browsers and security expectations keep changing. WebPro Drupal…</description>
    </item>
    <item>
      <title>Drupal security in practice — what actually happens when you skip updates</title>
      <link>https://webpro.company/blog/drupal-security-in-practice</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-security-in-practice</guid>
      <pubDate>Thu, 06 Feb 2025 06:00:00 GMT</pubDate>
      <category>Security</category>
      <category>Drupal</category>
      <category>Maintenance</category>
      <description>Drupal security updates feel like tedious routine — until the day your site is compromised. Here is the real picture of what happens and how to protect yourself. What attackers do with Drupal sites A compromised Drupal site does not necessarily &quot;break&quot; — an attacker&apos;s goal is often not to destroy the site. The goals are: Malware distribution — hidden code is added to the site that loads malware onto visitors&apos; computers. The site works normally, the owner notices nothing — but Google notices and adds the site to its blacklist. SEO spam — hidden pages are added advertising pharmaceuticals, gambling or other illegal content. Google indexes these pages under the site&apos;s domain. Result: the site&apos;s SEO reputation is damaged. Botnet member — the compromised server is added to a botnet used to…</description>
    </item>
    <item>
      <title>Drupal security incident plan — what to do when your site is compromised</title>
      <link>https://webpro.company/blog/drupal-security-incident-plan</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-security-incident-plan</guid>
      <pubDate>Thu, 16 Jan 2025 06:00:00 GMT</pubDate>
      <category>Security</category>
      <category>Drupal</category>
      <category>Maintenance</category>
      <description>During a security incident there is no time to start planning. Here is a step-by-step guide that every Drupal site owner should prepare in advance. Why the plan must exist before the incident When a site is compromised, you are stressed, clients are calling and every minute counts. That is not the moment to start figuring out what to do. A security incident plan is a document that answers questions before they are asked. The plan does not have to be long. It has to be clear and accessible — ideally not stored on the server being attacked. Signs of a security incident Before responding, you need to recognise that an incident has occurred: Google flags the site as &quot;this site may be harmful&quot; Hosting sends a notification about suspicious activity Unknown pages or redirects appear on the…</description>
    </item>
    <item>
      <title>Drupal backup restore test — why &quot;backup exists&quot; is not enough</title>
      <link>https://webpro.company/blog/drupal-backup-restore-test</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-backup-restore-test</guid>
      <pubDate>Thu, 02 Jan 2025 06:00:00 GMT</pubDate>
      <category>Security</category>
      <category>Drupal</category>
      <category>Maintenance</category>
      <description>A backup that has never been restored is an untested hypothesis. Here is how to make sure your Drupal backup actually works. A backup is a promise, not a guarantee Nearly everyone has a backup. Hosting providers take nightly snapshots, some use scripts, others rely on modules like Backup and Migrate. But the question is not whether a backup is being made — the question is whether it works. A backup that has never been restored is an untested hypothesis. A restore test is simple: take a backup and restore it. See whether the result is a usable site. What a backup must contain A complete Drupal backup consists of two parts: Database — all Drupal content, configuration, users. Without the database there is no site. Files — the directory. This is where images, documents and uploaded files…</description>
    </item>
    <item>
      <title>What to do when the previous developer is gone — taking over a Drupal project</title>
      <link>https://webpro.company/blog/taking-over-drupal-from-previous-developer</link>
      <guid isPermaLink="true">https://webpro.company/blog/taking-over-drupal-from-previous-developer</guid>
      <pubDate>Wed, 19 Jun 2024 06:00:00 GMT</pubDate>
      <category>Maintenance</category>
      <category>Audit</category>
      <description>A developer handover is a common situation. Here is a practical guide for taking over a Drupal project without losing anything critical. Why this situation is difficult A Drupal project is more than code. It is: Configuration (modules, settings, roles) Database (content, users) Files (images, documents) Hosting (server, domain, SSL, email settings) External services (analytics, payments, CRM integrations) Knowledge (why things were built a certain way, what known issues exist) The previous developer held all of this in their head. Now you have to reconstruct it. First steps Collect all access credentials Gather everything before contact with the previous developer ends: Hosting — where the site lives, SSH/FTP, cPanel/Plesk Domain — registrar, DNS management Drupal admin — administrator…</description>
    </item>
  </channel>
</rss>
