PHP + Curl + Htaccess

[skate master]

Mensen,

Onlangs hebben wij de website van onze vereniging ge-update en werkt deze geheel zonder fouten op PHP7.
Echter is er een onderdeel van de oude website wie tijdelijk weergegeven dient te worden binnen onze nieuwe website.

Het betreft hier een uitslagen en klassementen systeem wat door een van de leden in elkaar is gezet, echter nooit is bijgewerkt. Nu naar de update naar PHP7 blijkt dat dit script nog gebruik maakt deprecated functies voor MySQL.

Wij hadden idee om net zoals het eerder was via Curl het script aan te roepen en de juiste HTML tables eruit te filteren en weer te geven op de website. Echter loopt het script vast op de PHP versie.

Middels een htaccess bestand in de directory van het script lukt het om wanneer ik het script direct benader het resultaat te zien zonder de foutmeldingen. Echter wanneer ik een Curl aanroep doe naar het script lijkt het wel dat de htaccess genegeerd word, ik krijg dan een http 500 error. De URL in de Curl aanroep is goed, deze werkt middels een directe aanroep in de browser wel.

Zijn er mogelijkheden om Curl wel de htaccess te laten gebruiken?

Het script wordt aangepast naar PHP7, echter is het een vrij groot, gedateerd en niet gedocumenteerd systeem.
Veel werk dus om het om te zetten en de gebruiker wie het script gemaakt heeft wil er niets meer van weten.

Kortom: zijn er mogelijkheden om de standen via Curl op te halen en in de site te verwerken zonder dat ik de hele site op en lagere PHP versie moet laten draaien?

[Saven]

doe gewoon een find replace mysql_*( naar mysqli_*(

[ Voor 11% gewijzigd door Saven op 18-07-2017 15:08 ]

[kipppertje]

Kun je niet gewoon op de laatste versie van PHP 5.x.x blijven draaien?
PHP7 biedt nou niet echt zoveel voordelen dat het al deze moeite waard is...

[Onoffon]

Wat is de foutmelding die je krijgt zonder het .htaccess bestand?

[Spinal]

kipppertje schreef op dinsdag 18 juli 2017 @ 15:09:
Kun je niet gewoon op de laatste versie van PHP 5.x.x blijven draaien?
PHP7 biedt nou niet echt zoveel voordelen dat het al deze moeite waard is...

Meen je dit serieus? Niet alleen is de performance sterk verbeterd (scheelde bij ons zeker 40%), alleen al vanwege return type declarations en de null coalescing operator is het de moeite waard!

[kipppertje]

Spinal schreef op dinsdag 18 juli 2017 @ 16:20:
[...]

Meen je dit serieus? Niet alleen is de performance sterk verbeterd (scheelde bij ons zeker 40%), alleen al vanwege return type declarations en de null coalescing operator is het de moeite waard!

Begrijp me niet verkeerd, PHP7 is zeker een vooruitgang, alleen vraag ik me af of de lokale sportvereniging daar echt zoveel van gaat profiteren ten opzichte van de migratie problemen.

[dev10]

Saven schreef op dinsdag 18 juli 2017 @ 15:07:
doe gewoon een find replace mysql_*( naar mysqli_*(

Doe dat maar niet.

De mysql_* functies hebben wel een parameter voor een connectie, maar deze is optioneel en is de laatste paramater. Bij mysqli_* is de connectie verplicht en is dit de eerste parameter. Zie mysql_query vs. mysqli_query.

kipppertje schreef op dinsdag 18 juli 2017 @ 16:25:
[...]


Begrijp me niet verkeerd, PHP7 is zeker een vooruitgang, alleen vraag ik me af of de lokale sportvereniging daar echt zoveel van gaat profiteren ten opzichte van de migratie problemen.

Begrijp me niet verkeerd, Windows 10 is zeker een vooruitgang ten opzicht van Windows XP, alleen vraag ik me af of de lokale sportvereniging daar echt zo veel van gaat profiteren ten opzichte van de migratieproblemen.

Bovenstaande is natuurlijk een beetje gechargeerd, maar heeft ongeveer dezelfde strekking. PHP 5.6 krijg alleen nog veiligheidsupdates en alles daaronder is al EOL. Sterker nog: dit jaar (in december) stopt de actieve ondersteuning voor PHP 7.0.

skate master schreef op dinsdag 18 juli 2017 @ 15:05:
Middels een htaccess bestand in de directory van het script lukt het om wanneer ik het script direct benader het resultaat te zien zonder de foutmeldingen. Echter wanneer ik een Curl aanroep doe naar het script lijkt het wel dat de htaccess genegeerd word, ik krijg dan een http 500 error. De URL in de Curl aanroep is goed, deze werkt middels een directe aanroep in de browser wel.

Zijn er mogelijkheden om Curl wel de htaccess te laten gebruiken?

Curl zou altijd de .htaccess moeten gebruiken. Dit wordt in Apache afgevangen en tenzij je dingen af vangt in de .htaccess op basis van User-Agent worden alle regels toegepast voor zowel Curl, als Chrome en als Firefox.

Het script wordt aangepast naar PHP7, echter is het een vrij groot, gedateerd en niet gedocumenteerd systeem.
Veel werk dus om het om te zetten en de gebruiker wie het script gemaakt heeft wil er niets meer van weten.

Kortom: zijn er mogelijkheden om de standen via Curl op te halen en in de site te verwerken zonder dat ik de hele site op en lagere PHP versie moet laten draaien?

Ja, die zijn er wel. Je kunt in Apache per domein/subdomein/directory de php bestanden laten afhandelen door een andere PHP versie. Hiervoor gebruik je voor PHP 7 gewoon mod_php en voor 5.6 de fastcgi optie. De vraag is of je dat moet willen.

Ik weet niet op welke PHP versie dit voorheen draaide, maar als dit op PHP 5.6 was, is het relatief eenvoudig om dit te porten naar 7.0. De meeste dingen in PHP 5.6 werken nog in PHP 7.0 met uitzondering van de mysql_* en ereg_* functions. De mysql_* zijn relatief gemakkelijk aan te passen. Zie hiervoor mijn opmerking boven in deze post. De ereg_* functies zijn ook niet heel moeilijk om te vervangen door preg_* functies, maar dit zal iets meer werk zijn. Als vraag ik me af of deze functies er überhaupt nog in zitten, want deze zijn al een hele poos deprecated en ik ben ze ook al heel lang niet meer in het wild tegengekomen.

[ Voor 87% gewijzigd door dev10 op 18-07-2017 22:44 ]

[Thijsmans]

Je zou zelfs de scripts kunnen hernoemen naar uitslagen.php5 en daar een andere handler aan kunnen koppelen. Zo deden we dat bij PHP3

[kipppertje]

Thijsmans schreef op dinsdag 18 juli 2017 @ 23:09:
Je zou zelfs de scripts kunnen hernoemen naar uitslagen.php5 en daar een andere handler aan kunnen koppelen. Zo deden we dat bij PHP3

Dat is misschien nog wel een mooiere oplossing. Dan kunnen ze ondertussen rustig de tijd nemen om het script om te schrijven.

[skate master]

Allen, dank voor het meedenken.

Uiteindelijk heb ik de oplossing van @Thijsmans gebruikt.
Ik had in de subdir al wel een htaccess met een andere handler, echter gewoon naar de standaard .php extensie. Blijkbaar werkte dat dan toch niet voldoende.
Door simpel de extensie te wijzigen in .php5 werkt het weer zoals verwacht.

Nu de tijd nemen om de scripts om te bouwen.

[ Voor 0% gewijzigd door skate master op 19-07-2017 10:21 . Reden: Typo ]

[Stoelpoot]

kipppertje schreef op dinsdag 18 juli 2017 @ 16:25:
[...]


Begrijp me niet verkeerd, PHP7 is zeker een vooruitgang, alleen vraag ik me af of de lokale sportvereniging daar echt zoveel van gaat profiteren ten opzichte van de migratie problemen.

Begrijp me niet verkeerd, PHP8, 9, 10, 11, 12, en 101 zijn zeker een vooruitgang, alleen vraag ik me af of de lokale sportvereniging daar echt zoveel van gaat profiteren ten opzichte van de migratie problemen.

[skate master]

rikpro schreef op woensdag 19 juli 2017 @ 10:27:
[...]


Begrijp me niet verkeerd, PHP8, 9, 10, 11, 12, en 101 zijn zeker een vooruitgang, alleen vraag ik me af of de lokale sportvereniging daar echt zoveel van gaat profiteren ten opzichte van de migratie problemen.

Ik begrijp ook wel dat voor ons de "winst" niet zo groot is bij een nieuwe versie, echter lopen we nu tegen het probleem aan dat het niet meer "standaard" werkt.
De hele site draaien op een "oude" versie is natuurlijk niet handig, zo'n versie wordt op de duur niet meer ondersteund en dan hebben we geen keuze meer en is het moeten.

Nu hebben we de keuze om over te gaan en hebben we de tijd om de boel op orde te maken zodat we klaar zijn voor de toekomst.

[Stoelpoot]

skate master schreef op woensdag 19 juli 2017 @ 11:01:
[...]


Ik begrijp ook wel dat voor ons de "winst" niet zo groot is bij een nieuwe versie, echter lopen we nu tegen het probleem aan dat het niet meer "standaard" werkt.
De hele site draaien op een "oude" versie is natuurlijk niet handig, zo'n versie wordt op de duur niet meer ondersteund en dan hebben we geen keuze meer en is het moeten.

Nu hebben we de keuze om over te gaan en hebben we de tijd om de boel op orde te maken zodat we klaar zijn voor de toekomst.

Oeps, ik was de /s vergeten

[kipppertje]

rikpro schreef op woensdag 19 juli 2017 @ 10:27:
[...]


Begrijp me niet verkeerd, PHP8, 9, 10, 11, 12, en 101 zijn zeker een vooruitgang, alleen vraag ik me af of de lokale sportvereniging daar echt zoveel van gaat profiteren ten opzichte van de migratie problemen.

Vooralsnog wordt PHP5 nog steeds ondersteund. Tuurlijk is de oplossing niet voor eeuwig houdbaar.