Ik ben klant van Mijndomein. Mijndomein heeft een aantal dagen geleden mijn website rspp.nl overgezet naar een nieuw platform php vs 7.1. Mijn phpscripts ondersteunen dat nog niet. Er is een mogelijkheid bij Mijndomein om het platform terug te zetten naar vs 5.6, wat ik ook heb gedaan. Begin 2019 komt PHP 5.6 te vervallen.
Wat ik nu niet begrijp is dat ik ineens die foutmelding(en) krijg ná het vernieuwen van het platform. Het script is sinds twee jaar niet gewijzigd en werkte uitstekend.
Sinds het nieuwe platform er is, stonden er drie fouten op mijn website die inmiddels zijn opgelost. Daarna kreeg stond er weer eentje welke ik niet kan oplossen.
// HIERONDER GEEN FUNKTIE. DE CODE HIERONDER WORDT ALTIJD UITGEVOERD (en functies alleen als je ze aanroept)
//zoek alvast nuttige info
$sessie = session_id();
$pathinfo = $_SERVER['PHP_SELF'];
$membernaam="";
$dezepagina=str_replace("/","",$pathinfo);
Je bedoeld onderstaande error logs welke je al hiervoor aangaf. Ik zal deze in alle pagina's helemaal bovenaan het script toevoegen.
De webserver houdt als het goed is al het een en ander (stilzwijgend) bij, in een directory genaamd /logs of equivalent boven de webdirectory. Zowel bezoek (doorgaans in access.log) als foutmeldingen (doorgaans in error.log) worden daar als het goed is geregistreerd.
Oh ja, dus error_repporting hoeft dus ook niet in mijn index.php?
Je had het eerder over, dat het verstandig is om htmlspecialchars te gebruiken voor b.v. $_POST. Hoe zet ik dat neer in onderstaand statement? Of gebruik je htmlspecialchars alleen na een echo en voor $_post?
Ja, htmlspecialchars() gebruik je alleen als je de data toont.
Trouwens, waarom zou je een password door htmlspecialchars halen? Die echo je sowieso niet, of je wilt graag een bijzonder security-lek inkoppen.
Passwords moet je met Bcrypt opslaan, met password_hash() en daarna controleren met password_verify()
Maarre, heeft dit nog met de overgang naar PHP7 te maken? :-P
Alle output die je in een HTML document wilt weergeven maar niet als HTML wilt interpreteren (maar als platte tekst) dien je door htmlspecialchars() heen te halen.
Een wachtwoord dien je versleuteld op te slaan, dus die komt nooit meer als platte tekst terug omdat het originele wachtwoord nergens (in die vorm) opgeslagen zou mogen zijn.
Er is weer een heleboel mis met mijn website. Voordat ik in mijndomein het platform omzet van php 5.6 naar php7.1 heb ik alle webpagina’s gewijzigd:
http/rspp.nl/ enz > https:/rspp.nl/enz
<? > <?php
<?= > <?php echo enz
Problemen in order.php
Wanneer ik het @-teken verwijder in order.php en deze upload in sftp, dan krijg ik foutmeldingen in order.php pagina en deze verwijzen naar onderstaande lijnen. Er wordt niets berekend. Wanneer ik de @-tekens terugzet dan wel weer en komt de bestelling in de mailbox [email protected]
@-TEKEN (onderdrukking) in order.php voor :
Lijn 60: if (strlen(trim(@$_POST['alverzonden']))>1) {$doen=0;}
Lijn 83: if (@$_POST['verzend']) {
Lijn 109: @$remote_addr."','".$password1."')";
Lijn 152: @$totaalprijs=$totaalprijs+($prijs*(int)$aantal[$i]);
Lijn 153: @$totaalaantal=$totaalaantal+(int)$aantal[$i];
Lijn 168: $totaalbericht.='<td>'.@$totaalaantal.'
Lijn 169: $totaalbericht.='<td>'.maakeuros(@$totaalprijs).
Probleem met uitlog.php en mijnorder.php - kan niet uitloggen
Met de knop OK uit bedankt.php kom je weer in index.php, dan zie je links boven dat je bent ingelogd en links onder in het menu kun je uitloggen en mijnorder bekijken.
Bij mijnorder.php staat dan een lege order 0,00. Wanneer ik op de knop uitloggen klik, kom ik b.v. op de homepage terecht met een wit scherm. Wanneer ik opnieuw de url rspp.nl site opvraag staat er soms nog mijn welkomsnaam links bovenaan en onderaan het menu nog de knop uitloggen.
Probleem in winkelwagen.php
Wanneer je in categorie frame, motor of wiel een artikel invoert b.v. 5 en je wijzigt het artikel in b.v. 3 in winkelwagen.php, dan wordt er niets berekend 0,00 en ook geen artikelfoto meer.
Artikel wijzigen in winkelwagen.php
<select name="invoer<?php echo $i ?>" id="invoer<?php echo $i ?>" onChange="document.forms['guestform'].submit();">
<?php
for ($q=0; $q < 10; $q++) {
// wat is het aantal wat geselecteerd zou moeten zijn voor item $i > $i=0?
$selectedValue = isset($aantal[$i]) ? $aantal[$i] : 0;
// dit is de huidige optie
$selected = ($selectedValue == $q ? ' selected="selected"' : '');
// ingeval het aantal gelijk is aan 0 willen we " " afdrukken in plaats van het aantal
$label = ($q == 0 ? ' ' : $q);
?>
<option value="<?php echo $q ?>"<?php echo $selected ?>><?php echo $label ?></option>
<?php
}
?>
</select>
Artikelfoto in winkelwagen.php
$plaatje='<img src="https://rspp.nl/afbeeldingen/winkelfotos/'.$thumb.'">';
if ($thumb=='') {$plaatje='geen foto beschikbaar';};
Is het mogelijk dat iemand mij hierbij helpt? Zou ik ooit mijn website weer goed draaiende krijgen:) ?
Een beste tip: Vermijd @'jes in de code, en zet error-reporting uit op je live site, en schrijf de foutmeldingen naar een error_log, als dat nog niet gedaan wordt.
Wat mij betreft mag je hier best vragen blijven stellen, maar op deze manier gaat het omzetten (of meer een fatsoenering van code die lang op zich heeft laten wachten) wel erg lang duren want elk probleem wat je aanboort zal in een soort van schaakspelvorm behandeld moeten worden. Het zou veel handiger zijn als iemand hier direct "hands on" aan werkt.
Misschien is het ook handig dat je een soort van testomgeving inricht (hetzij op een lokaal opgezet webservertje, hetzij online) die representatief is voor de live omgeving zodat je daar eerst de wijzigingen door kunt voeren en testen. Ontwikkelen op een live omgeving is meestal niet zo handig, vooral als dit een (redelijk) centraal deel uitmaakt van de broodwinning.
Ook zou ik je aanraden om een soort van versiebeheer toe te passen op code, zodat je wijzigingen beter bij kunt houden en je een betere garantie hebt dat er straks niet tig varianten van eenzelfde codebestand rondzwerven. Of je moet een soort van stramien hebben die hier zorg voor draagt (bijvoorbeeld door eerst altijd bestanden te downloaden voordat je deze wijzigt en weer upload ofzo). Dit laatste is mogelijk minder complex, maar bewerkelijker.
Een @ kan zijn nut hebben, maar wordt vaak misbruikt om fout(meldig)en te onderdrukken. Hiermee veeg je in dit geval potentiële problemen onder het tapijt.
Het feit dat getracht wordt foutmeldingen op $_POST variabelen te onderdrukken vertelt mij dat er niet echt een scheiding is (in code) tussen de weergave van het formulier en de afhandeling na verzending hiervan. Dit is vrijwel nooit handig en resulteert vaak in een onoverzichtelijke brei (spaghetti code) met een of meer spagaten door middel van if-else statements om te bepalen wat er moet gebeuren (weergeven formulier, of toch verwerking hiervan?). Het is vele malen handiger om deze verschillende acties (beter) te compartimenteren zodat deze acties ook in afzondering behandeld (en mogelijk belangrijker: gedebugged) kunnen worden.
Dit zou een ideale oplossing zijn, en ik begrijp dat je eerst alles weer op de rails wilt krijgen maar het is wel iets om over na te denken: je kunt alles wel oppoetsen maar als de onderliggende programmastructuur/architectuur niet echt je dat is dan laat je de deur toch een beetje half open staan voor (al dan niet toekomstige) issues.
Ook maakt het ontbreken van een soort van algehele structuur het oplossen van dingen die niet naar behoren werken complexer omdat je bij elk issue het hele systeem in beschouwing moet nemen, in plaats van een enkel, en losstaand, onderdeel. Nu is de applicatie een beetje een baksteen.
Ook zou ik je aanraden om een soort van versiebeheer toe te passen op code, zodat je wijzigingen beter bij kunt houden en je een betere garantie hebt dat er straks niet tig varianten van eenzelfde codebestand rondzwerven. Of je moet een soort van stramien hebben die hier zorg voor draagt (bijvoorbeeld door eerst altijd bestanden te downloaden voordat je deze wijzigt en weer upload ofzo). Dit laatste is mogelijk minder complex, maar bewerkelijker.
En versiebeheer-systeem is wel handig, maar het opzetten ervan vergt ook een flinke 'know-how' en een goed model hoe je het project uitrolt naar de live omgeving. Ik denk dat een goed stramien met downloaden, uploaden en een gelijkmatige LAMP/WAMP/MAMP testomgeving voor een beginner de beste keuze is.
Ikzelf heb zelfs een aparte domeinnaam geregistreerd voor testdoeleinden. Want ik ontwikkel op Windows en draai live op Linux en test het op die manier ook daar op uit.
Daar hoef je (meestal) niet perse een aparte domeinnaam voor te registreren. Als het gewoon een simpele website is, zonder callbacks vanaf anders servers of iets dergelijks, dan kun je als ServerName (in je Apache config) gewoon een "fantasie domeinnaam" aanmaken en die vervolgens aan je Windows "hosts" bestand toevoegen.
