By this point I knew what the problem was. Every new application meant another copy of the same infrastructure. Every improvement meant updating multiple projects. The duplication wasn't making development difficult—it was making maintenance expensive. My first instinct wasn't to build a framework. It was simply to stop copying code. The obvious place to start was with the parts that almost never differed between applications. The website header. The footer. The navigation. Instead of maintaining separate copies, I began sharing them between applications. Suddenly a change to the site's appearance only needed to be made once. That small change had a surprisingly large effect. The more code I shared, the more I realised that the same principle applied elsewhere. Configuration files didn't need to exist in every project. Common helper functions didn't need to be duplicated. Authentication didn't need to be rewritten. Database access could be standardised. Even the...

When I first started writing my own PHP applications, every project was self-contained. That seemed like a sensible approach. Each application lived in its own directory, had its own configuration files, its own navigation, its own page layout and its own collection of helper functions. There were no dependencies between projects, and that meant I could develop each one independently. For a while, that worked perfectly. The problem wasn't building new applications. The problem was changing existing ones. Imagine deciding that your website header needs redesigning. Perhaps you want to add a search box, change the navigation or update your branding. With a single application, that's a straightforward task. With ten independent applications, it becomes ten separate tasks. Every header had to be updated. Every footer had to be updated. Every navigation menu had to be updated. Every configuration change had to be copied into every project. Every bug fix had to be repeated. None of t...

For many years, my website was powered by WordPress. Like millions of other people, I appreciated how quickly it allowed me to publish content without having to build everything from scratch. However, over time my website evolved beyond a simple blog. I found myself wanting applications that WordPress wasn't really designed to provide. Some projects needed custom databases, others required specialised interfaces or unique workflows that didn't fit naturally into the WordPress ecosystem. While plug-ins could sometimes fill the gap, they often introduced complexity and compromises that felt increasingly uncomfortable. Eventually I decided that, for these applications at least, it would be simpler to build them myself. At first there was no grand architectural vision. Each application was a completely independent PHP project. Every one had its own directory structure, its own configuration, its own navigation and its own way of doing things. That wasn't a deliberate design dec...

Artificial intelligence has become one of those subjects that is difficult to discuss without encountering either exaggerated enthusiasm or outright hostility. Depending on which article you read, AI is either about to replace entire professions or is little more than an overhyped autocomplete system. After spending several months using AI to help build the Jersey News Aggregator, the wider Auspice Darer publishing platform, and various supporting tools, my own view is somewhat different. I have come to regard AI as something closer to a very advanced programming language. That may sound like an unusual comparison, but it helps explain both its strengths and its limitations. Programming Through Abstraction The history of computing is largely the history of abstraction. Early programmers worked directly with machine code. Later they used assembly language. Then came higher-level languages such as C, Pascal, PHP and Python. Frameworks and libraries followed, allowing developers to expres...

When I first built the Jersey News Aggregator and the wider Auspice Darer website project, I concentrated on functionality. The site could collect news, display articles, search archives and present information exactly as intended. What it could not do was explain itself very well to search engines. That changed when I began setting up Google Search Console and Google Analytics. One of the first recommendations was to submit an XML sitemap. At first glance, an XML sitemap appears to be little more than a list of pages. In reality, it serves as a roadmap for search engines, helping them discover content that might otherwise take longer to find. What Is an XML Sitemap? An XML sitemap is a machine-readable file that lists the pages available on a website. A typical sitemap entry looks something like this: <url> <loc>https://www.example.com/about.php</loc> <lastmod>2026-05-01</lastmod> </url> The sitemap tells search engines: Which pages exist Wh...

After creating an XML sitemap for the Jersey News Aggregator and wider Auspice Darer website project, the next step was understanding another file that search engines pay close attention to: robots.txt. While a sitemap helps search engines discover content, robots.txt helps control what they should and should not crawl. Both files work together, and both play an important role in how a website is indexed. What Is robots.txt? A robots.txt file is a simple text file placed in the root directory of a website. For example: https://www.example.com/robots.txt When a search engine visits a website, one of the first files it requests is robots.txt. The file contains instructions that tell search engine crawlers which parts of the site are available for crawling and which areas should be ignored. A basic robots.txt file might look like this: User-agent: * Allow: / Disallow: /admin/ Sitemap: https://www.example.com/sitemap.xml In plain English this means: All search engines are allowed to cra...