If $parameter

Ik neem aan dat je wilt controleren of een checkbox aan is gevinkt? In dat geval moet je controleren of deze een $_POST-waarde meegeeft. Als deze aan is gevinkt, dan doet hij dan, en anders niet.

<?php
if(isset($_POST['vinkboxje'])) {
// ja, er is gevinkt.
} else {
// Nee, we hebben geen vink te pakken
}
?>

if(isset($_POST['vinkboxje'])) {
// dan is de waarde zoals invuld bijv. value="3" bijhorend bij de radiobox
} else {
// Nee, dan wordt gekozen $_post:['COP']
Bouwjaar huidige koelmachine:
<select name="COP">
<option value="2">1990 - 2000</option>
<option value="2.5">2000 - 2010</option>
}
?>

Mijn code is de afhandeling. Dit staat los van de HTML-formulierelementen

Je kunt beter even een basis php en html tutorial opzoeken.
Je kunt namelijk niet zomaar html in php gooien, deze moet dan in een echo geplaatst worden of buiten de php.
Let ook op hoofdletters en typfouten
$_post:['COP'] zou moeten zijn $_POST['COP']
Een formulier plaats je altijd in een <form> en dient wel een button of submit te hebben.
Select dien je ook weer te sluiten.

<?php
if($_SERVER['REQUEST_METHOD'] == 'post') {
// hierin doe je alle afhandelingen wanneer het formulier is gepost

if(isset($_POST['vinkboxje'])) {
    $waarde = 3;
} else {
    $waarde = $_POST['COP'];
}

echo $waarde;

}
?>
<form method="POST">
<select name="COP">
<option value="2">1990 - 2000</option>
<option value="2.5">2000 - 2010</option>
</select>

<input type="checkbox" name="vinkboxje" />
<button>Post</button>

</form>

Het volgende gaat waarschijnlijk te ver voor de vragensteller?

if($_SERVER['REQUEST_METHOD'] == 'post') {

gebruik ik ook wel eens, maar ik dacht dat 'POST' dan met hoofdletters moest, tenminste zo staat het wel in het voorbeeld http://php.net/manual/en/reserved.variables.server.php .

Er staat ook een (misschien out-of-date) waarschuwing tegen arbitrary methods, en volgens mij was het zo dat je dit soort waarden zowieso als tainted moet beschouwen omdat ze client-side worden ingesteld.
Kan je dan niet beter iets doen als:

if (isset($_SERVER['REQUEST_METHOD']) && $_SERVER['REQUEST_METHOD'] === 'POST') {

?

Dat is een lang verhaal maar hiermee speel je op safe:

if (isset($_SERVER['REQUEST_METHOD']) && strtoupper($_SERVER['REQUEST_METHOD']) === 'POST')

$_SERVER wordt gevuld door de webserver, dus kun je bij sommige webservers afwijkende resultaten krijgen. $_SERVER['REQUEST_METHOD'] kan bijvoorbeeld ontbreken als het PHP-script via een commandline (zoals een cronjob) wordt aangeroepen. Vandaar dat je dit voor maximale compatibiliteit beter met isset() kunt ondervangen.

Prachtig :) Nu las ik in het verhaal achter de link dat er voor PHP het voorbeeld wordt gegeven met strtoupper. Maar, om mijn applicatie helemaal Unicode compliant te maken met UTF-8, heb ik onder andere juist alle strtoupper() calls veranderd naar mb_strtoupper(). Zit je daarmee meer of minder veilig? Want strtoupper() werkt naar gelang de locale die is ingesteld...

Als ik het goed begrijp van http://stackoverflow.com/questions/4400678/http-header-should-use-what-character-encoding moet de HTTP header in US-ASCII gecodeerd zijn. Omdat US-ASCII altijd een subset is van UTF-8, ben ik geneigd te zeggen dat je met mb_strtoupper() altijd goed zit. Van strtoupper() weet ik het niet zeker, het zou kunnen dat als er een andere locale wordt ingesteld, bv. met setlocale(), het niet goed werkt. Daar komt bij dat setlocale() ook nog eens niet thread safe is, en dan heb je een extra (klein) veiligheidsrisico, het kan daar gaan rammelen, als een ander script een andere locale instelt.
Van http://php.net/manual/en/function.setlocale.php :

Warning
The locale information is maintained per process, not per thread. If you are running PHP on a multithreaded server API like IIS, HHVM or Apache on Windows, you may experience sudden changes in locale settings while a script is running, though the script itself never called setlocale(). This happens due to other scripts running in different threads of the same process at the same time, changing the process-wide locale using setlocale().

Oke, het is wel een tikje paranoïde, het gaat vast en zeker vrijwel altijd goed anders hadden we hier wel meer over gehoord. Toch?

Alle HTTP-methoden kun je sowieso in 7-bit ASCII uitspellen, dus als strtoupper($_SERVER['REQUEST_METHOD']) een onverwachte string oplevert, was de HTTP-methode per definitie al ongeldig.

Er is geen door PHP ondersteunde karakterset waarin de hoofdletters POST niet in de eerste 7 bits staan. Verschillen ontstaan pas vanaf de 8e bit.

Ik denk dat je het voor de veiligheid hier dus zou moeten omkeren: niet erop vertrouwen dat je overal correcte en volledige UTF-8 kunt afdwingen. (Hacks met 16-bits karaktersets maken daarvan namelijk dankbaar misbruik.) Staat er ongeacht karakterset en ongeacht locale niet 'POST', dan weet je al genoeg.

Dank jullie voor de hulp! Het is mij inmiddels gelukt het werkend te krijgen.

HTML en PHP had ik uiteraard los staan. Had het daarna gedaan zoals aangegeven door AAR, alleen was bij mij een fout ingeslopen, waardoor het niet direct werkte...

Toch maar meer verdiepen in PHP, mogelijkheden zijn oneindig ;-)

@Ward, Ik heb het nog even nagebrowsed, en mb_strtoupper() kan je net zo goed gebruiken. En het is inderdaad zo dat je bij UTF-8 invoer van de browser van te voren moet checken of er geen ongeldige byte sequences zijn. Ergo strtoupper() is uiteindelijk simpeler en net zo doeltreffend.

Ondanks dat logica in deze te kort schiet wil ik voor het oog liever alles multibyte-compatible houden, en zal ik mb_strtoupper() blijven gebruiken. Op de één of andere manier vind ik eleganter staan omdat het dan consistenter / gelijkvormiger is met de rest van mijn code.

Off-topic: nog even wat historie van ASCII bekeken, en toen kwam het weer naar boven dat een van key-features van de uiteindelijke ASCII-standaard juist is dat de printable charachters op vaste code-points zitten waarmee ASCII in hoge mate compatible is met codepages van zichzelf, dit in tegenstelling tot oudere encoding schema's als EBCDIC. EBCDIC codepages zijn niet bijzonder compatible met andere EBCDIC codepages, inclusief special characters, die weer op andere codepoints zitten. Bij EBCDIC maakt het enorm uit met welk encoding schema je source bestanden zijn opgeslagen. PHP maalt er totaal niet om, omdat de parser (net als andere talen) dankbaar gebruik kan maken van de vaste codepoints van (US-)ASCII. Onlangs had ik nog nageplozen dat PHP dus ook met UTF-8 uit te weg kan, omdat UTF-8 encoding juist zo is gemaakt dat het alleen encodeert met de 8e bit er bij, en daarmee is UTF-8 volledig ASCII-compatible. Dus andere encoding schema's die niet volledig compatible zijn met ASCII zullen problemen geven voor de PHP parser. Volgens mij geven onder andere UTF-16 en UTF-32 problemen.