Heb het even snel doorgekeken, maar er zit o.a verouderde code in en naar mijn idee is dit script echt belachelijk groot voor het gene dat hij zou moeten doen.
Posts by Tredgy
-
-
Misschien iets duidelijker zijn, om wat voor forum script gaat het .. ?
-
str_replace(); werkt ook op arrays.. ze worden floats en je kan er mee rekenen.
PHP<?php $array = array('50,50', '5', '3'); $postTotal = str_replace(',', '.', $array); var_dump($postTotal);
Bedoel je dit?
-------------------------------------------------------------------------------------------------------------------------------------------------------
Je kan eventueel ook het veld totaal een read-only maken dat word opgeteld door js door aantal * prijs te doen. Zo kan je ook user input mistakes verkomen.
Je kan dan met JS zorgen dat wanneer aantal/prijs word aangepast door de user door (or $('#id').on('change', function(){}); in jQuery te gebruiken) om het totaal opnieuw te berekenen wanneer een van de velden word bijgewerkt.
-
De code doet eigenlijk helemaal niks elke 1,5 seconden?
Wat jij wilt is om de data opnieuw in te laden, niet om hem te laten refreshen.
Gebruik Ajax hiervoor om data van de server te plukken en de div te vullen.jQuery.ajax() | jQuery API Documentation ; jQuery's Ajax-Related Methods | jQuery Learning Center ; Ajax | jQuery Learning Center
-
Waarom begin je dan niet aan Criminals blue - revamped deze source? Dit is wel een iets andere source maar maffia game. Deze bevat een stuk minder lekken en is veel beter geprogrammeerd. Ook makkelijker om mee in te stappen.
Nu is het de vraag of die de code gaat snappen je al de tijd niet wilt nemen om het te leren .. lol ..
-
Het makkelijkste is om gebruik te maken van bijvoorbeeld Bootstrap van Twitter. Hier kun je geheel je eigens site omheen bouwen (bekijk mijn site maar als voorbeeld), het is super simpel om te gebruiken en je hoeft het wiel niet opnieuw uit te vinden
Bootstrap is een goeie manier om dat inderdaad te doen. Puurhost.nl klopt alleen nog niet helemaal op de verschillende resoluties die ik getest heb (buttons,titels, sommigen dingen zijn nog off).
-
Vind de prijzen best duur voor de specificaties ...
-
-
Dat is zeker maar ik denk ook dat het een leuke basis om ook andere dingen op te bouwen. Je kan het deel criminals er ook uitgooien.
Dan kan je het net zo goed volledig opnieuw schrijven. Er is gewoon weinig animo voor criminal games. -
-
Gelukkig nieuwjaar & voor iedereen de beste wensen!
-
Wat een lul verhaal, hun waren bezig hadden niks geregistreerd dus toen dacht jij laat ik dat domein registreren? En nergens dacht je dat wat je deed niet netjes was?
-
Het is niet echt dat je dat een lay-out kan noemen.
Idee is best grappig, maar doe inderdaad iets met de lay-out.
Hoe maak je trouwens gebruik van de button op de website, en dan bedoel ik de code erachter?
-
Jij dus ook niet zul je bedoelen. Als jij als bedrijf dat niet ziet zitten om die om te zetten dat doe jij als bedrijf toch iets fout. Zijn gewoon kosten die je door kan berekenen. Die functies zijn wel deprecated waarom zouden ze anders in PHP7 verwijderd worden.
Je kan hier nog wat kennis op spijkeren: Why not to use MySQL extension
Volgens mij heeft TS trouwens genoeg tips gehad om de kwestie op te lossen.
Als jij dat trouwens als bedrijf niet ziet zitten om dat te doen, mag je ze doorzetten naar mij dan verdien ik er zelf wel wat aan.
-
Mee eens hoor
Maar client side code tonen / verbergen a.h.v. een variabele noem ik niet persee beveiligen. Je kan als het ware ook zelf de URL invoeren zonder dat je hem kan zien op de website.. Dus het blijft zeer belangerijk om server-side deze toepassingen te gaan beveiligen.
Overigens zie ik nog heel veel projecten (waar ik help of verbeter) die de oude mysql fncties gebruiken, en ik denk niet dat al die projecten de enige zijn op het web..
Het is inderdaad ten zeerste aangeraden om over te schakelen naar mysqli of PDO, maar voor heel grote projecten kan dit zeer lastig worden. Deze blijven dan dus ook draaien op een PHP versie die mysql_ nog ondersteunt.Maar zowizo vroeg of laat zal het moeten, en dan zullen de meeste telaat zijn zoals gewoonlijk..
Wat eigenlijk echt een slecht argument is, want die programmeurs (en jij) van die projecten weten donders goed dat die functies deprecated zijn dus ook aan vervanging toe zijn en dat is absoluut niet moeilijk om te doen.
Zoals @FangorN zei:
De volgende functies zijn deprecated en verwijderd uit PHP7.
- ext/ereg (since PHP 5.3; use ext/pcre instead) REMOVED (PECL extension)
- ext/mysql (since PHP 5.5; use ext/mysqli or ext/pdo_mysql instead) REMOVED (PECL extension)
-
Ik denk dat je het toch anders moet zien. Het antwoord op jouw eerste vraag is waarschijnlijk "nee", vaak is de standaard character encoding nog steeds latin1. Verder lijkt het mij ook onverstandig om uit te gaan van een default, het is veel beter om deze expliciet in te stellen (bijvoorbeeld bij de creatie van de tabel en bij het maken van een connectie).
Dan misschien handig voor de beeldvorming wat een set_charset() functie doet. Dit moet je zien al een contract tussen jouw applicatie en de database. Dit contract bevat twee bepalingen:
- jij zorgt ervoor dat alle data die je aanlevert in de overeengekomen character encoding is opgesteld
- de database zorgt ervoor (of doet in ieder geval een oprechte poging) om alle data die zij teruggeeft aan te leveren in de overeengekomen character encodingDit is dus de "taal" waarmee jullie met elkaar praten, maar dat zegt helemaal niets over welke character encoderingen de tabellen of de data daarin zou moeten hebben en met een set_charset() methode kun je dit ook niet afdwingen omdat dit al is vastlgelegd in de definities van de tabellen zelf.
Indien jouw website UTF-8 is en jouw database enkel latin1 tabellen bevat kun je dus nog steeds set_charset('utf8') gebruiken: als je iets opvraagt vertaalt MySQL de latin1 data naar utf8 en als je data wegschrijft vertaal MySQL de UTF-8 data naar latin1 (maar dat laatste zal mogelijk niet altijd passen).
Beschouw set_charset() dus als "de character encoding die je op jouw website wenst te gebruiken". Je moet er dan dus ook zorg voor dragen dat je, als je data wegschrijft naar een database, deze data aanlevert in de overeengekomen character encoding anders gaat het mis.
Ahzo, dankjewel weer wat geleerd.
-
Enne, jQuery heeft een standaard functie genaamd serialize() waarmee je automatisch een URL-encoded string kunt bouwen.
Jouw code gebruikt een langere en omslachtigere methode, en encodeert de waarden op dit moment ook helemaal niet... Als er dus gekke tekens in je data zitten die in de URL-encoded context een speciale betekenis hebben bestaat de kans dat de data-string verkeerd wordt uitgelezen aan de ontvangstkant, met onvolledige/corrupte data als gevolg.
Ook is het altijd van belang dat al je character encoderingen in de pas lopen, vooral als je via AJAX data doorgeeft, klopt het dat al je data ook UTF-8 geëncodeerd is (en utf8 in MySQL)?
Het bovenstaande kun je eenvoudig testen door eens wat exotische karakters te voeren aan de database via een AJAX-call, met hier en daar ook karakters als &, >, < en enkele en dubbele quotes. Als alles goed wordt weergegeven na opslaan en er ook weer goed uitziet als je deze data weer wilt gaan bewerken (pas dan heb je een volledig rondje gemaakt) dan heb je je werk goed gedaan. Anders... zet je een stevige pot koffie en los je dit alsnog op :).
Gebruikt MySQL niet automatisch UTF8 codering? en anders mysqli_set_charset();
Verder ga ik met hem akkoord.
-
Wat heb je allemaal geprobeerd?
- Heb je gekeken of het aan je DB lag?
- Heb je gekeken of de query werkt?
- Heb je gekeken of die values gepost/opgenomen worden?
- Heb je gekeken of JS goed doorstuurt?
of wat anders?
-
-
Volgens http://php.net/manual/en/function.exec.php moet $output een array zijn. en $status is gewoon plain int ..