PHP7 functie laten werken zoals in php5
Ik ben genoodzaakt, zoals zovelen onder jullie vermoed ik, om de stap van php5 naar php7 te maken.
en meteen stuit ik op een "probleem" met een query/functie die ik in 5.6 gebruikte en nu in 7.1 wil ik graag iets identiek hebben maar ik slaag er niet in om dit te laten werken.
de query "werkt" in 7.1 als ik hem niet in de functie plaats maar eens in de functie lijkt het niet te lukken...
$tekst= 23456;
$sql= "SELECT *
FROM
eob_taal
WHERE taal_id = '".$tekst."' ";
$query = mysqli_query($con, $sql);
$vertaal = mysqli_fetch_array($query);
echo $vertaal['nl'];
Ik wil deze dus in een functie omdat ik de variabele $tekst plaats op mijn site waar ik teksten wil vertalen. (al zijn daar mss ook wel andere mogelijkheden/suggesties)
In 5.6 gebruikte ik daarvoor
function vertaal($tekst)
{
$q_vertaal ="SELECT
*
FROM
eob_taal
WHERE taal_id ='".$tekst."'
";
$r_vertaal = mysql_query($q_vertaal) or die (mysql_error());
$vertaal = mysql_fetch_array($r_vertaal);
echo $vertaal['nl'];
}
nu probeerde ik al iets met
function vertaal(int $tekst) : ?int maar ik heb het duidelijk nog niet begrepen want dit is wat ik krijg als ik dit probeer
de query doen en hup.... maar dat is niet zo....
Warning</b>: mysqli_query() expects parameter 1 to be mysqli, null given in <b>/home/megakiek/public_html/essevee.com/avantagesalon/connect.php</b> on line <b>90</b><br />
<br />
<b>Warning</b>: mysqli_fetch_array() expects parameter 1 to be mysqli_result, null given in <b>/home/megakiek/public_html/mmmmmm.com/connect.php</b> on line <b>92</b><br />
ik heb lang uitgesteld om naar v7 te gaan maar nu wordt ik natuurlijk wel met de hard facts geconfronteerd....
Heeft iemand tips of plaatsen waar ik meer info hierover zou kunnen vinden?
ik voelde me behoorlijk "cool" in de V5 maar de V7 zet me terug met de voetjes op de grond....
Iemand ergens een link naar nederlandstalige tutorials/artikelen
Gewijzigd op 03/08/2018 09:18:29 door Dimitri Velghe
Je kan dit oplossen door $con mee te geven als argument van je functie, of -iets ranziger- door: global $con; in je functie te gebruiken.
Verder heb ik een beetje mijn twijfels over je vertaalfunctie, want lijkt mij een beetje overbodig als je voor elk ding wat je gaat vertalen een query wilt uitvoeren. Je beter in een keer alle vertalingen ophalen, en met je functie de teksten te replacen.
Gewijzigd op 03/08/2018 09:26:50 door - Ariën -
Dus de $con ... die eigenlijk de query is om te verbinden met de db moet ofwel ook in de functie staan ofwel moet ik er een global van maken maar jij zou voor het eerste gaan?
Ik zou die liever in de functie zelf meegeven als argument. Dan weet je direct dat deze meegegeven wordt.
Dit klinkt allemaal nogal inefficiënt en inflexibel.
Wat je vaak ziet is dat er een soort van "woordenboek-bestanden" opgesteld worden waarin vertalingen zitten. Als je dan componenten in je website hebt die taalspecifieke elementen hebben, bijvoorbeeld een contactformulier, dan include je deze (bv. /lang/<geselecteerde taal>/contact.php) of heb je een mechanisme om deze automatisch in te laden.
Queries zijn dure operaties dus daar dien je spaarzaam mee om te springen. De vraag is dan ook, is het in eerste instantie nodig om dit (vertalingen en taalspecifieke elementen) allemaal in een database op te slaan?
En zelfs als deze vertalingen interactief beheerd worden is er mogelijk nog steeds iets voor te zeggen om dan deze vertalingen te cachen in op zichzelf staande bestanden zodat je voor het gebruik in principe geen database nodig hebt.
En om antwoord te geven op je vraag: de foutmelding geeft al min of meer aan wat er aan de hand is. In de functie mysqli_query() is het verplicht om de link identifier naar de database mee te geven. Dit in tegenstelling tot de oude mysql_query() functie, waarbij dit een optionele tweede parameter was. Als je toen geen database-connectie-resource meegaf, werd de laatst gemaakte connectie verondersteld en gebruikt, bij mysqli_query() moet je deze expliciet meegeven.
Leesvoer?
De standaard MySQL extensie gaat verdwijnen, wat nu?
voorbeeld van een database wrapper class
Gewijzigd op 03/08/2018 14:01:15 door Thomas van den Heuvel