PHP tag afsluiten

[KingFox]

Goeiemiddag!

Ik heb een klein probleempje. Op m'n Raspberry Pi draai ik Apache, PHP, MySQL.

Probleem is: ik heb ondervonden dat m'n scripts waarbij ik de PHP-tag niet afsluit voor problemen zorgen. Bij m'n eigen scripts viel dat mee om een ?> toe te voegen op het eind van de pagina (en dan werkt het gewoon!). Momenteel heb ik bij phpMyAdmin identiek hetzelfde probleem.

Momenteel krijg ik als error:

Parse error: syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE) in /media/3430-045F/apache/htdocs/phpmyadmin/setup/frames/menu.inc.php on line 29

Ik refresh 100 keer, probeer andere browser, andere PC zelfs... Ik upload het hele pakket opnieuw, noppes. Voeg ik aan de file op het einde "?>" toe, refresh de pagina, het werkt.

Iemand enig idee waar het mis gaat? Ik heb echt geen zin om in elk groot softwarepakket (waar m'n zo lui is om ?> toe te voegen) deze manueel te gaan toevoegen. Ik vermoed ook dat het aan een soort instelling ligt ofzo, want op webhostingpakketten heb ik problemen als deze nooit aan de hand.

[AW_Bos]

over welke versie van PHP hebben we het?

[KingFox]

PHP 5.4.4-14
Zend Engine v2.4.0

[Pin0]

De php sluit tag is niet verplicht. En in sommige gevallen zelfs af te raden omdat de webserver ook alles parsed wat na de sluittag komt. Dit kan vervelende regeleinden ed. tot gevolg hebben. Zie punt 2.2 van deze link: http://www.php-fig.org/psr/psr-2/

[Ypho]

Kun je eens kijken wat er op regel 29 van menu.inc.php staat? Als ik in GitHub kijk (linkje) heeft het bestand maar 28 regels. Wellicht is regel 29 in jouw bestand leeg. Probeer de witruimte aan het einde van het bestand eens te verwijderen, kijken wat ie dan doet...

[P.O. Box]

KingFox schreef op donderdag 30 januari 2014 @ 12:20:
emand enig idee waar het mis gaat? Ik heb echt geen zin om in elk groot softwarepakket (waar m'n zo lui is om ?> toe te voegen) deze manueel te gaan toevoegen. Ik vermoed ook dat het aan een soort instelling ligt ofzo, want op webhostingpakketten heb ik problemen als deze nooit aan de hand.

dat is niet lui, dat is bewust...

ik zie dat het om een menu.inc.php file gaat... m.a.w. deze file wordt geinclude vanuit een ander php-script... tsja, als je dan je tag niet afsluit, dan kun je een probleem hebben als er na de include nog van alles gebeurd.... het lijkt me echter sterk dat grote pakketten dat ook hebben....

[pderaaij]

Ik kan mij herinneren dat ik iets vergelijkbaars heb gehad in het verleden. Volgens mij bleef hij toen hangen op een BOM (byte-order-mark) die toegevoegd is aan het bestand. Door middel van een php configuratie heb ik dit probleem verholpen.

Ik ben nu niet in de gelegenheid om te zoeken, maar wellicht helpt dit je iets op weg.

[KingFox]

Ypho schreef op donderdag 30 januari 2014 @ 12:31:
Kun je eens kijken wat er op regel 29 van menu.inc.php staat? Als ik in GitHub kijk (linkje) heeft het bestand maar 28 regels. Wellicht is regel 29 in jouw bestand leeg. Probeer de witruimte aan het einde van het bestand eens te verwijderen, kijken wat ie dan doet...

Da's een witruimte gewoon een entertje.

Goh, ik vind het ook allemaal vreemd, en ik had ook gelezen over het al dan niet afsluiten van de php-tag. Maar het is vreemd dat er in de phpMyAdmin-download iets mis is. Het wijst dus op een lokaal probleem bij mij.

Nu krijg ik bijvoorbeeld een andere error:

Parse error: syntax error, unexpected '', expecting ')' in /media/3430-045F/apache/htdocs/phpmyadmin/libraries/Scripts.class.php on line 249

Lijn 249 is gewoon een lege lijn onder een " } ", ik snap die fout gewoon niet...

Ik denk/vrees dat het iets met karakters te maken heeft? Maar ik ken er zelf niks van om zomaar wat te klooien, ik heb geen flauw idee waar ik zou moeten zoeken. Op Google vind ik ook niet echt iemand met een vergelijkbaar probleem (Ofwel zijn mijn Google-skills zwak )

Edit: na wat aanpassen krijg ik nu deze error:

Parse error: syntax error, unexpected 'oude' (T_STRING) in /media/3430-045F/apache/htdocs/phpmyadmin/libraries/plugins/auth/AuthenticationCookie.class.php on line 801

Maar als je kijkt, op lijn 801 staat helemaal geen 'oude'


Herinstallatie van PHP hielp me ook niet echt verder.


2e Edit: Na elke " } " staat een enter, als ik die weg doe is het probleem ook opgelost en werkt de code. Iemand enig idee welke setting dat is in php.ini dat hij die "enters" moet negeren?

[ Voor 18% gewijzigd door KingFox op 30-01-2014 17:26 ]

[Cartman!]

KingFox schreef op donderdag 30 januari 2014 @ 12:20:
Ik heb echt geen zin om in elk groot softwarepakket (waar m'n zo lui is om ?> toe te voegen) deze manueel te gaan toevoegen.

Niet genoeg kennis hebben over het onderwerp en toch meteen de developers veroordelen Zoals gezegd is een sluit-tag toevoegen volledig overbodig en wordt het ook afgeraden dit te doen

pderaaij schreef op donderdag 30 januari 2014 @ 13:29:
Ik kan mij herinneren dat ik iets vergelijkbaars heb gehad in het verleden. Volgens mij bleef hij toen hangen op een BOM (byte-order-mark) die toegevoegd is aan het bestand. Door middel van een php configuratie heb ik dit probleem verholpen.

Ik ben nu niet in de gelegenheid om te zoeken, maar wellicht helpt dit je iets op weg.

Een BOM aan het eind van de file klinkt raar maar lijkt me wel iets wat het kan zijn. Open zo'n file eens met een HEX-editor om te controleren wat de laatste karakters echt zijn.

[dylanvana]

Compile php eens opnieuw en probeer ook andere versies zoals 5.3 of 5.5.

[NMe]

KingFox schreef op donderdag 30 januari 2014 @ 16:36:
[...]

Da's een witruimte gewoon een entertje.

Haal dat "gewoon een entertje" eens weg. Enters buiten PHP-tags geven altijd gezeik. Dat is ook de reden dat die sluittags er in de eerste instantie al niet stonden. Je doet er veel beter aan de originele code terug te nemen en in je settings in te stellen dat PHP geen sluittags nodig heeft.

dylanvana schreef op donderdag 30 januari 2014 @ 18:51:
Compile php eens opnieuw en probeer ook andere versies zoals 5.3 of 5.5.

Lijkt me niet bepaald makkelijker dan de settings goedzetten.

De fout hier wordt gewoon veroorzaakt door een syntaxdingetje. Dat is met een andere PHP-versie echt niet opgelost.

[ Voor 29% gewijzigd door NMe op 30-01-2014 18:58 ]

[dylanvana]

Php compilen is niet moeilijk.

Met een default php installatie moet phpmyadmin gewoon werken.

[KingFox]

NMe schreef op donderdag 30 januari 2014 @ 18:57:
[...]

Haal dat "gewoon een entertje" eens weg. Enters buiten PHP-tags geven altijd gezeik. Dat is ook de reden dat die sluittags er in de eerste instantie al niet stonden. Je doet er veel beter aan de originele code terug te nemen en in je settings in te stellen dat PHP geen sluittags nodig heeft.

[...]

Lijkt me niet bepaald makkelijker dan de settings goedzetten.

De fout hier wordt gewoon veroorzaakt door een syntaxdingetje. Dat is met een andere PHP-versie echt niet opgelost.

Dat ene entertje weghalen werkt, maar zo moet ik op 10000 files dat gaan wegdoen...

Parse error: syntax error, unexpected 'not' (T_STRING) in /media/3430-045F/apache/htdocs/phpmyadmin/libraries/Types.class.php on line 987

Maar op die file staat potverdorie geen 'not', en zeker niet op die regel, die is leeg, ik snap het echt niet. Het is gewoon dat entertje onderaan elke pagina, maar ik snap het totaal niet. Hexeditor toont niks bijzonders.

Over dat compilen: hoe moet dat juist vanuit SSH?

[Joolee]

Klinkt eigenlijk alsof er tussen download en gebruik iets met de file encoding gebeurt. Download eens zo'n bestand terug van je pi en open hem in Notepad++. Die laat in het encoding menu zien wat de huidige encoding is. In het edit menu kun je zien welke line endings (eol) er worden toegepast. Goede kans dat wanneer je het bestand bewerkt (enter weghalen of end tag toevoegen) de encoding wordt gefixt. Hoe upload en bewerk je de bestanden eigenlijk?

[NMe]

Luister asjeblieft niet naar dat opnieuw compilen, dat gaat je niet meer helpen dan die ene setting goed zetten. Het probleem dat je hebt komt omdat je zelf zit te hacken om een wijziging te maken die in de eerste instantie al niet verstandig is. Zie ook het accepted answer hier voor een goeie uiteenzetting waarom die closing tag niet handig is.

Revert je code zodat je die closing tags niet meer hebt. Pas de setting aan die closing tags verplicht (als die überhaupt bestaat). Ga niet PHP opnieuw compilen totdat je zeker weet dat je het niet in je configuratiefile kan oplossen, en ga zeker niet PHP opnieuw compileren om deze syntaxfouten op te lossen, want die lost dat niet op.

[dylanvana]

Je kan er omheen lullen zoals je wilt maar een standaard php installatie moet phpmyadmin gewoon draaien. Ik zie ook niet hoe je erbij komt dat de topic starter "hacks" heeft toegepast op zijn pi.

Hoe heb je apache, mysql en php geinstalleerd? (Linux right?)

[KingFox]

Oorspronkelijke file: UTF-8 (zonder BOM)
Gedownloade file: UTF-8 (zonder BOM), niks toegevoegd ook.

Ik heb dit gevolgd:
http://www.howtoforge.com...port-on-ubuntu-11.04-lamp ,maar dan uitgevoerd op Raspbmc Zou geen probleem mogen maken lijkt me? Of ben ik hier echt iets doms aan het doen?

Alé, ik heb wel eerder met php-mysql enz gewerkt, maar ben 'nieuw' in Linux. (Ben al blij dat het allemaal werkt )

[Gomez12]

Klint meer als een BOM of een foute overzetting van je bestand oid waardoor er rare dingen aan het einde van het bestand staan.

Andere mogelijkheid is dat je ergens in je webconfig iets hebt staan wat "automatisch" footers aan je html meegeeft en wat nu dus de footers toevoegt aan het einde van de file.

@NMe : Er is (afaik) niet een config-setting die bepaalt of closing tags wel/niet verplicht zijn, er zal vast een andere config-setting wel fout staan maar welke...

Wat ik zou doen is een vrij simpel stappenplan :
- Download een wamp/xampp en een phpmyadmin.
- Verifieer in die wamp / xampp of phpmyadmin werkt
- Dump die werkende phpmyadmin op je raspberry pi
- Verifieer of de md5's van alle gedumpte bestanden gelijk zijn zijn deze niet gelijk zoek dan een tutorial hoe je bestanden op je pi moet zetten
- Verifieer of die phpmyadmin werkt.
- Zoniet vergelijk raspberry pi php-settings met je wamp/xampp php-settings

Vervang phpmyadmin in het bovenstaande stappenplan aub wel door een veel simpeler voorbeeld wat nu fout gaat (bijv 1 pagina die hello world schrijft)

@dylanvana : Compileren levert juist bijna nooit een "standaard php-installatie" op, want je blijft met dezelfde config file zitten en wellicht niewere library's, andere compile opties etc. etc. Met compileren maak je de bende enkel maar groter omdat je nog een onbekende variabele gaat introduceren.
Compileren bij bugs uitzoeken is 1 grote no-no

[dylanvana]

Wat ik concludeer is dat de installatie fout is gegaan. Meest logische is dan ook opnieuw installeren Dat is anders dan bugs uitzoeken. Anders hadden we allemaal wel dit probleem met phpmyadmin.

[KingFox]

Het ligt niet aan phpmyadmin, mijn eigen code had hetzelfde probleem het zijn die enters onderaan een file... Ben aan het proberen maar ik vind geen enkele manier om in SSH een MD5 te maken van die file.

Maar in ieder geval, het ligt gewoon niet aan files, het ligt aan enters. PHP herinstalleren heb ik al getest, maar kzal het nog maar is proberen.

In ieder geval bedankt voor de hulp, ik krijg er kop noch staart aan waar het fout gaat. Dit is volgens mij één van de meest frustrerende problemen die ik ooit heb gehad, ik raak er ook gewoon niet uit.

Herinstallatie werkt ook niet ik begin het echt wel serieus beu te raken. Waarom doen die enters zo lastig

[ Voor 9% gewijzigd door KingFox op 30-01-2014 21:06 ]

[Gomez12]

Bugs kunnen ook gewoon in config-files zitten en dan heb je opnieuw gecompiled en werk je met dezelfde config-file en heb je het nog steeds, alleen werken nu op andere gebieden opeens dingen ook niet meer omdat je bijv de optie voor gd-libs bent vergeten (of de mysql-libs of ...) en dan komt hij hier weer en dan geef jij weer dat advies en ondertussen heeft hij andere libs op zijn systeem gezet (voor andere progs) en krijgt hij weer een andere versie.

@KingFox : MD5 stap kan je anders ook overslaan en direct de config-files vergelijken tussen de wamp en je pi, daar zit >90% zeker de fout in

[TommieW]

Zou je niet kunnen proberen om helemaal opnieuw te beginnen? Dus opnieuw Debian downloaden, op een SD kaartje zetten, enzovoorts.
Ik begrijp helemaal dat dit een verschrikkelijk tijdrovende klus is, maar je hebt wel een grote kans dat het werkt.
Ik heb ook een Raspberry Pi draaien met Apache, PHP en MySQL, en het werkt allemaal naar behoren. Het is dus wel mogelijk.

[drm]

Staat APC aan? Of een andere bytecode cache? Zo ja, zet die eens uit. Parset de CLI de files wel goed? Is het probleem verholpen met een tussentijdse restart van Apache?

[Cartman!]

Upload je toevallig in ASCII mode ipv binary mode? Dat kan ook behoorlijk je newlines opfokken.

[KingFox]

Upload is via autodetectie (FileZilla), UTF8 dus normaal.

Goh, over APC ofzo: geen echt idee, die termen klinken Chinees voor mij Ik begin meer te voelen voor een schone installatie van m'n Raspberry Pi en het dan te testen. Ik geraak er totaal niet meer aan uit en ben het zoeken naar fouten als deze (waarvan de oorzaak God weet waar ligt), hopelijk raakt het opgelost.

Ik heb ooit iets gelijkaardigs voorgehad binne XAMPP, werd veroorzaakt door files aan te passen in MacOSX en die op een Windows XAMPP te zetten. Maar 'k heb nooit gezocht naar die fout, omwille van dezelfde reden.

*Zucht* ik zie wel op tegen al dat werk, maar volgens mij kan het gewoon niet anders. Hier kan ik eindeloos tijd blijven in steken...

[Cartman!]

Autodetectie uitzetten en binary uploaden.

[Gomez12]

KingFox schreef op donderdag 30 januari 2014 @ 21:53:
Upload is via autodetectie (FileZilla), UTF8 dus normaal.

Ok, je hebt een probleem lijkt het je dan niet handig om eens autodetectie uit te zetten? (alhoewel autodetectie voornamelijk gaat over binary of niet, niet over encodings)

Ik heb ooit iets gelijkaardigs voorgehad binne XAMPP, werd veroorzaakt door files aan te passen in MacOSX en die op een Windows XAMPP te zetten. Maar 'k heb nooit gezocht naar die fout, omwille van dezelfde reden.

Ik vermoed ook dat het exact dezelfde fout is (je line-endings / enters zijn anders in MacOSX / Linux en Windows) alleen dat moet gewoon in je php config file staan wat je mogelijke line-endings zijn (of heb je toevallig al jarenlang een wamp install draaien op je desktop en heb je nu blind die config file overgekopieerd, want dan is er een kans dat je x jaar geleden je config-file windows only line-endings hebt laten lezen (geeft geen probleem op windows))

[drm]

Line endings zijn gewoon whitespace. Dat maakt niks uit. De opmerking dat de parse error optreedt met woorden die niet bestaan doet sterk denken aan een APC bug.

[KingFox]

drm schreef op vrijdag 31 januari 2014 @ 00:06:
Line endings zijn gewoon whitespace. Dat maakt niks uit. De opmerking dat de parse error optreedt met woorden die niet bestaan doet sterk denken aan een APC bug.

En hoe valt een APC bug op te lossen? Ik heb gelezen dat het te maken heeft met cache, maar niet echt wat het kan helpen in mijn geval.

[Cartman!]

Probeer eerst eens of het uploaden verschil geeft en of je uberhaupt wel APC cache draait.

[KingFox]

Oké, ik heb eventjes iets ontdekt.

Mijn websites staan op het pad "/media/3430-045F/apache/htdocs/phpmyadmin/", wat dus verwijst naar mijn externe schijf. Die is geformatteerd in het exfat formaat.

Ik heb in Apache mijn pad gezet naar de /var/www folder, phpMyAdmin naar daar geüpload, getest en het werkt perfect.

Het gaat dus precies mis door het feit dat ik gebruik maak van mijn externe schijf. Iemand die weet wat daarvan de oorzaak kan zijn? De aanpassingen ivm de verwijzing doe ik enkel in etc/apache2/sites-available.

Zoals ik reeds eerder aanhaalde: ooit heb ik een gelijkaardig probleem gehad in een ietwat gelijke situatie. Ik werk vanop Mac op Windows, opeens vreemde fouten (zoals deze), die vielen ook gewoon niet op te lossen. Op die Windows draaide een gewone XAMPP installatie. Nooit heb ik de oorzaak gevonden, ben gewoon gestopt met vanop m'n Mac op Windows te werken (maar da's uiteraard geen oplossing.)

Momenteel stelt het probleem zich ook vanop Windows naar Linux en MacOS naar Linux. Alé, meerbepaald: naar m'n externe schijf. Maar kan het daaraan liggen, en hoe valt zoiets op te lossen?

EDIT: Apache terug aangepast naar pad op m'n externe hdd, hetzelfde probleem opnieuw, vreemde en onmogelijke errors, ook als ik het test met andere folders op externe HDD. Op m'n SD-kaartje zelf (Raspberry Pi) loopt het als een zonnetje. Het zou geen drama zijn moest ik mijn scriptjes op m'n SD-kaartje zetten, maar mocht het werken op m'n externe hdd, dat zou wel fijn zijn.

[ Voor 13% gewijzigd door KingFox op 01-02-2014 12:59 ]

[drm]

Ah, dat is ook een mooie verklaring. Ik zou naar een native filesystem migreren, veel veiliger en stabieler.

[Verwijderd]

Ik kwam laatst ook zoiets dergelijks tegen. Op php 5.3 deed dezelfde file het gewoon prima, maar op php 5.4 ging de compiler over zn nek door een enter voor de openingstag.