Problemen met $GLOBALS['xxxxxxx'] verschillende Windows omgevingen?
Ik ben nu op een klus gekomen en ik moet er wat bij in bouwen. Dit staat op een Windows server waarbij Apache draait met een Oracle XE database.
Wanneer ik de applicatie start op der server middels http://<server naame>/<applicatie naam> werkt het.
Dus dat betekent ook, wat volgens mij de anderen ook doen, dat er ontwikkeld moet worden op de server. Dit vind ik minder.
Daarom dacht ik, ik installeer XAMPP op mijn bedrijfs laptop en plaats de front-end in htdocs. Zorg dat er connectie komt middels php_oci8 (PHP 5.6.x wordt hier nog gebruikt) en dan kan ik op mijn eigen omgeving ontwikkelen zonder verder last te hebben van collega's.
De connectie werkt ed. en ik kan de applicatie starten via http://localhost/<applicatie_naam>
Waar ik op vastloop zijn $GLOBALS, bv. ik krijg dan de melding index ... $GLOBALS['current_database_connection'] does not exist....
Hoe kan dit nu? Worden $GLOBALS nog op een andere GLOBALE (de naam zegt het al) gedefinieerd? Daar bedoel ik mee buiten de applicatie.
Waarom struikelt de applicatie niet als ik deze vanaf de server start en wel bij mijn localhost?
Nico
Wat wij op kantoor gewoon doen is iedereen een eigen omgeving geven op een centrale server, met een bekende configuratie. Anders krijg je vroeg of laat gegarandeerd gezeik met bugs die geintroduceerd worden omdat men de configuratie op zijn eigen machine niet op orde heeft.
Staan er geen script bestanden boven die htdocs map?
Indien geinstalleerd op een C:\windows zijn alle scripts geplaatst in C:\xampp\htdocs zonder problemen benaderbaar.
U heeft of een gruwelijke fout in de php config file te vinden onder, C:\xampp\php.ini, zitten.
Afhankelijk van de windows/xampp versie kan deez file ook onder C:\xampp\etc\php\php.ini te vinden zijn.
Het wel of niet benaderbaar van de xampp server via een extern/intern adres is te vinden onder,
C:\xampp\apache\conf\httpd.conf.
Verander de laatse regel in dit script ServerName: <ipadres>; en open de poort in de firewall. ->start-> configuration-> network -> enzovoorts.
Wat ik wel vreemd vind is dat u gebruik maakt van een $GLOBALS om een connectie tot een XE Oracle database tot stand te brengen.
$GLOBALS werken na definieering serverwijd maar zijn hier niet voor bedoeld. Dus een wijziging hier in zou niet verkeerd zijn qua opbouw en structuur.
Het standaardverhaal qua van het onder php een database connectie tot stand brengen wijkt af.
Link: https://secure.php.net/manual/en/function.oci-connect.php
Gewijzigd op 12/09/2018 09:41:29 door Yoop Overmaat
Ik heb wel een verschil gevonden in de php.ini. Op de server, waar het dus werkt staat register_globals=On,
Bij mijn XAMPP staat deze op off. Nu probeer ik hem op On te zetten maar dan start Apache niet meer op.
Ik ga even verder met zoeken, maar zou dit er mee te maken kunnen hebben? Het is een interne applicatie, wat gewoon volgens mij uit de losse pols bedacht is..., maar inmiddels toch al wat stakeholders kent!
******************* EDIT *******************:
Ik denk dat ik het gevonden heb, zeker na de opmerking "zonder configuratie kunnen we niet helpen". Omdat ik nog niet zo met dit fenomeen bekend ben heb ik er niet direct bij stil gestaan dat het ook nog in de configuratie zou kunnen zitten.
Maar ik lees nu net dat vanaf PHP 5.4 register_globals niet meer mogelijk is. Nu heb ik zojuist de PHP versie's expliciet gecontroleerd, ik dacht begrepen te hebben dat overal 5.6 gebruikt werd, maar dat is niet zo.
Mijn XAMPP heeft versie 5.6.30. Op de server staat nog versie 5.2.6 en als ik het goed begrijp werkt 'register_globals' nog wel mee.
Dan is het hiermee verklaarbaar dat het op de server wel werkt en niet op mijn localhost.
Nu bestaat er geloof ik wel even een 'workaround' om dit voor nu werkend te maken op mijn localhost. Vervolgens maak ik mijn wijzigingen en plaats die op de dev-server om verder te testen.
Gewijzigd op 12/09/2018 10:34:24 door nkamp Kamp van de
Dat is de ellende van een niet standaard php_ico8 versie onder xampp geinstalleerd op een windowsversie.
Als de Apache server het niet slikt is het, heb er geen zin aan, bekijk het maar.
Een workaround kan maar dat wordt kunst -en vliegwerk, de uitkomst van dit probeersel zeer onzeker.
Geen idee hoe of je dit op moet lossen?
Gewijzigd op 12/09/2018 11:28:50 door Yoop Overmaat
Snel (laten) updaten..
Gewijzigd op 12/09/2018 11:44:43 door - Ariën -
Er is een reden waarom register_globals is uitgefaseerd en verwijderd uit PHP. Ik denk dan ook dat het beter is om je energie te steken in iets wat geschreven is met recentere ontwerpcriteria dan om hier iets nieuws tegenaan te metselen.
Dan heb je het over "ontwikkelen op de server". Ik hoop voor jou en je bedrijf dat dit inaccuraat is en dat je middels een versioningsysteem hier wijzigingen in aanbrengt. Of dat je op zijn minst een procedure hebt voor het wijzigen van code die niet onderworpen is aan versiebeheer, anders is het gewoon een kwestie van tijd voordat deze applicatie definitief om zeep wordt geholpen.
Als deze applicatie op enige manier kritisch is voor jouw bedrijf of die van iemand anders, dan zou ik heel snel gaan investeren in een strategie om dit ding ergens anders onder te brengen in een vorm die wat meer levensvatbaar is dan de huidige opzet.
Gewijzigd op 12/09/2018 16:52:52 door Thomas van den Heuvel
Of zelfs, nu niet, er is al nieuwbouw gestart door een partij/eigen organisatie maar laat nog op zich wachten of komt zelfs nooit af... etc. etc. Ik heb het allemaal al voorbij zien komen en ik raak er niet meer van in de war. En ze weten hetzelf ook, als zo'n 'slagschip' aan het varen is dan kun je het niet zo maar van de koers laten veranderen als het om de 'huidige' centen gaat, de 'rest' zien we later wel!
Ik ben zelf voor nu terug geschakeld op 5.2.6, en was een leer momentje. Ik heb nog niet alles kunnen testen, maar het lijkt nu te werken en kan ik nu doen wat mij gevraagd is, althans het op deze manier werken vind ik stukken plezieriger voor mijzelf.
Ik liep nog wel tegen een dingetje aan. Blijkbaar zat er in deze legacy XAMPP versie ook nog een PHP.ini onder Apache en daar moest je ook de php_oci8.dll activeren!
Zover downgraden is NOOIT de oplossing.
Gewijzigd op 12/09/2018 21:46:32 door - Ariën -