Heb je zelf die Wordpress geïnstalleerd of is dat via het control panel van de hosting provider gegaan? Indien dat laatste dan valt het beheer van de geïnstalleerde Wordpress ook onder dat control panel (in ieder geval gedeeltelijk; uitgezonderd mogelijk eigen toegevoegde modules, of hoe die dingen dan ook heten in Wordpress of PHP, en moet je rekening houden met updates, beveiligingsupdates, etc.).

Het wp thema dat ik gebruik heeft een builder. De hostingprovider biedt binnen plesk standaard installeren van WP aan. Dit betekent dat updates automatisch worden gedaan.

Maar suggereer je hiermee dat updates wijzigingen kunnen aanbrengen waardoor de lay-out veranderd?

De provider zou dit kunnen vertellen, als dit zo is en de logging beschikbaar stellen. Als dit een policy is ben je daar waarschijnlijk in de kleine lettertjes mee akkoord gegaan.

Even bellen is waarschijnlijk sneller iets weten dan de vraag hier stellen.

of een feature, wellicht dat de plugin/thema lek is. Zoek het eens op in https://www.exploit-db.com/

Het zou ook zo kunnen zijn dat de versie niet meer compatibel is met de huidige versie van Wordpress, bijvoorbeeld als Wordpress automatische updates doet en dat Wordpress hem daarom uitzet.

Wordfence heeft iniedergeval een IP login geschiedenis. Daar zou je in kunnen kijken of er een successvolle login poging was.

Ik weet niet... Had je het verdwenen theme in gebruik?

Als eerste je bent geen eigenaar van de server nog de hosting omgeving je leased een stukje bij je provider de naam zegt het al *shared* dat betekend dat jij beheerder bent maar hun zijn bovenliggend beheerder.

Het is gebruikelijk dat provider van sharedhosting ook beveiliging hebben draaien om ongein te herkennen bij ftp upload en public, private html folders. Dit is een geautomatiseerd proces waar normaliter als het goed ingesteld staat een mail wordt uitgestuurd richting de klant met wat geconstateerd is. Dit soort beveiliging kan ook automatisch scripts verwijderen als deze onveilig blijken. Verzuimd een klant bijvoorbeeld om na herhaaldelijk mails hun omgeving veilig te maken dan haal je de ignore flag weg en volgende run schoont de software de omgeving op. Kosten rekening naar klant wegens verzuim.
De kans is echter klein dat dit zonder berichtgeving is gebeurd.

Wordfence is maar een plugin dat opereert op je site je hoster heeft toegang tot de directe bestanden.
Voor Wordpress als je de respectievelijke plugin map delete dan is de functie eruit. Er komt een eenmalige melding in beeld bij volgende refresh op de plugin pagina dat een plugin niet gevonden kon worden en daarna is het niet meer zichtbaar. Wordfence beveiligd enkel van buiten naar binnen jouw provider opereert van binnen dus Wordfence kan niks voor je betekenen as it should.

Poorten heeft hier weinig mee te maken je provider runt op local en hoeft nergens naar toe ze zijn of via SSH verbonden of via een NoVNC console of iLO of simpelweg de ingebouwde Plesk functie voor overname van beheer. En je mag aannemen dat los van je Web Application Firewall je provider zelf hardware firewalls heeft of geavanceerde security suites met bijvoorbeeld Modsecurity V3 rulesets of gelijkwaardige middelen.

Je kunt (mits je toegang hebt vanuit de feature manager) de Apache, Nginx raw logs uitlezen om te kijken welke acties zijn gestuurd naar het domein. Echter directe acties via console komen hier *niet* in terug daarvoor zul je in de console moeten duiken en als je geen shell toegang hebt houdt dat op. Het commando "last" is een goed begin punt.

Een provider gaat zich echter ook niet zomaar wagen op de shared omgeving van een van hun klanten de logs zijn absoluut te wissen als men voldoende rechten heeft (en die heeft je provider) Maar ten eerste laat dat sporen achter waarin staat dat er gewist is en dat is een sure fire way om een rechtszaak uit te lokken. Daarnaast werk je met beveiliging lagen en niet alle beheerders bij een provider kunnen bij alle lagen komen ook op een VPS. En dit alles wordt uiteraard ook vermeldt in je S.L.A.

Wil je uitsluiten dat het een bug was dan zul je de debug log functie moeten activeren in wp-config.php (wel display uitzetten) Wil je uitgebreidere logs welke acties zijn gedaan door Wordpress en ingelogde gebruikers dan kun je iets gebruiken als WP activity log plugin. Voor filtering optie moet je wel betalen bij die plugin.

Indien je echter geen plugin bedoeld maar een thema functie die eruit is dan heb je mogelijk te maken met standaard gedraging. Tenzij je een childtheme hebt gemaakt zullen bij een thema update *alle* function aanpassingen worden vervangen.

Nou op zich wel enigzins verhelderend. Ik denk dat het lastig is achteraf vast te stellen wat de oorzaak was, omdat ik wel WP_DEBUG true had, maar niet WP_DEBUG_LOG. Ik heb ook bij reproduceren vd pagina geen debog.log gevonden.

Een plugin als WP activity lijkt een oplossing maar meer voor multi-user site en dat is deze website niet.

Waar ik naar zoek is logs die aangeven welke plugins er geupdate zijn en wanneer. Standaard worden plugins en themes en wp gecontroleerd op updates en uitgevoerd.

Het is ook niet dat ik geen backup heb, maar toch wil ik de oorzaak kennen van de verdwenen thema module.

Wordpress houdt dit standaard niet bij of beter gezegd het slaat de informatie niet op maar gooit het meteen weg. De genoemde plugin kan dit soort acties ook herkennen maar uit ervaring weet ik dat de gratis versie een nachtmerrie is om in te zoeken omdat je dus niet kan filteren.

Dat gezegd is een bijfunctie het registeren van meerdere gebruikers maar het doet veel meer dan dat. Wij installeren het zodra een klant klaagt over site gedrag zoals jij vermeldt. 9 van 10 keer komt dan in de logs naar voren dat het een actie van een legitieme gebruiker is en vaak de klant die klaagt.

Je kan ook Stream proberen van XWP die is gratis maar verwacht weinig tot geen ondersteuning van XWP als er problemen zijn. Ook is de rapporteer functie rond uit slecht.

Indien je beschikt over spare servers is het raadzaam als het site gedrag dermate storend is of risico voor conversie en uitvoering om een server snapshot van moment dat goed ging in te laden op mirrored hardware of virtualisatie. Vervolgens pas je de domeinnaam aan naar iets anders zet de site op no index zet debug aan en kijk of het gedrag zich opnieuw vertoont. We doen dit zelf enkel bij de grotere mysteries maar het is meestal de sure fire way om bugs compleet uit te sluiten.

Je moet je bedenken dat je hoster de boel kan updaten via toegang tot het filesystem of tot een user op de server
en daarbij helemaal niet via het hele WordPress gebeuren gaat. Dus WordPress zelf logt daar niks over, er zijn hooguit
operating system logs van die activiteit.

Ik vind het eigenlijk wel goed als hosters dat soort dingen doen want het voorkomt dat allerlei sites nadat ze enthousiast
geinstalleerd zijn, nooit meer geupdate worden en veiligheidsproblemen hebben.
Alleen betekent dat wel dat je zelf de functionaliteit van je site voortdurend in de gaten moet houden! Het zou mooi
zijn als je hoster een mailtje stuurde als ze een update gedaan hebben, zodat je dit soort problemen op dat moment
kunt onderzoeken ipv dat je maanden later bij verrassing er achter komt dat iets niet meer werkt.

Wordfence scant op backdoors is te lezen op hun eigen site. Maar, indien een backdoor (bijv door dit in te sluiten in een *.jpg of *.png) niet gedetecteerd wordt dan heeft een hacker vrij spel. Echter het is speculatief.

++++++++++++++++++++++++++

Het is bekend dat (geldt voor alle) plugin updates soms (hoe vaak?) bepaalde php/wordpress/css code die door een webdesigner was gewijzigd, weer overschrijven. Daarop wordt bij update geattendeerd; om te backuppen.

In mijn huidige situatie is dat echter niet het geval. Ik werk met een bekende pagina/theme builder. Hierin zitten modules voor bv tekst, fotogalerij, header etc. Hiervan is er 1 verdwenen.

WordPress, dat is toch die RAT met blog functionaliteit?

Als je volledige controle over je systeem wilt hebben moet je geen "shared hosting voor Wordpress" afnemen
maar een "Linux VPS" (zelf beheerd) en daar de hele boel op installeren. Dwz de basis pakketten zoals Apache2, mariadb
en PHP7 en het WordPress gebeuren. Je hoster zal wellicht in hun standaard images wel de "unattended upgrades"
aangezet hebben om niet met zwaar verouderde meuk te komen te zitten (en de bijbehorende klachten op hun abusedesk)
maar in ieder geval kun je dan wel zelf zien en in de hand houden wat er met de server gebeurt.

Wel vereist dit uiteraard de bijbehorende expertise en aandacht (tijd), als je die niet hebt is shared hosting beter en
moet je gewoon niet te veel niet-standaard spul installeren zodat zij het goed kunnen updaten zonder jouw spullen
ongewild stuk te maken.

Het ligt voornamelijk aan zijn S.L.A en of het een Managed Hosting Provider is.

Een managed hosting provider behoort dit te doen al wel altijd in overleg met de klant maar de provider heeft feitelijk het laatste woord als het op veiligheid kwestie aankomt van de in beheer genomen server omgeving. Dat levert nog wel eens discussie op maar het hoort eenmaal bij de geleverde dienst of de klant kan ervoor kiezen het contract op te zeggen.
Voor Wordpress wordt daarbij meestal een beheer dashboard gebruikt als ManageWP, InfiniteWP, MainWP en in mindere mate Jetpack. Hieruit kun je ook dagelijkse, wekelijkse en maandelijkse rapportages draaien met gedetaileerd log wat er gedaan is. Je betaalt hier echter wel natuurlijk meer voor dan je basis hosting.

De budget hosters daarin tegen de unmanaged providers waar de meeste eenpitters mkb en hobbyisten gebruik van maken hebben vaak de meer basis tools als installatron voor auto deploy erin staan. Hoewel lekker makkelijk zijn dit soort basis tools zelden aan te raden in maatwerk omgevingen. Prima te doen als je standaard plug-ins gebruikt en thema uit de wordpress store maar moment dat je iets custom doet aan scripting levert het meer gezeik op dan het waard is.
Echter enorm populair door het gemak waar het mee kan en dat het automatisch updates doorvoert.

Maar je wilt eigenlijk simpelweg *niet* dat alle updates automatisch gebeuren maar dat dit gecontroleerd gebeurd.
Er zijn op dit moment 3 niveau's van update rotatie in te stellen op wordpress zelf daar heb je geen control panel voor nodig.
allow_dev_auto_core_updates (test builds)
allow_minor_auto_core_updates (default bijv 5.1 naar 5.1.2 of 5.2 naar 5.3)
allow_major_auto_core_updates (versie jumps bijv. 5.0 naar 6.0)

Maar nu komt het warrige Wordpress update maar standaard sommige plugins middels een API respons.
Welke dat echter zijn dat weet je niet dat wordt bepaald door de Wordpress security team en daarvoor hebben ze dan weer filters gemaakt waar je gebuik van kan maken zoals add_filter( 'auto_update_plugin', '__return_true' );
Dus als je je afvroeg waarom je plugins nooit autoupdaten terwijl je toch echt automatische updates aan hebt in Wordpress dan is het ontbreken van een filter waarschijnlijk de oorzaak.

Kinsta heeft een goed artikel hierover destijds gemaakt scheelt je door de warrige informatie van Wordpress zelf bladeren.
https://kinsta.com/blog/wordpress-automatic-updates/


Je kan scanning buiten de reguliere extensies aanzetten moet je even door je instellingen scrollen alsmede custom paths opgeven. Let wel dit kost meer geheugen op je server dus pas indien nodig je limiet erop aan.
Injectie via afbeelding houd WF dan ook gewoon tegen mits je het configureert.

Het is de meest gebruikte aanvals vector om injectie te doen op xmlrpc.php na. Meestal binnen komend via wp-content/themes vaak vermomd als emoticons of background afbeelding in de img of assets folder van je respectievelijke thema. Vaak kun je dit soort ongein herkennen door via een dienst als sucuri scan te doen https://sitecheck.sucuri.net/
Vind je dan iets dan kun je mits je toegang hebt tot console een grep actie doen zoals onderstaand om verder te filteren op verdachte bestanden.
grep -Erl '[[:alnum:]/+]{20,}' /folderpadhier/*

Het is vaak raadzaam om naast WF ook zelf de controle te doen want WF ziet ook niet altijd alles.

Ok dus het gaat om een thema plugin, addon en niet een function toegevoegd aan het thema in de theme editor zoals functions.php? Meestal komt dit door dat een update van het onderdeel niet goed lukt en daardoor de plugin eruit valt.

Twee bekende gevallen waar wij regelmatig mee te maken hebben zijn bijvoorbeeld WPML en Visual Composer. Specifiek heeft dat met die twee te maken dat ze een license verificatie doen bij het updaten. De plugin wordt uitgeschakeld voor het vervangen en als dan de connectie naar license service mislukt stopt de update en de oude kan niet terug gezet worden omdat bestands integriteit niet te controleren is. Je raakt geen data kwijt die staat nog in de database maar de plugin moet je wel helaas zelf weer ophalen of je license heractiveren. Of dat in jouw specifieke geval ook is gebeurd is natuurlijk niet te zeggen maar je zou kunnen onderzoeken hoe de update van de addons geregeld is bij je theme developer.

Wat ook kan gebeuren is dat de theme developer besluit standaard functies uit te zetten of te verwijderen. Meestal zie je dan deprecated function staan in je theme option selectie maar het komt soms voor dat ze een functie samenvoegen en dat je shortcodes niet automatisch worden bijgewerkt. Dit soort aanpassingen worden echter meestal wel maanden van te voren verkondigd en in fase doorgevoerd.

Voorbeeldje we hadden bij een theme een additionele plugin om de wysiwyg editor te activeren maar dat is later in de core opgenomen waardoor de plugin waardeloos werdt. Probleem alleen was wel dat andere plug-ins niet allemaal netjes daar rekening mee hielden en daardoor de functie ook wegviel en we terug zaten te staren naar de afgrijselijke Gutenberg interface.


Twee mogelijke scenarios die ik me zo kan bedenken omtrent je situatie.
Ik zie voor alsnog geen enige indicatie dat je provider iets met de situatie te maken heeft ik kan het niet uitsluiten maar het lijkt niet waarschijnlijk.

Dat ze mooi met hun tengels van mijn dozen afblijven. Hoe kunnen die nou weten wat ik allemaal custom heb geconfigd etc?

Iemand die niet in staat is z'n dozen te onderhouden, verdient een botnet met de daaraan verbonden consequenties die in de voorwaarden staan.

Ja dat is de houding van de zelfverklaarde IT deskundige hobbyist, dat weten we.
Die kan de oplossing kiezen die ik daarboven al noemde (VPS met eigen beheer).

Maar voor de gewone man die een interactieve website wil hebben zonder meteen in de diepte in de techniek
te moeten duiken is zo'n managed oplossing echt de beste keuze hoor. Die moet zich dan hooguit inhouden bij
het installeren van wilde extra's van her en der (wat toch al verstandig is in dit soort PHP CMS omgevingen!).

Klopt en mooiste is het technische stukje is maar een taartpunt van het geheel wat beheerd *moet* worden.

Klopt de WHOIS informatie administratief, houder, technisch contact en KVK informatie gekoppeld aan het domein.
Is er een abuse mail adres of DPO, FG verkondigd voor afwikkeling van klachten en is het domein aangesloten bij overkoepelende monitoring platforms alsmede een klacht verwerking procedure.
Zijn alle media en teksten op de infrastructuur vrij van copyright of is er een licentie beschikbaar en is er een procedure tot bezwaar.
Worden de logs conform de wetgeving bewaard en kloppen alle verwerkings overeenkomsten alsmede kan data conform GDPR verwijderd of aangepast worden.
Is er een procedure bij datalek infrastructuur uitval en of aanval.

Als sitebeheerder ben je spreekwoordelijk de burgemeester, politie, brandweer, ambulance van je eigen digitale stad. Als hosting provider of server beheerder is dat eerder een land of continent qua grote en ben je ook meteen het leger.
En de meeste mensen kunnen simpelweg helaas die verantwoordelijkheid niet aan of erger nog weten niet dat het hun verantwoordelijkheid is in te first place.

"Na vandaag in te loggen en door mijn website te gaan, zie ik dat 1 van de Wordpress Thema Modules is verdwenen. Dit kan een bug zijn, het kan hacking zijn. "

Een hacker doet altijd iets wat in zijn voordeel is: wat is het voordeel van een hacker om op een site een thema te verwijderen?
Die kun je dus uitsluiten als oorzaak.

Het kan een bug zijn.
Het kan een opruimtaak zijn (cron) van wordpress zelf, of iets wat vanuit je provider meedraait.
Het kan een bewuste actie vanuit de hostingprovider zijn die een bepaalde kwetsbaarheid weghaalt (e.g. patchman).
Het kan een stomme klikfout zijn de vorige keer dat je zelf door het panel liep en even niet doorhad.
Het kan een processing error zijn, een f5 en het staat er ineens wel weer.

Als je inlogt op disk kun je vaak nog zien of de bestanden er wel staan: zijn die er nog?

Na bijna 20 posts weten we nog steeds niet welke theme er verwijderd is.
Misschien ook niet geheel onbelangrijk in het verhaal?

is het een theme via WordPress zelf, of een door de user geïnstalleerde 3rd party versie?

vragen.. vragen... ;)

beste weg wordpress verwijderen en degelijk cms installeren