Bij dit soort vraagstukken kan het handig zijn om (in het vervolg) de PHP-versie die je gebruikt te vermelden omdat bepaalde constructies simpelweg niet werken in/voor bepaalde versies.

Zo had ik een tijd geleden het probleem dat ik geen statische methoden kon aanroepen waarbij de klassenaam variabel was. Dit bleek niet ondersteund te worden voor PHP 5.3.0. Ook daar was call_user_func() de oplossing.

Of een PHP upgrade lol.

Wellicht heb je hier iets aan?

Google: aspx read image from database, eerste hit

Haha, blijkbaar zijn die ISO praktijken sinds maart 2015 weer afgelopen in verband met de leeftijd van Windows 7 (althans zo luidt de officiele lezing).

Zie het volgende artikel. (En als je hier even naar beneden scrollt) Je zou kunnen proberen om via de Microsoft Software Recovery met behulp van je product key Windows opnieuw te downloaden. In het eerste artikel staat wel dat als je een OEM versie hebt dit niet gaat werken :/.

Ik kan mij nog herinneren van mijn laptop aankoop dat ik er apart (en expliciet) een Windows licentie bij had aangeschaft. Ik weet niet in welke opzet jij je laptop hebt aangeschaft.

Een andere optie is dat je bij de maker van je laptop (ASUS) te rade gaat. In het eerstgenoemde artikel staan ook linkjes naar de verschillende merken.

Als je een (clean) install wilt, probeer eerst de Microsoft Software Recovery. Als je dat niet wilt of dat niet lukt, raadpleeg dan de site van de maker van je laptop of gebruik de meegeleverde software. Wel grote kans dat bij de laatste twee varianten bloatware zit.

En je kunt dus ook nog altijd een image maken van wat je nu hebt op je oude HD, maar misschien is dit ook een goed moment om alles weer een keer schoon te vegen.

Een tijd geleden stond ik voor hetzelfde probleem. Ik heb een ASUS K50ID uit mei 2010. Als ik de specs vergelijk komen onze laptops wel ongeveer overeen. Ik had al Windows 7 64-bit.

De keuze was nieuwe laptop versus upgrade van huidige laptop. In mijn vrije tijd programmeer ik af en toe PHP hierop (WAMP/SublimeText/PHPStorm). Dit zou je ook in zekere zin als tekstverwerking kunnen beschouwen :).

Het enige probleem was dat de laptops die ik voorbij zie komen (ik hield en houd nog steeds de reclamefolders een beetje in de gaten) allemaal shit hebben die ik niet nodig heb, maar waar je wel voor betaalt.

Daarnaast heb ik een gewone desktop PC die ik voor het "zwaardere" werk gebruik: films/series/gaming :p.

Uiteindelijk toch gekozen voor een upgrade die enkel bestond uit de vervanging van een HD door een SSD. Hierbij heb ik gekozen voor een wat duurder model: de Crucial MX100 512 GB. Hier betaalde ik begin dit jaar 200 EUR voor (je zou natuurlijk ook voor een goedkoper model kunnen gaan). Ik heb uiteindelijk gekozen voor dit model vanwege de positieve reviews (volgens mij ook de specifieke (caching?) techniek die van positieve invloed op de levensduur was of zoiets) en de specs ((zeer) hoge lees/schrijfsnelheid). Als je voor een goedkoop model gaat is denk ik de leessnelheid belangrijk(er). Je leest doorgaans vaker data dan dat je deze schrijft.

Volgende stap is het overzetten van je data. Ga je voor het maken van een image of herinstalleer je alles van meegeleverde CD's / DVD's enzo. Ik ben zelf voor optie #3 gegaan want bij die meegeleverde installatieschijven krijg je volgens mij ook ontiegelijk veel bloatware mee (programma's die meegeinstalleerd zijn en je eigenlijk nauwelijks/nooit gebruikt maar wel CPU en geheugen vreten). Anyway, optie #3. Dat is mogelijk het best bewaarde (publieke?) geheim van Microsoft: je kunt gewoon legaal images van windows downloaden van het internet. Tijdens mijn speurtocht naar "asus laptop clean install" kwam ik onder andere deze thread tegen. Nu is het niet verstandig om meteen de eerste de beste bron te geloven, maar vanuit verschillende reacties op dit officiele forum (van medewerkers / gecerticifeerde leden) werd keer op keer doorverwezen naar dezelfde site (digitalrivercontent.net). Je zult wel even zelf moeten uitzoeken welke versie je moet hebben. In deze zelfde reactie wordt ook verwezen naar een supersimpel tooltje (mits je een DVD-brander hebt, uiteraard) voor het bakken van een bootable DVD van de image (GEARISOBurn.exe). Ook zul je dus een andere computer moeten hebben waar je tijdelijk bestanden naar over kunt zetten.

Dan is daar het inbouwen van de SSD. Als je niet direct 2 linkerhanden hebt is dit niet zo heel ingewikkeld. Ik maakte voor mijn avontuur gebruik van een Youtube filmpje. Geen idee of dit 100% aansluit bij jouw model maar het is illustratief genoeg denk ik, en anders moet je even verder zoeken :).

Tot zover een samenvatting van mijn onderzoek :).

Oh, en hoe het bevalt: mijn laptop is best wel weer snel en muisstil. Maar nu vormt de processor waarschijnlijk de bottleneck :). De upgrade is zeker de moeite waard want een SSD is zooooooveel sneller dan je standaard meegeleverde 5400 RPM HD (en geen bloatware helpt ook, natuurlijk :)).

Citaat van matistop333

Als ik die htmlentities erbij doe komt er helemaal niks meer van tekst te staan

Ik zou geen htmlentities() gebruiken maar htmlspecialchars(). Deze functies doen ongeveer hetzelfde, met als verschil dat htmlentities speciale karakters die een html-entity-equivalent hebben hierin worden omgezet (en dat zorgt voor enige verspilling, is minder goed voor XML compatibiliteit blijkbaar; tis gewoon niet nodig, die extra omzettingen :)).

Output escaping is altijd een goed ding, tenzij je dit bewust niet wilt doen bijvoorbeeld omdat je echt HTML wilt afdrukken (die van een betrouwbare bron afkomstig is).

De reden dat je een lege string krijgt komt waarschijnlijk omdat zowel htmlentities() alsmede htmlspecialchars() ook een derde parameter kennen die aangeeft wat je character encoding is. Als de te escapen tekst onbekende (illegale) karakters bevat ten aanzien van deze encoding wordt de lege string geretourneerd. Grote kans dat de character encoding van de tekst niet aansluit bij de aangenomen (default) encoding van htmlentities() / htmlspecialchars().

Je moet het zo zien: escaping vindt altijd plaats in een specifieke character encoding (context), anders kan er simpelweg niet goed ge-escaped worden.

Ik weet niet welke character encoding je gebruikt (UTF-8?) of waar deze vandaan komt (database?) maar het lijkt mij altijd een goede zaak om EXPLICIET aan te geven met welke character encoding (in welke context) je wilt escapen.

Te meer omdat de default encoding (3e parameter) in PHP 5.4.0 verandert van ISO-8859-1 naar UTF-8. Het is (IMO) altijd beter om expliciet ( == ondubbelzinnig ) aan te geven wat er zou moeten gebeuren, in plaats van uit te gaan van default waarden (die dus nogal eens kunnen veranderen).

Een soortgelijke vraag werd hier gesteld, met als enig verschil (als ik het goed begrijp) dat deze tab op een facebook-pagina die niet van jou zelf is wordt aangemaakt.

Ik neem aan dat er dan ook op een of andere manier hiervoor toestemming gegeven moet worden.

Wellicht geeft bovenstaand bericht je een (nieuwe) invalshoek.

Welke API?

Blijkbaar worden de berichten behandeld als plain text. HTML-syntax heeft dan geen enkele betekenis.

Of het gebruik van HTML en dergelijke staat expliciet uit.

Lees de documentatie van de API eens door zou ik zeggen, om te zien of daar iets in staat over het gebruik van (pseudo-)HTML (zoals UBB codes) en/of emoticons.

Misschien maakt de API zelfs gebruik van Content-Types. Als dit text/plain is zal HTML gewoon als tekst worden afgedrukt.

Wat is dit? PDO?

Zoals de foutmelding zegt: er ontbreken een of meer tokens, in dit geval ontbreekt "herUniverse".

Waar ik mij meer zorgen over zou maken is de database-structuur. Ik bedoel, ik bespeur een zeker patroon :s. Zouden skills en talents niet beter in aparte (koppel)tabellen opgeslagen kunnen worden?

Bij het wijzigen van een reactie.

EDIT: het lijkt nu goed te gaan, wellicht hing dit nog samen met de overgang naar het nieuwe IP.

Prepared statements hebben pas een zekere meerwaarde als de query-sjablonen (die je in je prepare() definieert) meerdere keren worden uitgevoerd (met execute()).

Realiseer je goed dat in deze constructie zowel de prepare() als de execute() een query naar je database stuurt. Elke SELECT-query met deze opzet voert dus effectief TWEE queries uit.

mysqli_stmt->bind_param() verwacht in parameter 2, 3 enzovoorts variabelen - je hebt daar functies staan.

Jammergenoeg heeft mysqli geen bind_value() methode zoals PDO, dus je zult hier variabelen van moeten maken.

Of, wat ik zou doen en als dit een optie is, maak bij voorkeur geen gebruik van prepared statements in mysqli. Het is gewoon niet zo handig :s (*uche*understatement*uche*).

Als ik een code-fragment in een bericht wijzig krijg ik een JavaScript foutmelding waardoor ik het bericht niet kan plaatsen. Indien ik deze fout kan reproduceren zal ik deze melden.

Ik raak overigens geen informatie kwijt omdat dit (toch) als "draft" wordt opgeslagen, dat dan weer wel :-).

Uhm, in het algemeen is het eigenlijk wel oké als een username-kolom (van zich)zelf case-sensitive is, dus ik weet niet of het aanpassen van de kolomdefinitie de beste oplossing is, dat zul je zelf moeten uitmaken (maar houd wel rekening met de consequenties).

Tenzij je in je login je username IN CAPS wilt kunnen intypen, of in BrEeZaH-stijl.

Hangt ook een beetje van je query af waarmee logingegevens worden opgehaald, natuurlijk.

En als de controle bij registratie van nieuwe gebruikers ook case-INsensitive is (ik neem aan dat je gebruikersnamen uniek wilt laten zijn).

Let dus wel op de gevolgen van dit besluit tot structuurwijziging.

Normaal zijn tekstvergelijkingen zoals LIKE case-insensitive, tenzij je database, tabel of kolom een case-sensitive collation heeft (of je kolom de toevoeging BINARY heeft).

Je collation geeft aan hoe tekst vergeleken en gesorteerd wordt. Om expliciet een case-insensitive vergelijking te doen geef je dit als volgt aan (er vanuit gaande dat je een utf8 character encoding gebruikt):

SELECT *
FROM table
WHERE case_sensitive_column LIKE '%search_term%' COLLATE utf8_general_ci

Overigens doe je er altijd verstandig aan user input te escapen in je queries met de daarvoor bestemde functie.

EDIT: voorbeeld

mysql> CREATE TABLE test (
 -> col VARCHAR(255) BINARY NOT NULL
 -> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.03 sec)
mysql> INSERT INTO test(col) VALUES ('blaat');
Query OK, 1 row affected (0.01 sec)
mysql> SELECT * FROM test WHERE col LIKE '%BLAAT%';
Empty set (0.00 sec)
mysql> SELECT * FROM test WHERE col LIKE '%BLAAT%' COLLATE utf8_general_ci;
+-------+
| col   |
+-------+
| blaat |
+-------+
1 row in set (0.00 sec)

Citaat van wimmpie

En deze werkt! Dankjewel

(ik snap nog steeds niet wat ik fout deed maar goed...)

Er zijn twee redenen waarom de originele regexp niet werkt zoals je wellicht zou verwachten.

1. Je controleert niet de hele string. Als je alle karakters in een string wilt controleren moet je de juiste meta-karakters meegeven:
- een ^ om de start van je input aan te geven
- een $ om het einde van je input aan te geven (dit karakter ontbreekt)

2. Je controleert maar één karakter. Met [...] definieer je een set geldige karakters; Vervolgens moet je ook aangeven hoeveel karakters je wilt controleren. Als je dit niet aangeeft controleer je precies 1 karakter.

Jouw oorspronkelijke regexp controleert dus enkel het éérste karakter van je input.

De suggestie van A.Tytgat dekt in principe de lading al (controleert de hele string van begin tot eind (^...$) en accepteert een niet-lege input door de + aan het einde (dit houdt in: 1 of meer karakters)).

Maar in zijn suggestie is wel de underscore weggevallen :).

Daarnaast kun je de expressie case-insensitive maken door de pattern modifier i - hiermee maak je de expressie case-insensitive.

Ook kun je met quantifier meta karakters - { accolades } - een minimum en maximum lengte aangeven.

De volgende reguliere expressie combineert alle bovenstaande punten:

<?php
if (preg_match('#^[a-z0-9_-]{6,12}$#i', $input) == 1) {
    echo 'win';
} else {
    echo 'fail';
}
?>

PRO TIP: Little known fact: de $-delimiter accepteert ook één newline karakter. De volgende invoer wordt dus ook geaccepteerd: "123456789012\n". Je doet er dus verstandig aan om je $login na afloop alsnog te ontdoen van een mogelijke newline door hier (r)trim() overheen te halen.

.

Het script in de parameter "url" in je AJAX-call moet enkel de in te voegen onderdelen van het formulier bevatten.

Als het script bijvoorbeeld enkel een input-veld moet teruggeven dan doe je ook alleen dat - het script hoeft geen volledig formulier te serveren omdat dat ene inputveld via jQuery wordt ingevoegd in een reeds bestaand (en compleet) formulier.

AJAX-calls worden meestal gebruikt om ofwel op de achtergrond data op te slaan, of data op de achtergrond op te halen. In het laatste geval haal je snippets HTML of JSON op die je invoegt of verder verwerkt op de pagina waar je de AJAX-call deed.

In jouw geval wil je een prijzentabel ophalen. Als je ervoor zorgt dat deze enkel de in te voegen formuliervelden bevat (en niet een compleet op zichzelf staand formulier) zou dit gewoon moeten werken.

Hoe onderscheid je verschillende producten (ik zie tig varianten staan als ik mij niet vergis)? Ik zie niet goed hoe de informatie van verschillende producten apart wordt opgeslagen - zou je niet beter alle form variabelen kunnen laten beginnen met product[<productId>], en dan product[<productId>][<productEigenschap>] die vervolgens een waarde bevat zodat alle informatie gegarandeerd in de goede (en aparte) vakjes valt?

Weet je zeker dat je je form niet submit? Voeg een "e" aan de callback-functie toe en begin je functie met e.preventDefault() in plaats van een "return false" aan het einde.

Weet je zeker dat je items *binnen* je form-tags toevoegt, anders worden deze sowieso niet verstuurd. En als je dus de verschillende producten niet op een unieke manier opslaat (beginnende met bijvoorbeeld productId) dan heb je dus de kans dat er velden met dezelfde naam meerdere keren voorkomen wat dus resulteert in een enkel veld na submit (velden met dezelfde naam overschrijven elkaar).

Dat geloof ik best.

Maar inline CSS lijkt mij iets wat je moet vermijden. Het vertroebelt de leesbaarheid van je uiteindelijke document.

Als je hier ook nog eens PHP doorheen gaat fietsen is dat dé manier om je code onleesbaar / niet onderhoudbaar te maken.

Daarom zou ik die oplossingsrichting niet kiezen.

Tenzij je echt niet anders kan.

Een apart CSS-bestand heeft voordelen boven al die inline meuk. Waarvan leesbaarheid niet de minste is. Stel dat je iets moet debuggen, dan moet je eerst nog door die heg heen.

*brr*

Daarnaast, simpelweg antwoord geven op een vraag is ook niet altijd de beste "oplossing". Daarbij mag je best zelf een waardeoordeel vellen waarbij je kijkt of de gekozen aanpak wel de goede is.

Ik lees hier een hoop flauwekul. Dit hoeft helemaal niet inline en kan prima middels een losse stylesheet die in wezen een PHP-bestand is.

index.htm

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>PHP stylesheet</title>
<link href="style.php" rel="stylesheet" type="text/css" />
</head>


<body>
<p>Hello world.</p>
</body>
</html>

style.php:

<?php
header('Content-Type: text/css; charset=UTF-8');


$watJijWilt = '#ccccff';
?>
body { background-color: <?php echo $watJijWilt; ?>; }

GL HF.