Foutmelding website

[Jordyz]

Goedenavond,

Ik beheer voor iemand een website en heb nu al een week last van deze foutmelding.

Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in public_html/wp-content/plugins/googleanalytics/class/Ga_Admin.php on line 480

Dit is een foutmelding die is gekomen na het updaten van een Wordpress plugin. Ik kan ook niet meer op de admin omgeving terecht komen.

Als ik naar het Ga_Admin.php ga en regel 480 bestaat deze niet. Ik kan maar geen oplossing vinden voor dit probleem. Mocht iemand hier iets weten over hoe ik dit kan oplossen? Dan zou dat het heel fijn zijn!

Via Teamviewer meekijken in Filazilla is ook geen probleem.
Eventueel tegen een vergoeding.

Alvast bedankt!

Met vriendelijke groet,
Jordy

[ Voor 1% gewijzigd door RobIII op 28-12-2016 18:24 . Reden: Error-melding quote gefixed ]

[Amelandbor]

Altijd even kijken in de support forums van de desbetreffende plugin.

https://wordpress.org/sup...after-analytics-update-2/

[sypie]

Open PHPMyAdmin, zoek in de database waar de plugins-settings staan, zoals het feit of ze actief zijn of niet. En pas dit aan voor de betreffende plugin: deze moet op niet-actief gezet worden. Daarna kun je alles weer lekker updaten en op zoek naar waarom de plugin het niet meer doet.

[Jordyz]

Amelandbor schreef op woensdag 28 december 2016 @ 18:13:
Altijd even kijken in de support forums van de desbetreffende plugin.

https://wordpress.org/sup...after-analytics-update-2/

Bedankt!

Inmiddels de plugin verwijderd maar geen resultaat.

[Jordyz]

sypie schreef op woensdag 28 december 2016 @ 18:16:
Open PHPMyAdmin, zoek in de database waar de plugins-settings staan, zoals het feit of ze actief zijn of niet. En pas dit aan voor de betreffende plugin: deze moet op niet-actief gezet worden. Daarna kun je alles weer lekker updaten en op zoek naar waarom de plugin het niet meer doet.

Ik kan ook niet in PHPMyadmin komen..

[RobIII]

Al eens gezocht op T_PAAMAYIM_NEKUDOTAYIM? Kijk daarna eens in Ga_Admin.php of je ergens kunt vinden waar dat zich precies voordoet ;-)

Verder lijkt me hier (aangehaald door Amelandbor in "Foutmelding website") de juiste oplossing te staan.

Jordyz schreef op woensdag 28 december 2016 @ 18:22:

Inmiddels de plugin verwijderd maar geen resultaat.

Definieer "verwijderd". Hoe dan precies?

Ook lijkt 't me stug dat je alles al geprobeerd hebt wat hier beschreven is; en als dat wél zo is: waarom heb je dat niet vermeld in je topicstart of je posts erna?

[ Voor 71% gewijzigd door RobIII op 28-12-2016 18:30 ]

[Jordyz]

RobIII schreef op woensdag 28 december 2016 @ 18:26:
Al eens gezocht op T_PAAMAYIM_NEKUDOTAYIM? Kijk daarna eens in Ga_Admin.php of je ergens kunt vinden waar dat zich precies voordoet ;-)

Verder lijkt me hier (aangehaald door Amelandbor in "Foutmelding website") de juiste oplossing te staan.


[...]

Definieer "verwijderd". Hoe dan precies?

Ook lijkt 't me stug dat je alles al geprobeerd hebt wat hier beschreven is; en als dat wél zo is: waarom heb je dat niet vermeld in je topicstart of je posts erna?

Heb ik al eerder gedaan, toch bedankt..

Op een of andere manier werken alle oplossingen niet. Het is heel vreemd en ik snap er echt niks meer van hoe dit kan.

Ik heb de plugin verwijderd met Filazilla uit de map waar alle plugins staan. Ik ben er al een dikke week mee bezig met allerlei gegoogle maar ik kom er niet uit. De oplossingen die ik telkens gevonden heb werken niet en de site blijft deze error maar houden. Oplossingen had ik misschien beter in de starterpost kunnen plaatsen.

[ Voor 14% gewijzigd door Jordyz op 28-12-2016 18:35 ]

[RobIII]

...maar nog steeds weten we niet welke PHP versie je draait...

[NMe]

Jordyz schreef op woensdag 28 december 2016 @ 18:33:
[...]

Heb ik al eerder gedaan, toch bedankt..

Waarom zeg je dat dan niet? Waarom moeten we in dit topic tandentrekken voor de info die we nodig hebben?

[Jordyz]

NMe schreef op woensdag 28 december 2016 @ 19:04:
[...]

Waarom zeg je dat dan niet? Waarom moeten we in dit topic tandentrekken voor de info die we nodig hebben?

Nee uiteraard niet, is mijn fout geweest en te snel willen posten.
Omdat ik de post niet meer kan aanpassen zet ik het maar even in een reactie.

Ik kan niet op Phpmyadmin komen, dan krijg ik dezelfde foutmelding. Na mijn idee krijg je dit bij alle linkjes.
De plugin verwijderen heb ik al een keer geprobeerd, dit is gebeurd via Filazilla. Maar de foutmelding blijf bestaan.

Via Google ben ik erachter gekomen dat op regel 480 een '''::'' te veel staat, alleen deze regel bestaat helemaal niet in Ga_Admin.php.

Ik heb geen idee welke PHP versie de website draait, is een website voor mijn ouders en heeft eigenlijk altijd prima gedraaid. Pas na het updaten van de plugin krijg ik deze melding. Indien het nodig is om de PHP versie te weten dan kan ik dit opvragen bij mijn hoster.

Allemaal bedankt voor het meedenken alvast!

[ Voor 51% gewijzigd door Jordyz op 28-12-2016 19:46 ]

[Amelandbor]

Laat eens een screenshotje zien van Filezilla in de wp-content/plugins map. Als die plugin echt verwijderd is moet dit toch echt niet meer kunnen.

[b2vjfvj75gjx7]

In PHP, the scope resolution operator is also called Paamayim Nekudotayim (Hebrew: פעמיים נקודתיים), which means “double colon” in Hebrew.

The name "Paamayim Nekudotayim" was introduced in the Israeli-developed Zend Engine 0.5 used in PHP 3. Although it has been confusing to many developers who do not speak Hebrew, it is still being used in PHP 5, as in this sample error message:

$ php -r :: Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM

As of PHP 5.4, error messages concerning the scope resolution operator still include this name, but have clarified its meaning somewhat:

$ php -r :: Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM)

[DJMaze]

Jordyz schreef op woensdag 28 december 2016 @ 19:41:
Ik kan niet op Phpmyadmin komen, dan krijg ik dezelfde foutmelding.

Ik heb zo het gevoel dat je bij god niet weet wat het allemaal betekend wat wij zeggen.
Phpmyadmin kan namelijk helemaal niet de zelfde error geven.
Misschien tijd om eens een ontwikkelaar wat euro's toe te schuiven?

[Verwijderd]

Wat heeft PHPMyadmin hier nou allemaal mee te maken

Hij update een plugin, en wordt vervolgens geconfronteerd met een PHP foutmelding.

Het eerste wat je doet is het uitschakelen van de plugin. Als de site hierdoor crashed is dat geen ramp, ga gewoon met een file manager naar de map

code:

/wp-content/plugins/

en hernoem de volgende map

code:

googleanalytics

naar

code:

googleanalytics1

om te voorkomen dat wordpress de plugin verder laadt. Als het goed is is de foutmelding nu verdwenen. De google analytics plugin is nu uitgeschakeld en staat vermoedelijk op niet actief in /plugins onder /wp-admin/. Het komt vaak voor dat net voor een major release van wordpress (4.7) plugins worden geupdate en men er bij de plugin al vanuit gaat dat het direct op 4.7 gezet wordt, terwijl veel sites met een nog oudere versie van wordpress draaien.

Ik snap zowiezo niet waarom je een plugin voor analytics wilt, terwijl je in /wp-content/themes/huidgetheme/header.php voor </head> gewoon de analytics code kunt plakken. Het voordeel is dat je zo minder resources loopt te stoken op een server (want hij haalt het iedere keer uit de database nu) en het aantal plugins ook veel kleiner blijven.

[Douweegbertje]

DJMaze schreef op donderdag 29 december 2016 @ 01:37:
[...]

Ik heb zo het gevoel dat je bij god niet weet wat het allemaal betekend wat wij zeggen.
Phpmyadmin kan namelijk helemaal niet de zelfde error geven.
Misschien tijd om eens een ontwikkelaar wat euro's toe te schuiven?

Of je doet gewoon niet zo arrogant met je eerste zin, om vervolgens zelf de mist in de gaan met je tweede zin. Het is wel degelijk mogelijk dat phpmyadmin zo'n error geeft. Grote kans dat zijn server domweg zo'n phpmyadmin mapje naast zijn website heeft staan.

Alles hier wijst er gewoon op dat de host de PHP versie heeft veranderd waardoor -alles- niet meer werkt. Inclusief dus phpmyadmin. Zoals hij aangeeft heeft hij de plugin uitgezet en blijft de error bestaan.

Overigens wel iets subtieler aan de topicstarter: het lijkt mij handig dat je er iemand naar laat kijken die iets ruimere ervaring heeft. Dit geval is niet zomaar op te lossen, vooral niet als er gewoon even veel uitgezocht moet worden.

Verwijderd schreef op donderdag 29 december 2016 @ 01:42:

Ik snap zowiezo niet waarom je een plugin voor analytics wilt, terwijl je in /wp-content/themes/huidgetheme/header.php voor </head> gewoon de analytics code kunt plakken. Het voordeel is dat je zo minder resources loopt te stoken op een server (want hij haalt het iedere keer uit de database nu) en het aantal plugins ook veel kleiner blijven.

Of je zorgt gewoon voor caching, wat naar mijn mening standaard bij WP moet draaien om het enigszins fatsoenlijk te laten draaien. De template aanpassen is helemaal een no-go. Bij een theme update ben je de wijzingen kwijt. Eventueel kan je nog een child-theme doen, maar dat is dan een afweging die kunt maken.

Een plugin om dynamisch je GA in te zetten is niet gek. Caching is de oplossing die je wilt voor jouw probleem wat je nu aandraagt.

[ Voor 30% gewijzigd door Douweegbertje op 29-12-2016 01:48 ]

[Verwijderd]

Hoevaak wijzig je je GA nu daadwerkelijk? De minder plugins je meedraait, des te minder feeds er bij het openen van o.a wp-admin worden opgehaald. Des te minder queries er ook naar je DB gemaakt moeten worden iedere keer. Caching werkt maar dat hangt af van je server specs (shared, eigen server) en configuratie.

Wil je wordpress helemaal tot in de details hebben, dan moet je het op security na, zo minimaal mogelijk houden. Een thema update is niet zo'n ramp aangezien je met bestandseditor in wordpress zelf zo net voor de </head> tag de analytics code plaatst.

En thema's lopen niet geautomatiseerd. M.a.w zolang jij niet op update klikt gebeurd er ook niets.

Ik heb zowat 8 seconden van verschillende sites in laadtijd geschaafd door onnodige zooi er gewoon uit strippen, en dat men prima kan updaten, prima kan werken en berichten plaatsen. Een site die lekker snel laadt is goed voor pagespeed factor en het stoort mij mateloos om te moeten wachten op een trage wordpress site met een miljoen triljard plugins.

[ Voor 21% gewijzigd door Verwijderd op 29-12-2016 01:55 ]

[DJMaze]

Douweegbertje schreef op donderdag 29 december 2016 @ 01:46:
Het is wel degelijk mogelijk dat phpmyadmin zo'n error geeft.

Ja natuurlijk kan phpmyadmin een "Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM" hebben, maar niet "in /wp-content/plugins/googleanalytics/class/Ga_Admin.php".

Hij zei toch echt

Jordyz schreef op woensdag 28 december 2016 @ 19:41:
Ik kan niet op Phpmyadmin komen, dan krijg ik dezelfde foutmelding.

Douweegbertje schreef op donderdag 29 december 2016 @ 01:46:
Alles hier wijst er gewoon op dat de host de PHP versie heeft veranderd waardoor -alles- niet meer werkt. Inclusief dus phpmyadmin.

Natuurlijk niet. Als je even in dat bestand had gekeken van versie 2.0.0 dan staat daar

PHP:

$class::$action();

Tja, iets met PHP 5.3

[Douweegbertje]

In elk geval goed mogelijk dat hij gewoon naar site.nl/phpmyadmin gaat en dat hij dan normaal de WP 404 pagina krijgt

Hoe dan ook handig dat er iemand met meer ervaring naar kijkt, desalniettemin kan dat normaal gezegd worden, en dat was meer mijn punt.

[johnkeates]

Het kan ook dat het een cheap ass hosting pakketje is en de ISP een of andere PHP include meegeeft met daar in de fout. Maar eigenlijk zou het genoeg moeten zijn om gewoon een een grep -ri te doen om die dubbele dubbele punten te vinden.

[Verwijderd]

johnkeates schreef op donderdag 29 december 2016 @ 02:22:
Het kan ook dat het een cheap ass hosting pakketje is en de ISP een of andere PHP include meegeeft met daar in de fout. Maar eigenlijk zou het genoeg moeten zijn om gewoon een een grep -ri te doen om die dubbele dubbele punten te vinden.

Ik heb tientallen sites gehad die stukraakte na de update van verschillende plugins. Devs die plugins schrijven testen zulke dingen niet altijd of een update wel compatible is. Ze maken het bijv. werkbaar voor de nieuwste versie van wordpress, maar vergeten even voor het gemak dat er genoeg mensen met < 4.6 draaien. Een fout is zo gemaakt en ze willen vaak allemaal de snelste zijn.

De foutmelding kan je eenvoudig uitschakelen door de map van de plugin gewoon te hernoemen. Hiermee schakel je in de eerste instantie de plugin gewoon uit. Nu kan je verder kijken waarom dit gebeurd.

Ik zou heel die plugin gewoon eruit mieteren en GA in de header.php zetten van je thema. Als de melding nog komt na het verwijderen van de plugin (fysieke map) dan is het caching op de server, die ververs je met F5 of CTRL-F5, of desnoods even een minuutje wachten ofzo.

Maar science zijn dit soort dingen echt niet. Zelfs op PHP < 5.3 kan je prima wordpress draaien.

[johnkeates]

Verwijderd schreef op donderdag 29 december 2016 @ 02:29:
[...]dingen[...]

Ik zou zelf gewoon niet kiezen om wordpress te draaien, en al helemaal niet met random code die lukraak van internet geplukt wordt

Laten we kijken wat Jordyz er van maakt.

[ Voor 71% gewijzigd door johnkeates op 29-12-2016 02:36 ]

[Verwijderd]

johnkeates schreef op donderdag 29 december 2016 @ 02:36:
[...]


Ik zou zelf gewoon niet kiezen om wordpress te draaien, en al helemaal niet met random code die lukraak van internet geplukt wordt

Laten we kijken wat Jordyz er van maakt.

Ach ja het schept werk voor de wel specialisten onder ons

Punt is is dat wordpress tegenwoordig meer dan 40% van het internet bepaald. Dus je ontkomt er ook niet aan dat dit bijna zowat het meest gebruikte CMS is. Echter wordt er vaak slechte audit op code gedaan, en al helemaal bij het invoeren van een toekomstige update.

Omdat alles open source is, kan jij, ik en iedereen technisch in elke code van elke plugin of thema kijken, en checken wat wel en niet onveilig is, en dit botvieren op een miljoen websites.

Ik ben met een honeypot momenteel bezig, gewoon een simpele statische pagina met daarop wp-login.php, en alle bruteforce logins gewoon lekker afvangen in een bestand. Heb ik binnen een maand een enorme lijst aan potentieele user / pass combi's

Het is onvoorstelbaar hoe zelfs blanco domeinnamen, gewoon tientallen 404's op maandbasis krijgen met bots die zoeken naar wp-login.php, /wp-admin-ajax.php en tientallen andere lekke thema's of plugins. Er komt een keer een omslagpunt dat wordpress wereldwijd zo enorm gepakt gaat worden qua hacks, en de halve wereld ineens meedoet in een botnet, dat de populariteit vanzelf wel weer daalt.

Mooi product hoor, om te bloggen that is, maar verschrikkelijk als website builder. Je hebt een beste server nodig wil je een fatsoenlijke wordpress site uberhaubt 'snel' en met 'veel' bezoekers kunnen hosten.

[Jordyz]

Iedereen super bedankt voor de reacties.
Ik ga er vanavond weer mee aan de slag, ik zal gelijk een aantal scrernshots posten.

[Jordyz]

Allen bedankt voor de reacties nogmaals!

Het was dus niet mijn fout waarom het maar niet lukte.

Blijkbaar is de hoster overgegaan naar een nieuwe omgeving. Gek genoeg heb ik geen nieuwe FTP gegevens ontvangen. De plugin kon niet overweg met de nieuwe PHP versie. Dus alles wat ik ging niet ''live''.

Toch bedankt, daarom werkte de oplossingen niet en daarom heb ik me een week lang suf moeten zoeken op Google zonder resultaat. Gelukkig heeft de hoster een uitstekende support afdeling.

Nogmaals bedankt voor het meedenken!

[Cartman!]

Verwijderd schreef op donderdag 29 december 2016 @ 02:29:
[...]
Maar science zijn dit soort dingen echt niet. Zelfs op PHP < 5.3 kan je prima wordpress draaien.

Dat moet je alleen niet willen want zelfs 5.3 is al een flinke tijd end of life.

[Jordyz]

Cartman! schreef op donderdag 29 december 2016 @ 19:02:
[...]

Dat moet je alleen niet willen want zelfs 5.3 is al een flinke tijd end of life.

Hij draait op versie 5.6.
Dus dat kon het probleem niet zijn.

[Cartman!]

Jordyz schreef op donderdag 29 december 2016 @ 19:38:
[...]
Hij draait op versie 5.6.
Dus dat kon het probleem niet zijn.

Ik reageerde dan ook op Jism die zegt dat e Wordpress prima op een antieke versie van PHP kunt draaien.

[Verwijderd]

Cartman! schreef op donderdag 29 december 2016 @ 19:02:
[...]

Dat moet je alleen niet willen want zelfs 5.3 is al een flinke tijd end of life.

Er zijn helaas nog een hoop websites op deze planeet die alleen op 5.3 werken en niet op 5.4 of hoger. Vaak uit kostenbesparing wordt zo'n site dan nauwelijks tot niet geupdate.

Maar er is hoop; je kunt gewoon met een PHP selector per gebruiker instellen welke PHP versie je moet draaien.

[Cartman!]

Verwijderd schreef op donderdag 29 december 2016 @ 21:02:
[...]
Er zijn helaas nog een hoop websites op deze planeet die alleen op 5.3 werken en niet op 5.4 of hoger. Vaak uit kostenbesparing wordt zo'n site dan nauwelijks tot niet geupdate.

Dat is gewoon enorm dom als dat een public facing website is. Blij dat ik gewoon 5.6 of 7 kan eisen

[Verwijderd]

Cartman! schreef op donderdag 29 december 2016 @ 21:35:
[...]

Dat is gewoon enorm dom als dat een public facing website is. Blij dat ik gewoon 5.6 of 7 kan eisen

Dat ligt eraan, als ie gewoon veilig is gescript gaat er niet zoveel mee mis. Maar als een site gehacked wordt kan de server erachter ook worden gehacked en dat is het risico van gebruik 5.3.

Tja en toegang tot een server.... gevolgen kunnen enorm zijn.

[Cartman!]

Verwijderd schreef op donderdag 29 december 2016 @ 22:53:
[...]


Dat ligt eraan, als ie gewoon veilig is gescript gaat er niet zoveel mee mis.

Wat is "veilig" scripten als er fouten in de onderliggende code zitten waar je niet vanaf wist toen je ze schreef? Ik las dat er dit jaar duizenden lekken waren waarbij data buit gemaakt is, het gebruiken van software die jaren geleden al end of life verklaard is helpt daar niet bij natuurlijk.

[Verwijderd]

Je moet kijken naar hoe hacks plaatsvinden, en of je website uberhaubt daar kwetsbaar voor is of niet. Het is niet alsof je nu een bak met PHP 5.3 gaat draaien meteen wordt gehacked. Absoluut niet. Maar al lukt het een hacker om een PHP bestand op je apache webserver te krijgen en deze van buitenaf uit te kunnen voeren dan is het een ander verhaal.

Hier staat een mooi voorbeeld over hoe 5.3 hier gehacked werd. Een exploit via /cgi-bin/ om hier een shell te downloaden en zo toegang te krijgen over de server bijv.

[Cartman!]

Ik snap niet waarom je software zou verdedigen waar de maker zelf een paar jaar geleden z'n handen al vanaf heeft getrokken. Het is gewoon niet slim het nog te gebruiken, moeilijker hoeven we t niet te maken.

[Verwijderd]

Je hebt gelijk hoor,

maar er zijn een hoop websites die het qua tijd, investeren en kostenplaatje gewoon niet waard zijn te herschrijven voor gebruik 5.6 of hoger.

[Cartman!]

Die komen zich vanzelf een keer tegen en dan zal goedkoop duurkoop zijn.