How do you develop a website while backpacking round the world without carrying a computer?

How was OneWorld365 Created?

In 2007 graduating with degree in media from Liverpool University and having worked twice in USA at Summer Camp younger brother Paul approached elder brother Steven, a software engineer with idea to publish a website listing summer camp placements.

This expanded to include a range of Gap Year activities including volunteering, language schools, seasonal & work abroad.

At that time a few websites had regional listings but there was nothing searchable.

In library publisher Susan Griffith offered a good guidebook with listings and Lonely Planet also offered advice.

Our idea was to offer free listings to non-profits, NGO’s & grass roots organisations and options for priority listings to bigger travel providers. You could go direct to project provider or book all inclusive through a reseller.

Realizing that taking booking & organising placements required a large team, we decided instead to advertise the idea of meaningful travel possibilities.

Soon we found in addition to students many seniors & corporate workers on sabbatical were also interested in a meaningful travel experience with local people’s.

The website was developed during a round the world backpacking adventure using internet cafe computers and VI (putty).

Whilst most were checking their Hotmail and some were Skyping home on video call we were typing furiously into a Unix terminal emulation shell prompt.

Having little money for resources and with a rapidly growing audience on technical side we started with a virtual hosting running BSD Unix from Texas data centre and used open source technologies..

Currently the site is hosted in Frankfurt with IONOS running CentOS Linux, PostgresSQL, PHP, NGINX and Apache SOLR Lucerne.

Site maintenance is mostly now carried out using SSH from Android Mobile phone, it tends to crash only when we are borrowing (hacking into) other people’s free broadband off the beaten track away on holiday!

Do we need an App? Wasn’t promise of Netscape Navigator that you no longer need to install software applications (does anyone today remember the floppy disk?) and this new “web browser” runs on all platforms?

Given, most of us speak UNIX and have read, studied and remembered the man pages and VI keyboard shortcuts, do we need to install anything or can we do it all from shell command prompt?

(whilst backpacking, hostelling & coding, putty in 2008 neither crashed nor modified any internet cafe Windows computer, not in India, Indonesia, Thailand, Malaysia, Australia, Chile, Bolivia or Brazil)

At present serving ~1 million annual readers (post pandemic the worldwide appetite for travel has increased significantly) with 15k project listings in nearly every country of world, 2.5k community contributed articles and 10gb of photos!

Where next? Multi-lingual offering allowing native speakers to read & publish in their regions language. Post-pandemic lockdown & travel ban listings, should be reviewed with heads up on who is active at present, what shape are they in & can we offer any help? From content point of view we’d like to in better position to monetize our worldwide wandering team of content creators. On technical side we need additional contributor(s) to maintain, update & ultimately takeover.

#opensourcesoftware

#meaningfultravel

#volunteering

#worktheworld

#gapyear

#php #postgres #apache #nginx #linux #putty

#psid_my,—nvoice; bill?!

Working presently to migrate a large (2000+ pages, 10gb images) travel blog from a bespoke PHP CMS to WordPress.

Over last 15 years task of developing, updating and maintaining the handwritten CMS has become burdensome and time consuming.

There is a dependency on me as developer being only person who knows architecture / codebase.

Migrating to WordPress makes sense for a number of reasons – developers, administrators and content creators worldwide are familiar with the platform.

There is a healthy marketplace for commercial and freely available plugins, themes and tooling along with a choice of hosting providers.

A few developer notes on implementation / architecture –

Posts / Pages

Aren’t these the same thing – content? Isn’t WordPress now a generalised content management platform rather than being specific to blogs?

Posts are displayed chronologically having URLs in form /<year>/<month>/<day>/<post-name> but otherwise posts and pages have the same a data model, right?

Shouldn’t tables post and page be merged into a new table “wp_content” – with content-type field to distinguish different page types?

Content Tree / URL Index

WordPress organises content hierarchically using parent – child database relation with each tier representing URL segments /<tier-1>/<tier-2>/…

This makes searching for content by URL relatively inefficient. Large sites might also encounter wp_posts.page_name namespace collisions

Rendering a content tree requires a recursive SQL or application code algorithm to “walk the tree”.

Why not decouple wp_posts.page_name and store as fully qualified URL in an index table?

                      Table "public.url_index"
   Column    |          Type          |  
-------------+------------------------+-----------+-----
 content_id  | integer                | 
 url         | character varying(256) | 

-- SQL to retrieve all pages under /blog/2023
select
 c.id,
 c.title,
 c.content,
 i.url
 from wp_content c, wp_url_index i
where c.id = i.content_id
and i.url like '/blog/2023%'
order by i.url asc, c.id asc

Parent / child relation is no longer required – by publishing a page under a specific URL parent hierarchy is implicit and can be determined simply be traversing URL segments.

Having a URL index table makes retrieving one or groups of pages very low cost and efficient as a b-tree index can be added to url_index.url

Database Optimisation

To my mind WordPress core requires only three tables and fields could be simplified significantly:

wp_content: <id>,<title>,<content>,<author-id>,<created-date>,<last-updated>, <content-type>, <version-id>
wp_metadata: <content-id>,<metadata-key>, <metadata-value>, <metadata-type>
wp_url_index: <content-id>,<url>

Metadata is a generalised key/value store linked to content by id.

Any structured metadata relating to a page can be maintained – Plain text (integers, floats (albeit as text), varchar) JSON, serialised PHP objects even JPEG encoded images.

Ok, lets consider a query for posts having extended metadata representing price from – to field:

select 
 mk.content_id,
 mvf.metadata_value,
 mvc.metadata_value,
from 
wp_metadata_key mk,
wp_metadata_value_float mvf,
wp_metadata_value_varchar mvc,
where mk.metadata-type = "price"
and mk.id = mvf.metadata-key-id 
and mk.id = mvc.metadata-key-id 
and mvf.metadata-value BETWEEN "30" AND "50"

Metadata in this scenario has container for varchar() but also one for float field enabling numerical queries.

Version ID

By maintaining version id field alongside content or metadata application can automatically determine appropriate implementation to retrieve, render or update.

Version ID beyond describing WordPress version number could also specify this metadata is stored as format serialised JSON or this is a serialised PHP 5 object – over time as application evolves different implementations can be supported even concurrently.

Conclusion

We appreciate making changes to any codebase having grown organically through time is not trivial – especially when a large market of 3rd party plugins / tools are based on current implementation and would potentially need to mirror changes in their own new versions.

Planning a smooth migration path is not an easy undertaking. But on the other side, optimisations at architecture level bring significant benefit increasing application performance, lowering computational resource costs, make application code easier to work with and allow the platform to scale efficiently.