Bedankt man, ik denk dat je me verkeerd begrijpt mijn latin1 coalaties in velden zijn meestal gwn int, decimal, float of date velden wrbij ik soms ook gewoon true of false doorspeel a.h.v. een int value.
Varchar velden deze krijgen utf8 net alsook text velden.

Ik verwerk alle nodige data netjes in mijn zijnde data laag en of logic laag, zodat deze slechts a.h.v. parameters worden doorgespeeld naar mijn view. Mijn view side html heeft de correcte UFT-8 charset en mijn data nodig voor bepaalde pagina's word tot nu toe nog steeds altijd netjes weergegeven zoals ik het wens, ook mijn CMS velden (waar gebruikers bv profiel opmaken) ondervindt tot nu toe nog geen problemen.

Ik zal zeker eens bekijken om eventueel de database om te zetten naar utf8 maar indien dit zoals je zei een grote invloed kan hebben op data zal ik daarom eerst al men bestaande pagina's testen en kijken wat de gevolgen zijn, indien ok dan geen enkel probleem ben dan ten minste blij dat mijn database in orde is en de code betreffende de connectie ook voor toekomstig gebruik.

Met dit script was ik vrijwel in staat alles te doen wat jij zou willen:

foto.php

Hoe te gebruiken in je web app ?
<img src="/foto.php?src=images/foto.jps&w=breedteInPX&h=hoogteInPX(&zc=2)" alt=""/> zc=2 (croppen zonder snijden)

foto.php
Parameters;
src = PAD naar bestand
w & h = breedte en hoogte
zc = Weet ik nog niet 100% zeker maar weet wel dat zc=2 zorgt voor een afbeelding op de juiste maten zoals aangegeven en zonder de afbeelding bij te snijden.

Edit: Weet originele bron niet meer van het script, weet wel dat deze 100% free to use is.

Bedankt man, snap ik volkomen en de manier waarop mijn applicatie geschreven is kan ik ook gewoon vanuit eender wel script meteen de DB class aanspreken zonder eerst een data class aan te spreken maar dit doe ik gewoon bewust niet ik houd het voor mezelf liever code en data gescheiden.
Heb echter bewust gekozen om mijn logic en data gescheiden te houden om sneller te kunnen werken in de toekomst, voor iedere tabel in mijn database heb ik een data class waar alle queries betreffende die tabel geschreven worden in de fucnties van de data klasse (handig voor mij om snel aanpassingen te doen aan queries voor tabel users bv, i.p.v. te gaan zoeken in 1 of meerdere bepaalde scripts.

De reden dat al mijn data classes dan de DBConfig extenden is omdat er enkel queries worden uitgevoerd in de data class en nergens anders, leek me ook beetje logisch om het op die manier te gaan schrijven dan.

Niet om mezelf meer schrijf werk te bezorgzen (wat ik uiteindelijk een beetje doe) maar gewoon om het feit dat wanneer ooit iets moet aangepast worden of er treed een bug op dan weet ik ook precies waar ik dat moet doen (a.h.v. eender welke error) in plaats van te gaan zoeken in 1 bepaald 'all-in' script. En net omdat dit vooral geschreven is voor een groot project vind ik het ook maar meer dan aangenaam als alles netjes gescheiden en logisch in elkaar zit.

En nu ga je me misschien uit lachen maar voor iedere tabel in de database heb ik dus: een logic class, data class en een entity class.
In men logic class hoort gewoon alle website code niet-database gerelateerd, data class alle queries en dergelijke en in mijn entity classes ga ik bv van een tabel een object maken, handig om na het fetchen van gegevens deze ook door te spelen naar de view in de vorm van een object.

Verder had ik gewoon even snippets gepost van voorbeelden hoe ik PDO aanpak in mijn applicatie, hoop de starter er toch mee geholpen te hebben, althans op vlak van verbinding leggen met de database, de rest doet hij beter zelf

Ik zie nu ook wel in dat ik wat extra schrijf werk kon vermijden maar op vlak van dataload en snelheid ondervind ik met deze methode geen problemen ik zou echter wel UTF8 kunnen gaan gebruiken maar mijn database is voornamelijk latin1_swedish_ci en CMS velden deze worden dan als UTF8 opgehaald vandaar ook de keuze om charset niet te bepalen, PDO zorgt ervoor dat de charset toegewezen in de database waarden van het veld automatisch worden gebruikt. Weet niet in hoevere dit vertraging kan veroorzaken maar switchen naar 1 charset doe ik dus niet om die bepaalde reden, ik houd mijn standaard (niet HTML of geen speciale karakters) velden liever in latin1.

Nog geen problemen ondervonden met men beiden classes, ook heb ik nog andere data classes met ook weel functies en ze doen het allemaal prima, ik voorkom in mijn script wel meerdere connecties maar het gebruik van meerdere data objecten lijkt mij geen problemen te geven, vooral bij een project waar maar 1 database word gebruikt.

ERROMODE_EXCEPTION heb ik erbij geplaatst om geen SQL error maar een standaard message weer te geven bij een mislukte database verbinding.

Hoe stel je voor om mijn data class te gaan schrijven om slechts 1 data object te gebruiken voor al mijn functies ?
Dus eig zou ik dan moeten alle nodige queries op die bepaalde pagina uitvoeren in 1 enkele statement?

zolang obj null is is er iets mis met het ophalen van de content van die website, aan je error vermoed ik dat http:// word weg gelaten zodra de functie aangeroepen word met de url erin.

Je error lijkt je Url niet helemaal geparsed te hebben, ik zie geen http:// staan bij de error waardoor mogelijke volgende code niet zal werken aangezien er geen HTTP request is gemaakt om de pagina inhoud op te vragen..

EN de page URL zelf geeft je een json obj als response.
Zoals wm-diensten al zei, probeer eens var_dump($obj);

Want die not found komt duidelijk van de pagina..:

$obj is volgens mij dan gwn een array met waarden, dus alsj een error hebt Not found welja dan doe je...:

if($obj['error'] != "Not found")
{
 //Gevonden
}
else
{
 //Niet gevonden
}

Hier een PDO gerichte config class voor je db (voorbeeld).

<?PHP


namespace src\Data\config;


use PDO;


class DBConfig
{
    protected $dbConstring = "mysql:host=localhost;dbname=databasename";
    protected $dbUser = "databaseuser";
    protected $dbPass = "databasepass";
    public $con = null;
    public $error;
    
    public function __construct()
    {
        $this->connect();
    }
    
    public function __destruct()
    {
        $this->disConnect();
    }
    
    public function connect()
    {
        //Enkel verbinden als de verbinding reeds null is zo voorkom je meerdere connections in 1 request.
        if($this->con == null)
        {
            try
            {
                $this->con = new PDO($this->dbConstring,$this->dbUser,$this->dbPass);
                $this->con->setAttribute(PDO::ERRMODE_SILENT,PDO::ERRMODE_EXCEPTION);
            }
            catch(\PDOException $e)
            {
                $this->error = $e->getMessage();
                die('Er is een fout opgetreden bij het verbinden met de database. Probeer later opnieuw.<br>An error occured while connecting to the database. Please try again later.');
            }
        }
    }
    
    public function disConnect()
    {
        $this->con = null;
    }
}

En dan hier een voorbeeld van een data class (voorbeeld in hoe je beiden kan combineren en gebruiken):

<?PHP


namespace src\Data;


use src\Data\config\DBConfig;
use src\Entities\User;
use src\Languages\GetLanguageContent;


//Data klasse, verbinden met database


class UserDAO extends DBConfig
{
    private $dbh = '';
    
    public function __construct()
    {
        parent::__construct();
        $connection = new DBConfig();
        $this->dbh = $connection->con;
    }
    
    public function __destruct()
    {
        $this->dbh = null;
    }


    public function checkUsernameExsists($username)
    {
        $statement = $this->dbh->prepare("SELECT `id` FROM `users` WHERE `username` = :username ");
        $statement->execute(array(':username' => $username));
        if($statement->fetchColumn() > 0)
        {
            return TRUE;
        }
        else
        {
            return FALSE;
        }
    }
}

Ik ben dol op domotica, enorm leuk dat je het ook met je watch kan bedienen!

Vind het allemaal wel heel erg ver gaan, zeker leuk voor de eerste paar maanden net als de smart watch, maar uiteindelijk blijft het standaard gebruik van de smartphone toch veel beter, jammer genoeg realiseren mensen dit pas maanden na het kopen van dergelijke gadgets

Thanks, sorry zal in het vervolg beter opletten.

I can convert it into your source but this won't be for free i'm afraid, i can also change the dates to show a date and not something like * hours ago..
This chat application is Ajax based and will show you new massages if your recipent replies without any refresh needed.

Citaat van FangorN

Mja, als de maan van kaas is ben ik Napoleon.
Met andere woorden: als je uitgangsstelling niet klopt kun je zeggen wat je wilt (false => true).

Getuige bovenstaande code van @ruttydm, die zo lek is als maar kan zijn.

als het niet klopt genereer je een default of een error message om de gebruiker er op te wijzen..
Tenslotte is het de programmeur die bepaald wat de code moet doen en niet de gebruiker, daarmee moet de programmeur altijd rekening houden.

Het is zeker niet verkeerd om ALTIJD je query input te gaan binden, maar het is ook gewoon niet altijd nodig, gebruikers input zonder enige validatie moet gewoon altijd gebind worden om inderdaad injectie tegen te gaan.

Citaat van FangorN

Toevoeging op code van @MiCa-

PHP

$result = $db->prepare("SELECT * FROM faucets ORDER BY `$sorton` $order");
$result->execute();

Hiermee doe je het idee van prepared statement min of meer teniet (door rechtstreeks waarden in je querystring te plakken in plaats van te binden via parameters of values).

Helaas is het niet mogelijk om dit op een andere manier te doen omdat het simpelweg niet mogelijk is om tabelnamen en -kolommen te binden op deze manier (of extra SQL te schrijven, for that matter). Daarvoor zijn prepared statements niet bedoeld, het is enkel de bedoeling dat je DATA bind, en niets anders.

Met het bovenstaande introduceer je wel weer de mogelijkheid voor SQL injectie. Omdat je de spelregels van prepared statements met bovenstaande constructie omzeilt is je query hier weer vatbaar voor. Zorg dus dat je met whitelists werkt, oftewel definieer wat toegestane waarden zijn voor $sorton en $order en zorg ervoor dat ze terug kunnen vallen op een geldige (en zinnige) default waarde.

Ik bedoelde, wanneer jij zelf de tabel kolommen valideert en je order string ook netjes valideerd a.h.v. enige input dan kan je perfect deze variabelen in je query toevoegen zonder dat iemand daarop kan inspelen. Data zoals jij aangeeft aan de andere kant moet wel steeds gebind worden en daarvoor beveel ik het 2e stukje code aan in mijn eerdere post i.p.v. iedere parameter in een aparte lijn te gaan binden. Data zal meestal ook alleen maar voorkomen in de WHERE clause.

Kolommen valideren kan al met een simpele array met toegankelijke kollomen, en je order kan gwn a.h.v. je gebruikers input, switch die en maak je string op met int waarden indien user input geen int waarde is stel je gwn een standaar in zoals bv: LIMIT 0,10
Dit is vooral handig bij dynamische code, functies die op meerdere vesrch wijzen gebruikt kunnen worden. Het is veilig zolang je weet wat je doet..

Dit lijkt op tablet of toch nog desktop ?
Oplossing is de css style aanpassen van het de betreffende button en dan de font-size: *px; aanpassen naar x aantal pixels, als het op desktop OK is dan gwn vanaf een bepaalde viewport (tablet size) de pixels aanpassen a.h.v. media queries.

Verander eens dit:

$result = $db->prepare("SELECT * FROM faucets ORDER BY :sorton :order");
$result->bindValue(':sorton', $sorton, PDO::PARAM_STR);
$result->bindValue(':order', $order, PDO::PARAM_STR);
$result->execute();

In dit:

$result = $db->prepare("SELECT * FROM faucets ORDER BY :sorton :order");
$result->execute(array(':sorton' => $sorton, ':order' => $order));

Vervolgens, zorg dat $sorton effectief een tabel attribuut bevat en dat $order ook juist is LIMIT *,* ...
Ik heb nooit eerder tabel attributen of orders gebind, snap ook niet waarom dat nodig is zolang het geen user input is.
Dus alsnog indien geen user input of op z'n minst door jouw samengestelde input variabelen a.h.v. die user input: dan kan je zonder gebinde parameters werken in je querie:

$result = $db->prepare("SELECT * FROM faucets ORDER BY `$sorton` $order");
$result->execute();

PS op die pagina lijken de errors uit een ander script te komen.
Illegal string offset komt voor wanneer je array ongeldige keys of values bevat, een oplossing kan zijn $arr = array("var" => $var); //Werken met dubbele quotes

Toon eens je complete code zoadat ik eens kan nakijken vooral lijn: 42 in index.php
Wat je probeert te doen (volgens de error) is een array naar string omzetten, helaas is dit niet mogelijk.

Indien de error op deze lijn voorkomt:
$r = $this->__exec("balance");

Dan is het omdat je __exec($arr) functie werkt met een array input i.p.v. een variabele input.

Super maar wat ik niet snap is curl en json decode zijn toch geheel andere functies ?
Met curl kan je een server-side (POST, GET,PUT,DELETE) request sturen naar eendere welke server en met json decode kan je een js object omvormen naar een PHP array.

Citaat van Pat4561

Dat is wel heel snel dan, het is namelijk vanaf gisteren ingegaan...

Ja maar ik had een vraag naar adsense toe en na het antwoord zag ik meteen ook dat ik geblokkeerd was op adsense zonder verdere uitleg Vraag werd wel goed beantwoord maar ben ik nu uiteindelijk niets meer mee...
En wanneer ik een apeal stuur dan word deze gewoon beantwoord met een geautomatiseerd bericht...

Maakt opzicht zoveel niet uit momenteel aangezien ik toch geen actieve site's beheer op het moment.

Oke dus daarom ben ik er waarschijnlijk niet zo lang geleden uit gegooid...

Oke maar dat zal toch nog even duren vooralleer ik daar tijd voor heb, maar komt zeker in orde bedankt allen!
Gebruik ook hun logo's, die zal ik ook wat moeten aanpassen dan vrees ik.

Citaat van WMDiensten

Wil niet als een zeikerd overkomen, maar heb je de rechten om die namen te gebruiken? Nu zullen ze kleine spellen niet snel aanpakken maar je maakt gebruik van geregistreerde namen..

Pff, wat mag de dag van vandaag wel nog sorry verwijderd.