Category: web development

Posted on

Two days in Kraków – a trip to WordCamp Europe 2026

I have been working with WordPress since around 2010 and since that time I have almost exclusively used it as the underlying basis for various web projects I’ve developed for myself and clients. From design festival websites, to a skatepark directory, to an online learning toolkit, I’ve used it for various projects both large and small.

Despite working with WordPress for over fifteen years, I had never attended one of the larger WordPress conferences. When I realised WordCamp Europe 2026 was taking place in Kraków, it seemed like the perfect opportunity to experience my first WordCamp.

It was a bit of a whirlwind trip, flying in late Thursday, the conference on Friday & Saturday and then flying out early Sunday morning. So not anywhere near enough time to see that much of Kraków outside of the conference but, along with my friend Graeme, we did manage a little sight-seeing in the evenings, exploring the general old town area (much of it via Bolt scooters!).

There was a lot to take in over the trip, so here are a few things that stood out at WordCamp Europe 2026.

View from a bridge over a calm river or canal, with several moored houseboats reflected in the water. Across the water is a large grassy park bordered by modern office and conference buildings, including a distinctive curved glass-and-metal structure in the centre. A ferris wheel stands in the distance on the left, while a wide pedestrian walkway and road run alongside the bridge on the right under an overcast sky.
A view of the ICE Kraków Congress Centre, the venue for WordCamp Europe 2026.

Accessible and affordable

Many creative industry / web design / development conferences are quite expensive to attend, as someone who has been self-employed for the majority of my working life I have not attended many of these kind of events as I could not justify the high ticket costs.

So part of what I mean by “accessible” is that the cost to attend is accessible. The basic entry cost of €50 for the two-day event including lunches and snacks meant this was extremely affordable. Additional tiers were available for those who are able to contribute more and pay it forward to help the event stay affordable, but everyone had the same experience regardless of ticket type. This was made possible by the support of some extremely generous sponsors, this helped ensure the cost of entry was as small a barrier as possible (thanks go to all the sponsors who supported WordCamp Europe 2026).

Another aspect of accessibility that was notable was language, translation and captioning. English was the primary language spoken by everyone who was giving a talk, but this was aided by live translated English subtitles shown on screen behind the speakers. Additionally the Wordly AI service was used to provide real-time translation in both audible and text formats. As an English language native I can’t attest exactly as to how effective this was as a tool, but I did try out the live text translation with Ukrainian1 and it seemed to be translating pretty well.

Talks and Panels

Talks and Panels with various speakers were a key component of the conference, there were two different tracks to pick from with a variety of subjects. Ranging from more technical talks about things like the new “Abilities API” or “Block bindings” to broader topics like the “Future of SEO”.

One of the talks that particularly stood out was “Two Worlds Collide: WordPress at CERN”, Joachim Valdemar Yde and Francisco Borges Aurindo Barros gave an overview of a huge project undertaken at CERN to consolidate 800+ websites on various disparate platforms onto WordPress:

Additionally, there were also two Workshop tracks with longer hands-on time exploring things like the “HTML API” and the “Interactivity API”. The workshops looked interesting but I was more interested in checking out the various talks rather than doing extended workshops, I think the workshops were fully booked as there was a lot of interest in them.

All the talks / panels and workshops were streamed / recorded so you can actually go and watch all of them, I will definitely be checking out all of the talks that I missed. Click through to the talks / workshop pages from the main conference schedule page to see the videos.

Conversations

The talks were really interesting, but a big part of WordCamp is the conversations that take place outside of them. Whether it was sitting during a break, queuing to get some coffee or visiting the many exhibitor / sponsor booths in the venue, the conversations with other attendees were really interesting.

There was an incredible variety of backgrounds to the people attending the conference, it’s not just web design / developers attending but a huge array of people that use WordPress for their businesses, charities, personal projects etc. The power and success of WordPress is down to the community of people who care about WordPress, helping people to install, use, develop, translate, support WordPress and the people who use it.

I think there were almost 2500 people attending from about 81 different countries, so it was a really broad and varied group of people in attendance. One thing I missed out on this time but would be keen to attend in future is the Contributor day, this took place the day before the conference and was an opportunity for people to meet together, find out more about opportunities to contribute to WordPress and use their skills to make it even better.

The after-party on the Saturday night at Forty Kleparz – aka Kraków Fortress2 – continued the incredibly high standard of the rest of the event, and a chance for the attendees, speakers and at least some of the organisers to relax after a job well done. A time for more conversation, great food, music, karaoke etc. I didn’t stay too long at this as it was an early start to catch a flight back to Scotland the next morning, but everyone seemed to be enjoying themselves.

I don’t drink much beer but I did enjoy this white beer, not sure what it was. My Friend Graeme also enjoyed it.

WordPress and AI

Not unexpectedly, AI was a very common topic of both the talks and panels and conversations. The majority of exhibitors at the conference seemed to be advertising some form of AI or agentic integration, and whilst not every talk or panel had AI in the title, most of them mentioned AI one way or another. Co-incidentally WordPress 7.0 has recently launched which adds some key features enabling AI connections to allow deeper access to AI tools like Codex, Claude, Gemini etc.

There definitely was a lot of discussion about where WordPress stands in this highly dynamic and, yes, disruptive3 era that we are in. Overall it was positive with people excited about the opportunities that AI has for WordPress and how WordPress 7.0’s new AI connectors set a good foundation. I did have at least one conversation where someone expressed concern about how AI is affecting WordPress usage and whether this is contributing to a decline in its growth.

Overall there was a lot of energy being directed in how best to integrate AI into WordPress and related workflows. Definitely some food for thought in regard to my own usage of WordPress and AI. As someone who has increasingly used tools like ChatGPT and Codex in my own work, it was interesting to see how quickly AI has become part of the wider WordPress conversation.

A high bar

So some final thoughts, I heard some amazing talks from great speakers, had some excellent conversations with people, learned about some interesting services, companies, new features and initiatives relating to WordPress.

It really was an incredibly well run event, as a first time attendee I was blown away by the standard of the event and how well it was organised and the level of care and attention given. An incredible venue, in an incredible city, organised by an incredible team. Well done to all the organisers, volunteers and sponsors who made it happen!

After more than fifteen years of using WordPress, attending my first WordCamp Europe was long overdue. I’m glad I finally made the trip and I’ll definitely be looking at attending future WordCamps when I can. Next year’s WordCamp Europe city has been announced, so if this event sounds like something you’d be interested in I’d strongly recommend booking a ticket for WordCamp Europe 2027 in Malaga, Spain as soon as they are available.

Quick video of my trip

It’s always fun to document trips, and Kraków was a beautiful city so there was a lot to try and capture. Here’s a wee video with some of what I saw over the two days or so:

WordCamp Europe 2026 took place on June 4-6th, here’s a little video of my trip there!
  1. I have been slowly learning Ukrainian for a couple of years, I’m definitely far from fluent! My wife on the other hand (she is definitely a language geek!) is pretty fluent and is now learning Romanian. ↩︎
  2. Forty Kleparz is in the “Kraków Fortress”, a 19th century Austro-Hungarian fortification. Wawel Castle was also an amazing looking, centuries old building, but one I saw only from the outside, I definitely need a return trip to check this out more. ↩︎
  3. “Disruptive” is a word thrown out about various kinds of technology, but I think it is definitely appropriate to use it to describe the impact of AI in our lives. ↩︎
Posted on

AI Bots: Disallow

I wrote a post recently “Should WordPress block AI bots by default?” with some thoughts about whether WordPress should be blocking AI bots via the robots.txt file by default.

Since writing that I decided that rather than just talking about it I should go ahead and submit some updated code to the WordPress project that does exactly that. I’ve done WordPress development for 14+ years, whilst I’ve created my own plugins and added them to the WordPress plugin repository I’ve never submitted anything to the core codebase before, so it was an interesting process to go through to get a bit of experience of that.

I’m not going through the various steps in detail to do this, but basically it involves forking the WordPress codebase on Github, making the changes in a local development environment, pushing some code to Github and making a Pull Request for those changes.

Whilst the code change is pushed to Github you also need to make a ticket in WordPress Trac ticketing system that is used to track code issues like bugs, updates and feature requests. I created a new Trac ticket for the PR but as it turns out a similar idea had been previously suggested in this Trac ticket so mine has been marked as duplicate to this original one.

This original ticket has some good ideas in it, although no code has been written so I’m glad to have submitted a PR along with it. I do also think my argument for this are a bit more forceful in my ticket compared to the original, I really do think this should be added. However, I am approaching this from the perspective of trying to create some discussion around this, so I don’t at all expect that the code in my PR is exactly the way this feature should work. In the original Trac ticket the suggestion is to have another checkbox in the “Reading” options in WordPress, “Discourage Al services from indexing this site” which I think makes perfect sense.

I did wonder whether there should be any specific way to manage the list of AI Bots though, whilst the “discourage search engines…” option is similar there is a difference. In the ‘robots.txt’ file it only takes a couple of lines to block all search engine user agents:

User-agent: *
Disallow: /

So if you wanted to block all search engines and AI bots you could use just those couple of lines, but presuming you still want search engines to index your site1 you need to specifically list all of the AI bot user agents to be blocked, something like this should block most known AI bots (at the time of writing in October 2024 anyway):

User-agent: AI2Bot
User-agent: Ai2Bot-Dolma
User-agent: Amazonbot
User-agent: anthropic-ai
User-agent: AlphaAI
User-agent: Applebot
User-agent: Applebot-Extended
User-agent: Bytespider
User-agent: CCBot
User-agent: ChatGPT-User
User-agent: Claude-Web
User-agent: ClaudeBot
User-agent: cohere-ai
User-agent: Diffbot
User-agent: FacebookBot
User-agent: facebookexternalhit
User-agent: FriendlyCrawler
User-agent: GPTBot
User-agent: Google-Extended
User-agent: GoogleOther
User-agent: GoogleOther-Image
User-agent: GoogleOther-Video
User-agent: iaskspider/2.0
User-agent: ICC-Crawler
User-agent: ISSCyberRiskCrawler
User-agent: ImagesiftBot
User-agent: img2dataset
User-agent: Kangaroo Bot
User-agent: Meta-ExternalAgent
User-agent: Meta-ExternalFetcher
User-agent: OAI-SearchBot
User-agent: omgili
User-agent: omgilibot
User-agent: PerplexityBot
User-agent: PetalBot
User-agent: Scrapy
User-agent: Sidetrade indexer bot
User-agent: Timpibot
User-agent: VelenPublicWebCrawler
User-agent: Webzio-Extended
User-agent: YouBot
Disallow: /2

It’s possible users might want to allow certain ones, and disallow others so the original Trac ticket also suggests that this list could be filterable so that plugins etc could modify this list.

I don’t think adding any kind of UI beyond the checkbox to core would be desirable as it’s exactly the kind of extension of functionality that plugins are intended for. The basic feature of blocking AI bots will work and if users need more they can find a plugin or write their own code to do what they need. One consideration is whether this list of default AI bots should get updated outwith the regular core WordPress development cycle, but the amount of new AI bots appearing probably(?) isn’t that frequent and there are fairly common interim point updates in the WordPress development cycle that would allow this block list to be updated.

If you’re reading this and think it’s an enhancement worth supporting then please do leave a comment on the original Trac ticket if you can, or reshare this post anywhere you think might help draw attention to it.

  1. I acknowledge there is a lot of discussion about whether blocking AI bots will one day have the same impact that blocking search engines from your site does now in that you basically won’t show in any search engine results. The intention of blocking AI bots by default is so that users can make an informed choice about how their content is used. ↩︎
  2. These are the droids we are looking for? ↩︎
Posted on

Disable Login Language Selector on WordPress 5.9

With the release of WordPress 5.9 comes a new dropdown language selector on the Login screen for WordPress that lets users switch to any language that has been installed on the website. As long as there is more than one active language on the site then this dropdown selector will be visible and is a great feature for multi-lingual sites.

If, like me however, you develop a website which already has a language switcher in place, either via your own code or another plugin then you may not want the new language selector to appear. Thankfully WordPress 5.9 also comes with a filter that you can use to disable the selector, so you can use this simple line of code in the ‘functions.php’ file in your theme to do so:

add_filter( 'login_display_language_dropdown', '__return_false' );

Whilst it is fairly simple to add this to your theme for some people it may not be possible to edit your theme files and such it’s much easier to install a plugin, so I’ve made a simple plugin which is now live in the WordPress plugin directory. The “Disable Login Language Selector” plugin provides a quick and easy way to remove the Language selector that appears on the login screen in WordPress 5.9.

Disable Login Language Selector

(Note that my other WordPress plugins have also been tested in WordPress 5.9 too so will happily work with the new release.)

Posted on

A Spacious place

I had a request the other day to find login details for the administrator of an old client website that we built for Dundee University in the earlier years of wideopenspace, the web design company I used to run. I hadn’t realised that the old client site was still up and running all this time after having been launched in 2006!

It was an amazing nostalgic blast-from-the-past to log in to the site’s control panel and see our custom-built content management system again! I’d kind of forgotten about the 100’s (actually, more like 1000’s!) of hours worth of time and effort that my business partner Andy and I put in to developing it and implementing it on client projects.

The CMS was called ‘Spacious’* and actually came in two versions, the full version with a multi-level navigation system and various custom modules and a ‘Spacious Lite’ version which was made for really small sites with single level navigation and also had access to certain modules.

Last logged in on 14/07/11, it had definitely been a while!

When we started development of our CMS around 2004 we hadn’t really used any third-party CMS platforms (WordPress V1 actually came out in 2004 but it wasn’t really on our radar). Instead we wanted to make something that suited our own specific purposes and client needs. So we didn’t really look at how any other CMS’s were doing things but in a kind of intentionally-naive way built it to work how we wanted it to work for the sites we were building for clients.

We used Spacious for a quite a lot of sites and we actually tried to secure funding to enable us to develop it into a fully fledged CMS product to sell to other companies, but sadly we never succeeded in getting funded. Eventually we stopped developing Spacious and as a company we increasingly moved our focus to WordPress as a platform around about 2009 (probably WordPress 2.7 I think?).

Client budgets were getting tighter and awareness of open source systems like WordPress was increasing. As such it was getting harder to sell clients a licence for a commercial CMS so financially the time spent building and maintaining our own one made less and less sense.

From a development perspective I found that WordPress had a lot of technical similarities to how we’d chosen to structure our CMS. Spacious had similar concepts of posts and pages, a plugin system offering various functions like Events, Email contact forms, Staff directories (‘modules’ in Spacious’ terminology), comments and even a form of multisite that could run more than one site from a single installation. (Spacious had some really cool features built into it that I’m pretty proud of in retrospect!)

From a client-facing perspective I liked the simplicity of WordPress, it was cognitively easy to use – especially compared to the complexities of something like Joomla at the time (I remember seeing all the steps that an incoming new client had to go through to edit their existing site in Joomla and it was extremely complex and confusing!).

As WordPress became our main focus the list of live client sites running Spacious grew shorter. So it’s very cool to see not just one but actually two sites that are still live and running on Spacious after all this time!

* Originally we wanted to call it ‘Fabric’ and trademark it but we weren’t successful – that’s a whole other story!

Posted on

A work-around for aspect-ratio percentage padding issues on flex items in older versions of Firefox and Edge

Whilst working on a recent project I needed to enforce a fixed ratio on some elements in the layout. In this case I used the ‘Aspect Ratio’ method which uses a ‘0’ height element with a percentage-based ‘padding-top’ value (More info about that in this CSS Tricks article).

The problem I ran into was that I was also using Flexbox for layout so each element was a Flex item, all of this was fine in Chrome and Safari and also in recent versions of Firefox and Microsoft Edge 17, 18 and in the upcoming 19.

But when testing in Edge 15 and 16 I found that the elements with the aspect ratio method applied to them were just completely invisible. Looking into it further I came across a Stackoverflow post and discovered that the issue was that in these versions of Edge they were supporting an earlier version of the Flexbox specification which meant that the percentage-based padding-top had no effect, basically rendering these elements with a ‘0’ height so they didn’t show up. It seems that the Flexbox specification was updated circa 2018 and basically brought it in line with the way Chrome and Safari have always behaved.

An alternative way of specifying the padding-top value is to use the ‘vw’ viewport-width units instead of percentages, whilst I found this did work to some extent it was harder to keep the ratios exactly how I wanted, but at least it was a way that would get these elements working in older version of Edge. Rather than having to completely redo my markup and CSS just to support these older browsers I wanted to see if there was a way to target only these earlier versions of Edge and use ‘vw’ units for Edge 15 & 16 but keep percentages for all other browsers.

As it happens I was also using “Variable Fonts” on this site which are only supported in Edge 17+, as such as I was already testing for Variable Font support by using ‘@supports (font-variation-settings: normal)’, so combining this with another parameter ‘(-ms-ime-align: auto)’ which allowed me to target Edge I came up with a workaround.

Here’s an example of how it would be used, in this case it is a 3-up layout so each element is 1/3rd of the page width so set at 33.33333% of the width and then a padding-top set to the same percentage. The first CSS block sets the main styles and the second block adds the ‘@supports’ check which overrides the first for matching Edge versions:

.aspect-block {
    padding: 0;
    position: relative;
    flex: 0 0 33.33333%;
    height: 0;
    overflow: hidden;
   padding-top: 33.33333%;
}

@supports (-ms-ime-align: auto) and (not (font-variation-settings: normal) ) {
    .aspect-block  {
        padding-top: 33.33333vw;
    }
}
Posted on

Mental note: Set ‘register_meta’s ‘single’ parameter appropriately or you end up with data across multiple custom fields

This is a mental note for my own future reference after spending several hours trying to debug why some data was getting magically broken apart into multiple meta data fields.

In this case I was submitting a string of JSON data (created using JSON.stringify) via $.ajax in jQuery to create a ‘user_meta’ field via the WP Rest API. I could see from the response after successfully posting that the data was breaking up into multiple parts and was showing up as an array in the Ajax response, sure enough looking at the data in the WordPress ‘user_meta’ table I could see that there were a whole load of entries created from pieces of the single string I had sent.

After searching online for solutions and trying quite a few things I managed to narrow it down to which bit of code might be the cause, I was struggling to figure out whether it was happening during the AJAX request or on the server within WordPress.

However, I was aware that when rendering meta data using ‘get_user_meta‘ or ‘get_post_meta‘ that it will bring up an array as the default format as it is possible to have multiple meta fields with the same name, so when requesting a meta field you can set the ‘$single’ parameter to ‘true’ and this will return only a single value.

However, I hadn’t realised that you can actually specify that the fields are only to ever have a single instance when you register them using ‘register_meta‘, after setting this parameter my submitted JSON string happily went into a single user_meta field!

You can set the meta field to use a single parameter when registering like so:

register_meta( 'user', 'my_meta_fieldname', array( 'type' => 'string', 'single' => true ) );

Hopefully this will stay in my head now and I’ll remember if this happens again!


Posted on

WatchOS 5 adds support for web content rendering

Apple recently announced updates to the core software on all of their hardware platforms with various interesting new features.

One feature that jumped out when looking through it all was support for displaying web content in watchOS 5, it’s important to clarify that they haven’t added a standalone Safari app to watchOS but instead it enables any links sent via Mail or Messages to be accessed and then displayed right on the watch.

To get a quick overview it is worth taking a few minutes to watch the “Designing Web Content for watchOS” video on the WWDC2018 videos site as it gives a good overview.

Here’s a few thoughts and info about key aspects that I picked up from watching the video:

User navigation / interaction

  • You can scroll using the Apple Watch’s digital crown or via pan gestures
  • Double-tap to zoom in / out on the page content
  • Back/Forward navigation is controlled either via an overlay UI brought up via a  firm press on the screen or by swiping back and forward from the edges of the screen.

Web browser feature support

Content is optimised for display on the Apple Watch so certain features are not supported in watchOS 5:

  • Video playback
  • Service workers
  • Web fonts

If the web content being accessed is responsive then it treats the content as being 320px wide, the same width as if on an iPhone SE (iPhone 5 or older width). So text may be smaller but at least it will basically render the smallest breakpoint content, so it doesn’t require any new even smaller breakpoint to be catered for.

This is done by overriding the “initial-scale” value and provides a viewport with the dimensions 320px by 357px and reports a media query size of 320px. So existing responsive content will render on the Apple Watch without requiring any changes – at least from a layout perspective, worth noting the lack of support for Web fonts as this will likely have some rendering impact as it falls back to alternative fonts in the font stack do display.

Optimising content for Apple Watch

Even though responsive content will be rendered quite well by default it is possible to optimise content for display on Apple Watch.

The above image shows the standard responsive content being displayed on the Apple Watch, basically just the same as it would be on an iPhone SE (minus any web fonts of course!).

Responsive Layout on Apple Watch

Using a media query it is possible to modify this layout to display as a single column. There is an example given in the video which obviously won’t apply for all uses, but basically it uses “min-width: 320px” as the baseline for showing the content as two columns, so any content below that would render as a single column. Again, how this works specifically for your layouts will vary, but there will be some methods to use for frameworks like Foundation or Bootstrap etc.

“Disabled-adaptations” meta tag

The important addition to using a media query though is a new meta tag which disables the default adaptations that the Apple Watch makes when rendering content by default:

<meta name=”disabled-adaptations” content=”watch”>

With this meta tag in place the device width will be treated as the real width of Apple Watch’s screen. This again has similarities to how content was handled when the iPhone originally came out, existing content is displayed as best as possible but there are ways to optimise for the device if you want to.

Form controls on watchOS

Making use of HTML5 form control types is really important on watchOS, setting the type attribute to “email”, “tel” etc will bring up a specific, full screen UI to allow interaction.

Additionally making use of labels, placeholder or aria-label attributes enhance the context given when interacting with these controls. Hopefully you’re using these already but here’s another reason to do so.

Safari Reader on watchOS

This is a feature found on iOS and macOS which basically formats pages to show a more readable version of web page content. It’s a little unclear from the video but it sounds like pages that are “text heavy” will get displayed using Reader, although I’m not 100% sure how that would be determined exactly if so. Perhaps this is a way to handle big pages that might have a lot of adverts on it? Reader view is an option that users can choose by firmly pressing on any page to bring up the navigation overlay, so even if content is displayed normally a more readable version can be accessed.

Semantic markup in Reader view on watchOS

Reader view makes good use of semantic markup, using the “article” tag helps the display of content, and attributes like “item-prop” and other semantic tags like “strong”, “em”, “blockquote” etc enhances the display of content in Reader on watchOS.

Open Graph meta tags

Using Open Graph meta tags is something that makes sharing content around the web such as into Facebook, Twitter etc look better by providing specific preview content such as images, titles etc. watchOS makes use of these Open Graph meta tags to make the previews for any shared links look as good as possible.

That’s a quick overview of some aspects of watchOS 5’s support for web content, there’s definitely a few things to consider in there but if you’re building pages using responsive layouts and using semantic HTML then things should work fairly well without having to do anything.

The biggest issue I see initially is the lack of support for web fonts, that seems like it could cause some display issues due to the fallback to alternative fonts in the stack or if web fonts have been used for icons etc.

I’m also interested to know what the impact on battery life on the watch is like when loading and rendering multi-megabyte web pages which are not uncommon these days, I think Reader view is going to be an essential feature for viewing web content on Apple Watch.