We are not just a remote agency. We are an active part of the ecosystem. We believe in Open Source and contributing back to the community that powers over 40% of the web (W3Techs).
In Bern's competitive market, site speed is your strongest SEO asset. Our Astro + Headless WP stack delivers performance that leaves competitors behind.
For businesses in Bern serving Local SMB and Enterprise, data security is paramount. Headless architecture virtually eliminates standard WordPress attack vectors.
An institutional or service-provider site in Bern sits next to the Bundeshaus at Bundesplatz, canton Bern administration and Swisscom headquarters at Alte Tiefenaustrasse. That is not a reason for WordPress to pretend to be admin.ch. It is a reason for the theme, plugins and content model to be written the way a Swiss legal team, a German-speaking editor in Bern and a French-speaking reviewer from canton Vaud expect before anything reaches production.
WPPoland builds this WordPress from a senior Polish team for businesses, public-sector suppliers and organisations with a base, branch or client base in Bern. Scope is WordPress development: block or classic theme, custom plugins, Gutenberg, CPTs, ACF or native blocks, REST integrations and code review on Git. WooCommerce stores and maintenance retainers are separate topics, with links at the end.
Bern is not Basel with pharma and the stock exchange, nor Geneva with the UN and WTO. It is Bundesstadt: seat of the Federal Council, parliament and key federal offices around Bundesplatz. Canton Bern adds its own administration, universities and a dense network of IT suppliers serving public procurement. Swisscom, headquartered in Bern-Ost, is one of the city’s largest technology employers, but a WordPress brief here rarely reads “build us a site like a telecom operator”. More often it reads: inherited theme with three multilingual plugins, DE/FR publications that drift apart after an update, editorial team in Poland, and a reviewer in Bern asking about nFADP, hosting in CH and an accessibility statement before a landing goes live.
For a WordPress site those facts mean three harder requirements than on a typical B2B market. First, formal language: German front in formal Sie, French version in parallel, not machine translation from a Polish brief. Second, decision trail: who approves DE, who approves FR, what goes to staging, what goes to production when a parliamentary session or public-procurement deadline freezes changes. Third, residency and retention: hosting in Switzerland, backups, logs and form integrations are discussed before the first commit, not as a contract appendix after an incident.
Bern Digital Hub at Wylerstrasse and nearby coworking spaces (Impact Hub Bern, Biel/Bienne in the agglomeration) add reviewers who read pull requests and ask whether the consent plugin sends IP addresses to the US without a legal basis. The University of Bern (Universität Bern) and Bern University of Applied Sciences (BFH) produce people who can tell theme from plugin and know that Polylang does not replace an editorial process. Commuters from Biel/Bienne, Thun and Solothurn work in one office in German and French, so a DE/FR front with Polish editorial back office is more common here than a purely Polish front with a German panel.
The typical brief that reaches seniors does not read “make a nice site”. It reads: federal template from five years ago, WPML or Polylang serving German text on the French version after a patch, Gutenberg used like a notepad, and a new official publication created by copying last year’s page and manually swapping the document number. That is a content-model and Git-process problem, not a marketplace-theme problem.
WPPoland is not a contractor for admin.ch or canton Bern. Proximity to the Bundeshaus sets the bar for documentation, roles and bilingual delivery. It does not set a list of government references.
A new build in Bern starts with a decision that costs months if deferred: whether presentation lives in a block theme with theme.json, in classic PHP templates, and what goes into a plugin. That decision is written down before the first commit, because “we will add FR over the weekend before the deadline” usually ends in hreflang regression and a complaint from legal.
A block theme holds tokens: palette, type scale, spacing, content widths. For Bern B2B and public-sector suppliers that means a restrained palette, readable type without ornament and buttons that do not break on long German federal compounds or French administrative phrasing. Block patterns describe repeatable layouts: hero with legal disclaimer, team grid, attributed quote block, footer with Impressum and privacy-policy link aligned with nFADP. Editors assemble pages from patterns instead of asking a developer for a new template on every press release or public consultation.
Full site editing (FSE) makes sense when the editorial team genuinely needs control over header and footer. In practice many institutions and firms in Bern do not want that: the header is brand and compliance, not a playground. Then the block theme stays, but template parts (header, footer) are locked and editors work within patterns and custom blocks. That is a compromise, not a half measure.
Every custom block gets block.json, category, icon and schema attributes. Where content must reach search engines and RSS, render is server-side. React in the editor serves InspectorControls and preview, not a SPA front pretending to be WordPress.
Inherited installs in Bern are often five to seven years old: child theme on a commercial skeleton, ACF wired into page.php, shortcodes in content, jQuery from the pre-block era, multilingual plugin glued with hooks. Rewriting that to FSE “because it is 2026” costs more than fixing template hierarchy, moving logic into a plugin and adding Gutenberg only where editors actually assemble new landings.
A classic theme stays when:
Even then new pieces ship as blocks, not as more shortcodes. A shortcode in 2019 content stays for migration; new code does not add shortcodes.
The boundary is simple and recorded in the runbook. The theme shows. The plugin knows. CPT for official publications, CRM queue, REST endpoint for intranet, user role “PL editor” without publish_pages on German production: plugin. Colours, grid, hero pattern: theme. If changing the theme removes a federal events calendar, the architecture was wrong.
A custom plugin has its own prefix, PSR-4 autoload, main file with Plugin Name header and semver, and tests where logic matters (event dates, CRM field mapping, form validation). Business logic does not go into the theme’s functions.php, because functions.php dies with the theme and a Bern client changes branding agencies more often than the content model.
Layer comparison used at kickoff:
| Layer | What lives there | Example in Bern |
|---|---|---|
| Theme | presentation, tokens, patterns | landing for public consultation, Impressum footer |
| Plugin | CPTs, roles, REST, integrations | publication catalogue, audit logs, DE/FR sync |
| Gutenberg | editing without HTML | disclaimer pattern, person block with department |
| Staging and Git | process, not feature | branch, review, production promotion |
Gutenberg without a content model ends with every subpage as a unique block collage and nobody able to produce a list. In Bern lists are concrete: publications, announcements, people, positions, consultation events, office locations (Bundesplatz is not Wylerstrasse, Biel is not Thun). Those are objects, not “more pages in the tree”.
CPTs register with their own capabilities, not mapped to post. A editor in Poland should edit a publication, not delete plugins. CPT archives get a template or query pattern; singles get a template that stops editors breaking layout outside the agreed structure. Taxonomies are separate: document type (report, notice, form) does not mix with blog tags.
ACF has a place but not as a block substitute. ACF fields on CPTs suit data that are fields, not layout: publication number, effective date, language version, official PDF attachment. Person or article layout is assembled in Gutenberg. Mixing ACF Flexible Content with full block editor on the same object creates two sources of truth and an editor who does not know where to click.
Where ACF is unnecessary, block attributes in block.json are enough. A “person with quote” block does not need a field group on every page. It needs attributes and optionally InnerBlocks for biography. Fewer plugins in the admin means less attack surface and fewer conflicts with Swiss consent and cache plugins.
A shortcode in content is debt visible only at migration or PDF export. New code in Bern ships as a block with server render: semantic markup, attributes in block comments, filterable output. A publication-list block reads the CPT, caches the query with a transient with explicit TTL and invalidation on save_post, not on every request.
For DE/FR editorial every string in a block goes through WordPress i18n functions. German or French strings in PHP are exceptions, not the rule. Translations live in .po files or the multilingual plugin mechanism, not in a hardcoded array in the theme. Polylang or WPML is added only when there are genuinely two languages on the front. A German panel with content edited from Poland can work with roles and user locale without a full multilingual stack, but a DE/FR front in Bern usually needs the full pair.
Code review on a block checks three things before merge: does the block work with front-end JS disabled, do attributes have types and defaults, does it avoid loading the full editor build on the front. Gutenberg that adds a megabyte of React to an executive profile page does not pass review.
A landing for a parliamentary session, public-consultation deadline or Bern Digital Hub event is not created by copying last year’s page. It is a CPT object with date, language, reference number and pattern. After the deadline the object stays in the archive, not as an orphan subpage in the tree.
The most common friction in Poland-Bern collaboration is not PHP. It is tone and the language pair. Institutional German uses formal Sie. The French version cannot be a literal translation from a Polish brief or a machine export from DE without native review. That is not solved by a translation plugin alone. It is a language brief, a string list in the theme and an approval process before production.
Practical rules written into theme documentation:
Polylang and WPML solve hreflang and language copies. They do not solve process: who approves German text, who approves French, before production. The brief records whether approval sits with the client in Bern, with the Polish content lead, or both in parallel. Staging shows both language versions because “DE broke because someone edited FR” appears only on comparison, not in Lighthouse.
Federal and cantonal communication culture in Bern is more formal than startup copy from a coworking space. Sie in DE, vous in FR in UI, transactional email and form errors. Du or tutoiement may be acceptable on a startup careers page if the brief records it. Default mixing registers in one theme is a bug, not flexibility.
Accessibility in Bern is not one checkbox. Public institutions and many suppliers working for the public sector must account for digital accessibility requirements referencing EN 301 549 and WCAG 2.1 AA (with migration to WCAG 2.2 where the auditor requires it). That is not German BITV or BFSG. The Swiss federal context has its own expectations for accessibility statements, feedback channels and testability before publishing citizen-facing documents.
Private-sector firms in Bern (Swisscom, IT suppliers, law firms handling procurement) often copy the same standards because reviewers on the client side are used to WCAG lists from federal projects. The team does not sell an “admin.ch accessibility certificate”. At kickoff we record which regime applies to the site, then test what can be tested in theme and blocks.
What the team does in code:
Automated scan (axe, Lighthouse) is a CI gate, not proof of compliance. For public-sector clients or contracts requiring WCAG, we add manual keyboard path and WCAG checklist comparison in both languages. The team does not issue certificates that were not in scope.
If the brief moves to WooCommerce, scope shifts to WooCommerce developer in Bern.
Proximity to the Bundeshaus and Swisscom does not turn a marketing WordPress site into a federal classification system. The team does not claim “ISO 27001 compliant” or “NCSC certified” unless the client ran that audit. ISO 27001 covers the client’s information-security management system. WordPress should deliver inventory, access trail and update discipline the client can paste into procurement or processor-agreement documentation, not an agency “compliance stamp”.
Posture maintainable in code and process without pretending to be an audit:
GDPR and nFADP are separate layers in cross-border briefs: form-field minimisation, processor agreement, consent for scripts, hosting location. Hosting “in Switzerland” is a jurisdiction argument, not a magic shield. A form collecting personal data without legal basis and without policy coverage is not fixed by a server in Bern-Ost alone.
Penetration tests are mentioned only when the client has or orders them from a lab. WPPoland does not add certificates it does not hold. Hardening WordPress is a set of pull-request decisions, not a slide about zero incidents.
This layer separates senior WordPress work from “upload a ZIP over FTP”. In Bern a client with an IT department or public-procurement experience asks about it on the second meeting, especially if the reviewer comes from BFH, Bern Digital Hub or internal IT at Swisscom.
The repository holds the theme and custom plugins. Plugins from WordPress.org and Core do not live as copied folders in Git unless there is a hard reason (fork, patch, air-gap). One feature branch per change: new block, new CPT, a11y fix, DE/FR sync. Pull request has description, screenshots or editor recording, and checklist: i18n, accessibility, no secrets, block does not break classic template if one still lives, both language versions pass regression.
Code review is done by a senior who did not write the branch. Review runs WordPress Coding Standards (PHPCS, WordPress-Core sniffs) but also reads intent: should the CPT be a plugin, does ACF duplicate block attributes, does the hook hang on init without need. PR comments are in English or Polish depending on the client reviewer; Swiss IT in Bern usually prefers English in the diff and DE/FR in editorial documentation.
Staging is a production copy with anonymised data. WP-CLI search-replace on URL, separate keys, crons that send mail to real addresses disabled. Editorial clicks through staging with real Gutenberg patterns in both languages, not on the developer’s localhost. Multilingual and keyboard regression happen here. Production promotion is a documented step: tag or merge to main, asset build, cache warmup, rollback path (previous tag). The team does not “quick upload” one PHP file over SFTP, because nobody can reconstruct what was on production on Friday before a federal publication deadline.
WP-CLI is operational: flush transients, wp scaffold, CPT import, autoload check. It does not replace tests. Where plugin logic matters (dates, mapping, validation), PHPUnit follows. Blocks with non-trivial UI get an editor test on staging, because jsdom will not catch InspectorControls covering Speichern or Enregistrer in the right locale.
Performance budget is part of acceptance, not a separate project. Lighthouse and Core Web Vitals on templates that actually exist: CPT archive, single, hero pattern page in DE and FR. Images in AVIF/WebP through the build pipeline, theme CSS without importing the entire block universe, editor JS not on the front. Redis object cache makes sense when transients and CPT queries show it, not because “that is what you do in Bundesstadt”.
Bern Digital Hub at Wylerstrasse 60A is a reference point for Bern’s digital ecosystem: meetups, networking, projects linking administration, startups and IT suppliers. It is not a WPPoland sales argument. It is a barometer: editorial and IT teams in Bern ask about the repository, staging and whether the theme breaks the editor after a Core update because they heard those questions at local meetups and in BFH corridors.
Impact Hub Bern and nearby initiatives add reviewers who read copy and code. The University of Bern and BFH supply people who can tell theme from plugin and know Polylang does not replace FR approval. Swisscom as an employer sets the bar for suppliers in the chain: questions about data location and log retention appear earlier than on a typical Polish B2B market.
The wider Swiss scene has WordCamp Switzerland and meetups in Zurich or Basel, but a Bern brief does not need to pretend to be Basel banking or Geneva diplomacy. For this city DE/FR bilingual delivery, public sector and canton Bern matter more than a slide about “global organisations”. Themes and plugins from this team must survive questions: where alt text comes from, who approves the French version, whether a form sends data outside CH without legal basis.
This page does not build checkout, TWINT gateways or product catalogues. If the brief moves to shop, VAT, PostFinance integration or QR-Rechnung, scope changes owner and is described by the WooCommerce developer in Bern. Pillar without city: WooCommerce developer. Mixing shop and institutional theme in one repository without plugin boundaries is the fastest route to a Woo update breaking a public-consultation landing, or the reverse.
A corporate site with one “shop” button to external Woo can stay in the theme as a link. Cart logic itself does not.
A development engagement ends with documentation, handover session and Git access for the client team. The runbook describes: how to add a pattern, how to register a new CPT, how to ship a branch, how to rebuild staging, whom to call when the editor will not save, how to publish a DE/FR pair without hreflang regression. If ongoing Core updates, monitoring and on-call are needed after launch, that is WordPress maintenance in Bern, not a hidden annex to the theme. Pillar without city: WordPress maintenance.
Development pricing is individual and delivered in writing after scope is agreed. There is no rate card or “hour packages” on this page. Scope changes (sudden FSE, third language, federal intranet integration) return to the written record before they enter a sprint.
A short brief is enough to begin: which theme and plugins exist today, who edits (PL/DE/FR), whether the front should use formal Sie and vous, whether CPTs for publications and events are in scope, whether Bern IT requires Git and staging from day zero, where hosting sits and whether backups must stay in CH. The team reviews the install, lists risks (Gutenberg used as a notepad, secrets in repo, missing accessibility statement, ACF duplicated with blocks, broken DE/FR pair) and proposes a plan with acceptance criteria.
Contact: WPPoland contact form. The service pillar without city in the slug remains at WordPress developer.
We serve clients in Bern and nearby areas.
This page features specific insights for Bern.
An institutional or service-provider site in Bern sits next to the Bundeshaus at Bundesplatz, canton Bern administration and Swisscom headquarters at Alte Tiefenaustrasse. That is not a reason for WordPress to pretend to be admin.ch. It is a reason for the theme, plugins and content model to be written the way a Swiss legal team, a German-speaking editor in Bern and a French-speaking reviewer from canton Vaud expect before anything reaches production.
WPPoland builds this WordPress from a senior Polish team for businesses, public-sector suppliers and organisations with a base, branch or client base in Bern. Scope is WordPress development: block or classic theme, custom plugins, Gutenberg, CPTs, ACF or native blocks, REST integrations and code review on Git. WooCommerce stores and maintenance retainers are separate topics, with links at the end.
Bern is not Basel with pharma and the stock exchange, nor Geneva with the UN and WTO. It is Bundesstadt: seat of the Federal Council, parliament and key federal offices around Bundesplatz. Canton Bern adds its own administration, universities and a dense network of IT suppliers serving public procurement. Swisscom, headquartered in Bern-Ost, is one of the city’s largest technology employers, but a WordPress brief here rarely reads “build us a site like a telecom operator”. More often it reads: inherited theme with three multilingual plugins, DE/FR publications that drift apart after an update, editorial team in Poland, and a reviewer in Bern asking about nFADP, hosting in CH and an accessibility statement before a landing goes live.
For a WordPress site those facts mean three harder requirements than on a typical B2B market. First, formal language: German front in formal Sie, French version in parallel, not machine translation from a Polish brief. Second, decision trail: who approves DE, who approves FR, what goes to staging, what goes to production when a parliamentary session or public-procurement deadline freezes changes. Third, residency and retention: hosting in Switzerland, backups, logs and form integrations are discussed before the first commit, not as a contract appendix after an incident.
Bern Digital Hub at Wylerstrasse and nearby coworking spaces (Impact Hub Bern, Biel/Bienne in the agglomeration) add reviewers who read pull requests and ask whether the consent plugin sends IP addresses to the US without a legal basis. The University of Bern (Universität Bern) and Bern University of Applied Sciences (BFH) produce people who can tell theme from plugin and know that Polylang does not replace an editorial process. Commuters from Biel/Bienne, Thun and Solothurn work in one office in German and French, so a DE/FR front with Polish editorial back office is more common here than a purely Polish front with a German panel.
The typical brief that reaches seniors does not read “make a nice site”. It reads: federal template from five years ago, WPML or Polylang serving German text on the French version after a patch, Gutenberg used like a notepad, and a new official publication created by copying last year’s page and manually swapping the document number. That is a content-model and Git-process problem, not a marketplace-theme problem.
WPPoland is not a contractor for admin.ch or canton Bern. Proximity to the Bundeshaus sets the bar for documentation, roles and bilingual delivery. It does not set a list of government references.
A new build in Bern starts with a decision that costs months if deferred: whether presentation lives in a block theme with theme.json, in classic PHP templates, and what goes into a plugin. That decision is written down before the first commit, because “we will add FR over the weekend before the deadline” usually ends in hreflang regression and a complaint from legal.
A block theme holds tokens: palette, type scale, spacing, content widths. For Bern B2B and public-sector suppliers that means a restrained palette, readable type without ornament and buttons that do not break on long German federal compounds or French administrative phrasing. Block patterns describe repeatable layouts: hero with legal disclaimer, team grid, attributed quote block, footer with Impressum and privacy-policy link aligned with nFADP. Editors assemble pages from patterns instead of asking a developer for a new template on every press release or public consultation.
Full site editing (FSE) makes sense when the editorial team genuinely needs control over header and footer. In practice many institutions and firms in Bern do not want that: the header is brand and compliance, not a playground. Then the block theme stays, but template parts (header, footer) are locked and editors work within patterns and custom blocks. That is a compromise, not a half measure.
Every custom block gets block.json, category, icon and schema attributes. Where content must reach search engines and RSS, render is server-side. React in the editor serves InspectorControls and preview, not a SPA front pretending to be WordPress.
Inherited installs in Bern are often five to seven years old: child theme on a commercial skeleton, ACF wired into page.php, shortcodes in content, jQuery from the pre-block era, multilingual plugin glued with hooks. Rewriting that to FSE “because it is 2026” costs more than fixing template hierarchy, moving logic into a plugin and adding Gutenberg only where editors actually assemble new landings.
A classic theme stays when:
Even then new pieces ship as blocks, not as more shortcodes. A shortcode in 2019 content stays for migration; new code does not add shortcodes.
The boundary is simple and recorded in the runbook. The theme shows. The plugin knows. CPT for official publications, CRM queue, REST endpoint for intranet, user role “PL editor” without publish_pages on German production: plugin. Colours, grid, hero pattern: theme. If changing the theme removes a federal events calendar, the architecture was wrong.
A custom plugin has its own prefix, PSR-4 autoload, main file with Plugin Name header and semver, and tests where logic matters (event dates, CRM field mapping, form validation). Business logic does not go into the theme’s functions.php, because functions.php dies with the theme and a Bern client changes branding agencies more often than the content model.
Layer comparison used at kickoff:
| Layer | What lives there | Example in Bern |
|---|---|---|
| Theme | presentation, tokens, patterns | landing for public consultation, Impressum footer |
| Plugin | CPTs, roles, REST, integrations | publication catalogue, audit logs, DE/FR sync |
| Gutenberg | editing without HTML | disclaimer pattern, person block with department |
| Staging and Git | process, not feature | branch, review, production promotion |
Gutenberg without a content model ends with every subpage as a unique block collage and nobody able to produce a list. In Bern lists are concrete: publications, announcements, people, positions, consultation events, office locations (Bundesplatz is not Wylerstrasse, Biel is not Thun). Those are objects, not “more pages in the tree”.
CPTs register with their own capabilities, not mapped to post. A editor in Poland should edit a publication, not delete plugins. CPT archives get a template or query pattern; singles get a template that stops editors breaking layout outside the agreed structure. Taxonomies are separate: document type (report, notice, form) does not mix with blog tags.
ACF has a place but not as a block substitute. ACF fields on CPTs suit data that are fields, not layout: publication number, effective date, language version, official PDF attachment. Person or article layout is assembled in Gutenberg. Mixing ACF Flexible Content with full block editor on the same object creates two sources of truth and an editor who does not know where to click.
Where ACF is unnecessary, block attributes in block.json are enough. A “person with quote” block does not need a field group on every page. It needs attributes and optionally InnerBlocks for biography. Fewer plugins in the admin means less attack surface and fewer conflicts with Swiss consent and cache plugins.
A shortcode in content is debt visible only at migration or PDF export. New code in Bern ships as a block with server render: semantic markup, attributes in block comments, filterable output. A publication-list block reads the CPT, caches the query with a transient with explicit TTL and invalidation on save_post, not on every request.
For DE/FR editorial every string in a block goes through WordPress i18n functions. German or French strings in PHP are exceptions, not the rule. Translations live in .po files or the multilingual plugin mechanism, not in a hardcoded array in the theme. Polylang or WPML is added only when there are genuinely two languages on the front. A German panel with content edited from Poland can work with roles and user locale without a full multilingual stack, but a DE/FR front in Bern usually needs the full pair.
Code review on a block checks three things before merge: does the block work with front-end JS disabled, do attributes have types and defaults, does it avoid loading the full editor build on the front. Gutenberg that adds a megabyte of React to an executive profile page does not pass review.
A landing for a parliamentary session, public-consultation deadline or Bern Digital Hub event is not created by copying last year’s page. It is a CPT object with date, language, reference number and pattern. After the deadline the object stays in the archive, not as an orphan subpage in the tree.
The most common friction in Poland-Bern collaboration is not PHP. It is tone and the language pair. Institutional German uses formal Sie. The French version cannot be a literal translation from a Polish brief or a machine export from DE without native review. That is not solved by a translation plugin alone. It is a language brief, a string list in the theme and an approval process before production.
Practical rules written into theme documentation:
Polylang and WPML solve hreflang and language copies. They do not solve process: who approves German text, who approves French, before production. The brief records whether approval sits with the client in Bern, with the Polish content lead, or both in parallel. Staging shows both language versions because “DE broke because someone edited FR” appears only on comparison, not in Lighthouse.
Federal and cantonal communication culture in Bern is more formal than startup copy from a coworking space. Sie in DE, vous in FR in UI, transactional email and form errors. Du or tutoiement may be acceptable on a startup careers page if the brief records it. Default mixing registers in one theme is a bug, not flexibility.
Accessibility in Bern is not one checkbox. Public institutions and many suppliers working for the public sector must account for digital accessibility requirements referencing EN 301 549 and WCAG 2.1 AA (with migration to WCAG 2.2 where the auditor requires it). That is not German BITV or BFSG. The Swiss federal context has its own expectations for accessibility statements, feedback channels and testability before publishing citizen-facing documents.
Private-sector firms in Bern (Swisscom, IT suppliers, law firms handling procurement) often copy the same standards because reviewers on the client side are used to WCAG lists from federal projects. The team does not sell an “admin.ch accessibility certificate”. At kickoff we record which regime applies to the site, then test what can be tested in theme and blocks.
What the team does in code:
Automated scan (axe, Lighthouse) is a CI gate, not proof of compliance. For public-sector clients or contracts requiring WCAG, we add manual keyboard path and WCAG checklist comparison in both languages. The team does not issue certificates that were not in scope.
If the brief moves to WooCommerce, scope shifts to WooCommerce developer in Bern.
Proximity to the Bundeshaus and Swisscom does not turn a marketing WordPress site into a federal classification system. The team does not claim “ISO 27001 compliant” or “NCSC certified” unless the client ran that audit. ISO 27001 covers the client’s information-security management system. WordPress should deliver inventory, access trail and update discipline the client can paste into procurement or processor-agreement documentation, not an agency “compliance stamp”.
Posture maintainable in code and process without pretending to be an audit:
GDPR and nFADP are separate layers in cross-border briefs: form-field minimisation, processor agreement, consent for scripts, hosting location. Hosting “in Switzerland” is a jurisdiction argument, not a magic shield. A form collecting personal data without legal basis and without policy coverage is not fixed by a server in Bern-Ost alone.
Penetration tests are mentioned only when the client has or orders them from a lab. WPPoland does not add certificates it does not hold. Hardening WordPress is a set of pull-request decisions, not a slide about zero incidents.
This layer separates senior WordPress work from “upload a ZIP over FTP”. In Bern a client with an IT department or public-procurement experience asks about it on the second meeting, especially if the reviewer comes from BFH, Bern Digital Hub or internal IT at Swisscom.
The repository holds the theme and custom plugins. Plugins from WordPress.org and Core do not live as copied folders in Git unless there is a hard reason (fork, patch, air-gap). One feature branch per change: new block, new CPT, a11y fix, DE/FR sync. Pull request has description, screenshots or editor recording, and checklist: i18n, accessibility, no secrets, block does not break classic template if one still lives, both language versions pass regression.
Code review is done by a senior who did not write the branch. Review runs WordPress Coding Standards (PHPCS, WordPress-Core sniffs) but also reads intent: should the CPT be a plugin, does ACF duplicate block attributes, does the hook hang on init without need. PR comments are in English or Polish depending on the client reviewer; Swiss IT in Bern usually prefers English in the diff and DE/FR in editorial documentation.
Staging is a production copy with anonymised data. WP-CLI search-replace on URL, separate keys, crons that send mail to real addresses disabled. Editorial clicks through staging with real Gutenberg patterns in both languages, not on the developer’s localhost. Multilingual and keyboard regression happen here. Production promotion is a documented step: tag or merge to main, asset build, cache warmup, rollback path (previous tag). The team does not “quick upload” one PHP file over SFTP, because nobody can reconstruct what was on production on Friday before a federal publication deadline.
WP-CLI is operational: flush transients, wp scaffold, CPT import, autoload check. It does not replace tests. Where plugin logic matters (dates, mapping, validation), PHPUnit follows. Blocks with non-trivial UI get an editor test on staging, because jsdom will not catch InspectorControls covering Speichern or Enregistrer in the right locale.
Performance budget is part of acceptance, not a separate project. Lighthouse and Core Web Vitals on templates that actually exist: CPT archive, single, hero pattern page in DE and FR. Images in AVIF/WebP through the build pipeline, theme CSS without importing the entire block universe, editor JS not on the front. Redis object cache makes sense when transients and CPT queries show it, not because “that is what you do in Bundesstadt”.
Bern Digital Hub at Wylerstrasse 60A is a reference point for Bern’s digital ecosystem: meetups, networking, projects linking administration, startups and IT suppliers. It is not a WPPoland sales argument. It is a barometer: editorial and IT teams in Bern ask about the repository, staging and whether the theme breaks the editor after a Core update because they heard those questions at local meetups and in BFH corridors.
Impact Hub Bern and nearby initiatives add reviewers who read copy and code. The University of Bern and BFH supply people who can tell theme from plugin and know Polylang does not replace FR approval. Swisscom as an employer sets the bar for suppliers in the chain: questions about data location and log retention appear earlier than on a typical Polish B2B market.
The wider Swiss scene has WordCamp Switzerland and meetups in Zurich or Basel, but a Bern brief does not need to pretend to be Basel banking or Geneva diplomacy. For this city DE/FR bilingual delivery, public sector and canton Bern matter more than a slide about “global organisations”. Themes and plugins from this team must survive questions: where alt text comes from, who approves the French version, whether a form sends data outside CH without legal basis.
This page does not build checkout, TWINT gateways or product catalogues. If the brief moves to shop, VAT, PostFinance integration or QR-Rechnung, scope changes owner and is described by the WooCommerce developer in Bern. Pillar without city: WooCommerce developer. Mixing shop and institutional theme in one repository without plugin boundaries is the fastest route to a Woo update breaking a public-consultation landing, or the reverse.
A corporate site with one “shop” button to external Woo can stay in the theme as a link. Cart logic itself does not.
A development engagement ends with documentation, handover session and Git access for the client team. The runbook describes: how to add a pattern, how to register a new CPT, how to ship a branch, how to rebuild staging, whom to call when the editor will not save, how to publish a DE/FR pair without hreflang regression. If ongoing Core updates, monitoring and on-call are needed after launch, that is WordPress maintenance in Bern, not a hidden annex to the theme. Pillar without city: WordPress maintenance.
Development pricing is individual and delivered in writing after scope is agreed. There is no rate card or “hour packages” on this page. Scope changes (sudden FSE, third language, federal intranet integration) return to the written record before they enter a sprint.
A short brief is enough to begin: which theme and plugins exist today, who edits (PL/DE/FR), whether the front should use formal Sie and vous, whether CPTs for publications and events are in scope, whether Bern IT requires Git and staging from day zero, where hosting sits and whether backups must stay in CH. The team reviews the install, lists risks (Gutenberg used as a notepad, secrets in repo, missing accessibility statement, ACF duplicated with blocks, broken DE/FR pair) and proposes a plan with acceptance criteria.
Contact: WPPoland contact form. The service pillar without city in the slug remains at WordPress developer.
Explore selected projects supporting our clients' success.
The website project car-mechanic-huntington.co.uk was created with the aim of professionally presenting the services of a car workshop. The primary goal of t...
centrumpoludnie.pl is an information portal for a shopping centre in southern Gdansk, covering shops, promotions, news, and simple administration.
DKF.za.pl is a website created in 2010 for the Film Discussion Club “ZA”, operating as part of the Polish Federation of Film Discussion Clubs. The project wa...
How we approach AI citations, WooCommerce B2B modernization, and NIS2-aligned operational resilience on WordPress. These guides apply to every client location.
Local expertise: - Senior WordPress development for businesses and institutions in Bern - Themes, plugins, Gutenberg and CPTs for DE/FR bilingual and public-sector requirements - WordPress Coding Standards, accessibility and i18n built into the workflow Our team understands the Bern market and tailors solutions to local business needs. In practice, this means a focus on Core Web Vitals, local intent, and information architecture tailored to the Bern market.
Let's discuss how we can bring top-tier performance to your project.
Schedule free consultation in BernStay updated with the WordPress Developer community
Since 26 August 2026, links in Google results go through google.com/goto instead of straight to the page. What this changes in analytics, in rank tracking tools and in WordPress, and what it does not change at all.
WP Rocket 3.23.2.1 and earlier fatal on WordPress 7.1: TypeError in Cloudflare.php line 562. GitHub report 6 July, sites down 19 August, fix 3.23.2.2 on 20 August. Update the plugin first.
Google now expands AI Overviews to a full AI Mode answer on some queries and pushes the ten blue links down. Our Search Console numbers on offer URLs at positions 2 to 4, and what we changed so the overview has a fact to cite.
Google changed its JSON-LD extraction and now applies only one pass of HTML unescaping. Double-escaped entities are no longer unrolled, so the block stops parsing and the structured data disappears. How to measure your own corpus and how to encode it correctly.
Google splits site reputation manual actions by searcher location from 30 August 2026. Outside the EEA the demotion still hits the affected portion. Inside the EEA that impact does not apply; the section may rank independently. Why parasite SEO does not return.
More articles are available on /en/blog/
Custom themes built to WordPress Coding Standards, custom plugins, Gutenberg block patterns, CPT-driven content models with ACF or native block attributes, REST integrations and large refactors of legacy themes. The brief stays anchored to WordPress development for businesses, public-sector suppliers and organisations based in Bern or canton Bern. If a different stack would serve you better, I say so in writing rather than changing the topic.
Both. A new project usually starts with a custom block theme built on the editor APIs (theme.json, block patterns, block variations). Inherited federal or cantonal installs often need a focused refactor of template hierarchy, multilingual layer and asset pipeline rather than a rewrite. The decision is made on cost-versus-debt grounds, not on what is more interesting to build.
For new builds the default is a block theme with full site editing, since that is where the WordPress editor is going. Classic PHP themes still make sense when existing template logic or an older multilingual stack is too expensive to port, or when the editorial team works in the classic editor and a tool change would be a bigger risk than technical debt. The choice is documented as a written trade-off, not a religious decision.
If a feature is functional rather than presentational, it lives in a plugin so it survives a theme switch. Themes describe presentation and editorial structure; plugins host integrations, custom post types that outlive the theme, business logic, REST endpoints and admin tools. The boundary is set during the architecture step and recorded in the runbook.
Living documentation for editors and developers, code-review trails on every branch, a written architecture decision record for non-obvious choices, and a handover session at the end of the engagement. The project can then move to your team or to the optional maintenance retainer with the same documentation. Ongoing updates and monitoring are described on the maintenance page, not hidden inside this development brief.
Strengthen your business with professional technical support in key areas of the WordPress ecosystem.
CrUX field-data audit with per-template LCP, INP, CLS attribution.
Core Web Vitals, caching, and faster delivery.
Stability, updates, and post-launch support.
Migration to Astro, Next.js, and headless WordPress.
Headless WordPress, Sanity, Strapi, and Contentful with Astro or Next.js.
Audit, hardening, and incident risk reduction.
How to optimize Interaction to Next Paint (INP) on WordPress sites. Practical fixes for the newest Core Web Vital metric that directly impacts Google rankings.
Field versus lab, LCP, INP and CLS for WordPress in 2026. Google's green LCP is still 2.5 s in CrUX. 100/100 in Lighthouse is a lab target. Edge HTML, consent banners, checkout widgets.
Compare the best image optimisation plugins for WordPress, configure WebP/AVIF delivery, extract critical CSS, and set up LiteSpeed Cache for maximum PageSpeed scores.