How WordPress actually works, from the request to the image on the page
WordPress works by building every page at the moment somebody asks for it, instead of serving a file written in advance: your words, your images and your layout are stored separately and assembled on request. A visitor requests a URL, the server runs PHP, PHP looks in the database for the post or page that matches that URL, the active theme decides which template shapes it, plugins get their turn to change the result on the way past, and the browser receives finished HTML. Nothing on the server is a file called about-us.html. That single fact explains most of what confuses people who arrive from hand written sites, and it is why backups, migrations and search all behave the way they do.
How WordPress works, step by step
Step by step, one request runs through 7 stages, and every stage is a place where something can be changed or can go wrong:
- Receive the request. The web server takes the URL and hands it to PHP through the front controller,
index.php. - Load the core. WordPress reads
wp-config.phpfor the database name, user and password, then connects. - Load the plugins. Every activated plugin in
wp-content/plugins/runs, and registers the hooks it wants. - Load the theme. The active theme in
wp-content/themes/runs itsfunctions.phpand registers its own hooks. - Parse the URL. WordPress turns the address into a query, such as "the post whose slug is remove-background".
- Query the database. The matching row comes back from
wp_posts, with its extra fields fromwp_postmeta. - Render the template. The theme picks a template file by a fixed order of preference, fills it with the content, and prints HTML.
Caching plugins short circuit this. They save the finished HTML from stage 7 and serve that copy to the next visitor, which is why a change you just made sometimes does not appear until you clear the cache. If you edit a page and the front of the site disagrees with the editor, empty the cache before you debug anything else.
What the theme controls, and what CSS controls
The theme controls structure and CSS controls appearance, and separating them tells you which file to open. The theme decides that a post shows a title, then an image, then the text, then the author area. CSS decides that the title is 42 pixels, dark grey and set in a particular typeface.
CSS is a language of rules, and each rule has 2 halves: a selector naming what to style, and a block of properties and values saying how. h2 { font-size: 28px; } is a complete rule. The browser reads every rule that applies to an element, and where 2 rules conflict the more specific selector wins. That conflict is the whole reason a colour change sometimes appears to do nothing: your rule is being beaten by a more specific one already in the theme.
In a classic theme the rules sit in style.css. In a block theme most of the same decisions are declared in theme.json instead, in one place, as colours, spacing steps and font sizes. Small additions belong in the Additional CSS field in the customiser or in the styles panel, never in the parent theme's own files, because the next theme update overwrites them. For anything larger, create a child theme, which is a folder with its own style.css that names the parent in a Template: header.
What a plugin actually does to the page
A plugin changes the page by attaching functions to named moments in that 7 stage run, using 2 mechanisms. add_action says "when WordPress reaches this moment, also run my function", which is how a plugin adds a share button under the content. add_filter says "before WordPress uses this value, let my function rewrite it", which is how a plugin changes the title or strips something out of the text.
This is also the honest explanation of why plugin count affects speed. Every activated plugin loads on every request, whether or not the current page uses it, so a gallery plugin runs on a contact page too. The cost is not the disk space, it is the PHP executing and the extra database queries each one adds. When a site slows down, deactivate plugins 1 at a time and measure between each, rather than guessing.
The 2 places your content can live
Your content can live in 2 places, and which one it lands in depends on how you write it. Written in the block editor, a page is stored as ordinary HTML in the post_content column of wp_posts, with small HTML comments marking where each block starts and ends. Strip the theme away and the words and structure are still there, still readable, still portable.
Written in a page builder, the layout is stored in that builder's own format. Some builders keep their layout data as post metadata in wp_postmeta, some fill the content column with their own shortcodes. Either way the page is only reassemblable by the plugin that made it, which is what people mean by lock in. Deactivate the builder and the page does not revert to plain text: it shows raw shortcodes or nothing.
Media is the third location and it is not a database row at all. The file itself is written into wp-content/uploads/ under a year folder and a month folder, and the database holds only an attachment row pointing at that path. A complete copy of a WordPress site is therefore always 2 things: a database dump and the wp-content folder. Take 1 without the other and the restore fails in a way that looks like a broken theme.
Is WordPress easy to learn
Yes for publishing, and no for the parts that are really server administration. Writing and publishing is 4 controls in the editor and you can be productive on the first afternoon. What takes longer is everything that is not writing, and it splits into 4 skills that are learned in order:
- Publishing: creating posts and pages, adding blocks, uploading media, setting a featured image.
- Structuring: categories, menus, permalinks, the front page setting, and which template a page uses.
- Maintaining: updates, backups, user roles, and knowing how to deactivate a plugin over SFTP when the admin area will not load.
- Extending: child themes, hooks, and enough PHP to read someone else's snippet before pasting it.
Skip level 3 and the site eventually breaks in a way you cannot fix, which is the actual answer to how long WordPress takes to learn: as long as it takes to reach maintenance, not as long as it takes to publish. Beginners are better served installing locally first, where a mistake costs nothing and no visitor sees it, then repeating the same steps on real hosting. The wider walkthrough of the screens, the hosted and self-hosted split, and the decisions worth making early is on the main WordPress page here, WordPress, for someone who has to run one.
Where this page stops
This page stops at the border of WordPress itself, because the next questions belong to different software. Whether Adobe Illustrator runs on an iPad is a question about a tablet application and this site does not treat that state as established, so no verdict is given here. Photoshop on a phone is settled and is covered on its own page: the iPhone app launched in February 2025 with a free base version that includes selections, layers, masks and compositing, and an Android version followed later in 2025.
The image work itself also sits outside this boundary. Resize, crop and compress a photograph in an image editor before it reaches the media library, because WordPress will generate several sizes of whatever you give it and none of that undoes a badly exposed original.