tobifjellner (Tor-Bjorn “Tobi” Fjellner)

Felmeddelandet antyder att felet inträffar i tillägget onecom-themes-plugins. Jag har inte tillgång till tillägget ifråga för att se vad som anropas på rad 115 i /wp-content/plugins/onecom-themes-plugins/onecom-themes-plugins.php

På One verkar det som om de har en hel svit av egna tillägg som automatiskt läggs in när du installerar WordPress med ett klick.

Du kan antagligen sätta tillägget (eller alla tillägg från One) ur spel genom att i Ones filhanterare leta dig fram till httpd.www/wp-content/plugins/ och där radera eller byta namn på katalogerna för deras tillägg. (WordPress databas innehåller en lista med länkar till huvudfilen för varje aktivt tillägg – om du byter namn på katalogen kommer filen inte att hittas och därmed är tillägget inaktiverat.)

Om föregående stycke känns besvärligt kan antagligen Ones egen support hjälpa dig mer handfast, eftersom de har tillgång till filstrukturen och enkelt kan uppdatera eller inaktivera tillägget.

Problemet är känt och kommer troligtvis att lösas snart. Du kan följa utvecklingen här: https://github.com/WordPress/gutenberg/issues/68641

Jag menade att du låter menyn i toppen av sidan vara kvar som den är, men ser till att de viktigaste länkarna i navigeringen också går att nå via någon mer bakåtkompatibel lösning längst ned på sidan.

Vilka övriga tillägg är aktiva på webbplatsen? Jag tror inte att Elementor eller WooCommerce är boven i detta. Snarare något som har med SEO, ”säkerhet” eller användarskapat innehåll att göra.

I så fall kanske nödlösningen från https://sv.wordpress.org/support/topic/lankarna-fungerar-inte-pa-mobilen/ kan fungera: lägg in en extra, ”ständigt öppen navigeringsmeny” längst ned på sidan.

En mapp med några filer lär inte strula till normal körning om ingenting anropar den koden.

Från din beskrivning är det inte helt klart vad du har under den extra katalogen. En hel separat WordPress-installation? Eller bara någon sorts omdirigeringskod?

I allmänhet är det god idé att ta bort filer som inte används, eftersom kodrester som ligger kvar utan att hållas uppdaterade kan innebära en större riskexponering för den händelse något där skulle råka innehålla kända svagheter som kan missbrukas av personer med fula avsikter. Se bara till att först spara en säkerhetskopia, så att du kan lägga tillbaka filen/filerna om det visar sig att webbplatsen inte fungerar utan dem.

Av samma anledning är det vettigt att radera gamla teman som du inte längre använder. (Men lämna kvar ett standardtema för säkerhets skull, t.ex. twentytwentyfive.)

Om din webbserver kör Apache har du troligtvis en eller flera filer med namnet .htaccess. Den filen kan innehålla en massa specialkommandon som kan anpassa hur webbservern stuvar om URL:er, förbjuder åtkomst till vissa filer, styra om vissa webbförfrågningar till cache-lagrade kopier, mm. Filen behövs normalt för att webbplatsen ska fungera med ”snygga permalänkar”, så att URL:er kan sluta på ”/2025/01/10/tillbakablick/” snarare än något i stil med ”index.php?p=15264”.

Innehållet i denna fil behöver ibland anpassas något, men ett typiskt utseende kan du kolla på https://developer.wordpress.org/advanced-administration/server/web-server/httpd/

Om du ser kommandon som är dåligt uppmärkta i den filen skulle du kunna prova att spara en säkerhetskopia av filen och sedan ta bort den på servern och därefter i adminpanelen besöka ”inställningar → permalänkar” för att låta WordPress återskapa filen. (Observera att om filen saknas behöver du kanske manuellt skriva in din adress som webbserverns-huvudadress/wp-admin/index.php.

Beroende på hur en webbplats är uppbyggd kan ”Beständig objektcachelagring” snabba upp en webbplats mer eller mindre mycket genom att spara ofta använda data nära tillhands, ofta direkt i serverprocessens arbetsminne.

MEN de effektivaste lösningarna för detta kräver speciell programvara och konfiguration på servern, något som inte alla webbhotell erbjuder.

Börja med att läsa https://developer.wordpress.org/reference/classes/wp_object_cache/#persistent-caching

Kolla sedan med ditt webbhotell om du har möjlighet att använda Redis. Om svaret är nej, så kan du botanisera bland de övriga lösningarna i dokumentet jag just länkade till.

Glöm inte att kolla om webbplatsen faktiskt blir snabbare med dessa lösningar. Om webbplatsen saknar dynamiskt innehåll (kommentarsfält, webbutik, etc.) kanske det räcker med något tillägg för helsides-cache i stället.

Därför att:

Varje gång WordPress bygger en sida är det mycket som händer på servern: WordPress läses in; Inställningarna hämtas; huvudfilen för varje aktivt tillägg definierar sina behövliga funktioner och köar upp begäran om återanrop vid olika tillfällen, sedan hämtas och definieras WordPress-kärnans överskrivbara funktinoer (om något tillägg redan definierat en funktion hoppar WordPress över kärnans inbyggda definition av samma funktion), och temats huvudfil körs. Först därefter börjar själva sidan att byggas, under ledning av ditt tema, och på olika bestämda platser i processen släpper temat in WordPress-kärnan och dina tillägg för nödvändiga funktioner.

Objekts-cache snabbar upp processen med att bygga en sida, genom att en rad databasanrop kan hoppas över.

Men om din webbplats saknar kommentarsfunktion och annat dynamiskt innehåll kan det räcka med att WordPress i lugn och ro bygger sina sidor, och en lösning för ”helsidescache” sparar dem som färdig HTML. Det går mycket snabbare om WordPress i början av processen upptäcker: Hmm. Den sidan har jag ju redan byggt, låt oss bara svara med den färdiga filen.

En ännu effektivare lösning du kan läsa om är s.k. ”Headless WordPress”. Då är grundidén att du administrerar en WordPress-webbplats som efter varje uppdatering bygger om en färdig ”skuggkopia” av hela webbplatsen så att utomstående besökare aldrig når själva WordPress utan direkt kan serveras färdiga filer. En trevlig bieffekt är att det är i princip omöjligt att hacka en webbplats av denna typ, eftersom WordPress självt är oåtkomligt för utomstående.

Man kan säga att jag använde den lösningen för en WordPress-webbplats som jag ”arkiverade”. Jag körde httrack på Windows för att bygga en kopia av hela webbplatsen i form av färdiga HTML-filer, som jag sedan laddade upp till en vanlig webbserver. Arkivkopian blev blixtsnabb. Servern behöver ju inte ens ladda in programmmiljön PHP, utan kan direkt svara med begärd fil.