- Eldurvul a Nova Lake-kel az Intel-féle hibrid dizájn
- A GravaStar analóg klaviatúráira nem mondható, hogy konformisták volnának
- Itt vannak az ASUS legszerényebb NVIDIA Blackwell architektúrás VGA-i
- Bluetooth hangszórók
- ThinkPad (NEM IdeaPad)
- Intel Core Ultra 3, Core Ultra 5, Ultra 7, Ultra 9 "Arrow Lake" LGA 1851
- Silicon Power XS75: Játékosoknak, DRAM nélkül
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- HiFi műszaki szemmel - sztereó hangrendszerek
- OLED TV topic
Új hozzászólás Aktív témák
-
#14346
Sk8erPeter
nagyúr
Petyyyyy
#14343
Sk8erPeter
nagyúr
válasz
Petyyyyy
#14343
üzenetére
A kommentárban van egy demólink is.
Az ott szereplő képet inkább imgurra felraktam, meg a sok <br> helyett átalakítottam <p>-re, szóval sokat nem változtattam rajta:http://jsbin.com/ulufot/125/edit
tesztelgesd a különböző böngészőkben.=============
(#14345) trisztan94 :
Ügyes eszköz, de sajnos csak WebKit/Blink-specifikus kódot generál (ott a -webkit prefix), az meg nem faszányos, ha egy webfejlesztő konkrét renderelő motorra optimalizál csak...
Pedig kényelmes lenne.(#14344) mobal :
"jquery blur?"
Erre gondoltál? http://api.jquery.com/blur/
Elárulnád nekem, ezzel hogy mosol el képet?
Tényleg érdekelne! 
-
#14338
Sk8erPeter
nagyúr
fordfairlane
#14336
Sk8erPeter
nagyúr
válasz
fordfairlane
#14336
üzenetére
És meglepő módon még az is segít neki, ha egy kicsit megerőlteti magát, és a dokumentációból az első értelemszerű példát copy-paste-eli, és átírja a számára megfelelő adatokra, például:
http://swiftmailer.org/docs/sending.html
Hogy mik vannak, doksi!
![;]](//cdn.rios.hu/dl/s/v1.gif)
Nem neked mondom, a kérdezőnek, meglep néha az ilyen mértékű lustaság. -
#14334
Sk8erPeter
nagyúr
Peter Kiss
#14332
Sk8erPeter
nagyúr
válasz
Peter Kiss
#14332
üzenetére
Ja, hogy így! Tehát rögtön a példányosítás utáni fluent használatra gondolsz, így már értem, bocs, előbb nem esett le.
Szóval akkor ezek szerint az a para vele, hogy külön sort kell létrehozni a működőképessé tételéhez.
Mondjuk végül is akár még zavaró is lehet. -
#14331
Sk8erPeter
nagyúr
dragon1993
#14330
Sk8erPeter
nagyúr
válasz
dragon1993
#14330
üzenetére
Ja, hogy XML-ben sikerült vesszőt használni? Az rettenetesen értelmes.
Eleve mindenféle ilyen vesszős elválasztás úgy fos, ahogy van. Például sokan azt hiszik, hogy az a cikkek tagekkel való ellátásának módja, hogy vesszőkkel elválasztva benyomják egy adatbázis-mezőbe, aztán kész, pedig nagyon nem úgy kő'. Abból még egy normális query-t sem lehet futtatni, ami nem zabálja tök feleslegesen az erőforrásokat (például stringeket feldarabolni ilyen hülyeség miatt). -
#14329
Sk8erPeter
nagyúr
Peter Kiss
#14328
Sk8erPeter
nagyúr
válasz
Peter Kiss
#14328
üzenetére
Gondolom erre gondolsz, de konkrétan mire gondolsz, hogy nem lehetséges 5.4 előtt? Most hirtelen nem esik le, bár lehet, hogy kiböki a szemem.
(#14327) dragon1993 :
uhh, bocs, de most nincs energiám, meg időm, meg kedvem megnézni a kódot, hogyan tudnád szépíteni...
Mindenesetre az első átfutásra látszott, hogy rengeteg felesleges overheadet adsz hozzá."A vesszősödi tényleg ki lesz, több [url] tagom lesz."
Hogy mi van? -
#14323
Sk8erPeter
nagyúr
dragon1993
#14314
Sk8erPeter
nagyúr
válasz
dragon1993
#14314
üzenetére
Láttam, hogy azóta megoldódott a gondod, de muszáj rákérdeznem:
$urlek="";
$sha="";
foreach ($xml->oldal as $oldal)
{
$urlek = $urlek.$oldal->url;
$sha = $sha.$oldal->sha1;
}
$sha = split(",", $sha);
$urlek = split(",", $urlek);
....
foreach ($urlek as $url)
....Ennek mi értelme van?
Először konkatenálod egy stringgé, aztán széjjelszeded a vesszők mentén, hogy kapj egy tömböt, majd ezután végigmész a tömbön? Miért nem eleve tömböt hozol létre? Azt mondjuk eleve nem tudom, miért tartalmaz vesszőt az $oldal->url tartalma (gondolom tartalmaz, ha már annak mentén szeded széjjel), először azt kéne megoldani, de ha így is van, akkor sem összerakni, majd széjjelbontani kéne, hanem egyszerűen leszedni a vesszőt a végéről, és utána bepakolni az aktuális $oldal->url tartalmát egy tömbbe, úgy még lenne is értelme annak, amit csinálsz.Mondjuk a továbbiak is elég brutálisak. Gondolj bele, milyen felesleges futási időket adsz hozzá az alapvetően nem túl bonyolult scriptedhez:
- 2 különálló foreach ciklus - ebből eleve 1 kilőhető, mert tök felesleges végigmenni még egyszer az immár tömbbe rakott URL-eken - minek különgyűjteni, ha úgyis egyből kezdeni akarsz vele valamit? Totál felesleges lépés kapásból az elején
- aztán ott van az az érdekesen kinéző do-while-od
- még egy while
- ezenbelül még egy do-while
- na most még egy foreach így a végéreÉrzed, mennyi felesleges lépés?
-
#14322
Sk8erPeter
nagyúr
fordfairlane
#14317
Sk8erPeter
nagyúr
válasz
fordfairlane
#14317
üzenetére
Hmm, csak azt nem vágom most így hirtelen, hogy a SwiftMailert miért így oldották meg, hogy tele van ilyen randa static newInstance-ekkel, ahelyett, hogy lehetne rendesen példányosítani.
$transport = Swift_MailTransport::newInstance();
$mailer = Swift_Mailer::newInstance( $transport );
$message = Swift_Message::newInstance( $subject )ezek helyett legalábbis sokkal szebben nézne ki így:
$transport = new Swift_MailTransport();
$mailer = new Swift_Mailer( $transport );
$message = new Swift_Message( $subject ) .....Szóval ide vajon minek a static?
-
#14321
Sk8erPeter
nagyúr
Zedz
#14313
Sk8erPeter
nagyúr
-
#14311
Sk8erPeter
nagyúr
Zedz
#14310
Sk8erPeter
nagyúr
Nem úgy értette. Egyszerűen elírtad, rakj egy s-t a $header végére, mivel csak $headers változót konkatenálgattál, sima $header (s nélküli) változóról szó sem volt sehol.
Tehát még érthetőbben:
$sentmail = mail($to,$subject,$message,$header);
HELYETT
$sentmail = mail($to,$subject,$message,$headers); -
#14306
Sk8erPeter
nagyúr
Rolly
#14293
Sk8erPeter
nagyúr
"Volt egy csodás konferencián ahol beültették a fülébe, hogy a cookiek használata rossz és csak akkor lehet ha az ügyfél tudtára hozzuk és ő engedélyezi..."
Szerintem nem azt ültették a fülébe, hogy rossz, hanem azt, hogy EU-ban kötelező feltüntetni, és engedélyt kérni a cookie használatára, lásd EU cookie law. -
#14305
Sk8erPeter
nagyúr
stigma
#14286
Sk8erPeter
nagyúr
válasz
stigma
#14286
üzenetére
Egyetemen mysql_ kezdetű függvények? Elég sajnálatos...
Mondjuk annyira nem vagyok meglepődve, eléggé jellemző sajnos a felkészületlenség, lemaradozás, az aktuális követelményeknek való megfelelés hiánya a tanrendben, mert a tanárok sokszor lusták képezni magukat, vagy nem eléggé érdeklődőek. (Ugyanis nem csak külső lehetőség (pl. továbbképzés) hatására lehet csak fejleszteni magunkat, engem sem nyomnak oda továbbképzésre, hogy "tanuljá'", hanem épp érdekel vagy kell, így próbálok folyamatosan tanulni valamit a nálam adott témában okosabbaktól. )"Az adatbázisban tárolt adatok kiíratására/"tárolására" 2 mód van(XML vs. JSON), melyiket érdemes/ajánlott használni Android parse-olásra ?
Én eddig csak XML fileból dolgoztam, amiben linkek voltak akár több 100 is , amik egyes képek url linkjeti tartalmazták."
Használd azt, amelyikkel könnyebben tudsz dolgozni. Mindkettő feldolgozására van mód.Például XML parse-olására itt van egy hivatalos doksi:
http://developer.android.com/training/basics/network-ops/xml.html
Ez így gyors átfutásra elég könnyen értelmezhetőnek tűnik (nem fejlesztettem még Androidra, de érdekel).JSON-re pedig:
http://www.vogella.com/articles/AndroidJSON/article.html
http://www.androidhive.info/2012/01/android-json-parsing-tutorial/
http://stackoverflow.com/questions/9605913/how-to-parse-json-in-android -
#14304
Sk8erPeter
nagyúr
biker
#14290
Sk8erPeter
nagyúr
Igazából az indoklásod volt egy kicsit vicces.
A másik meg az, hogy elég meglepő eredményeket ad PHP-ban a foreach versus for ciklus használata: a srác által mutatott teszt tényleg azt az eredményt adja, hogy a foreach minden esetben gyorsabb ennyi lépésben, ami számomra kicsit furcsa, mert más nyelvekben nem igazán ez tapasztalható. (De nem azért, mert van benne egy darab összeadás művelet, meg egy darab összehasonlítás.)Szóval az ennyire feltűnő különbség a foreach javára a for ciklussal szemben a PHP-ban számomra újdonság.
-
#14289
Sk8erPeter
nagyúr
biker
#14288
Sk8erPeter
nagyúr
Te jó ég. Remélem, ezt a hozzászólásodat, miszerint "a foreach csak azt nézi, van-e még elem a tömbben, a for esetén pedig összehasonlít és összead is", ergo BIZTOS lassabb a for ciklus, mint a foreach, csak valami nagyon rossz viccnek szántad...
Ez azért nagyon durva volt. -
#14285
Sk8erPeter
nagyúr
stigma
#14284
Sk8erPeter
nagyúr
válasz
stigma
#14284
üzenetére
Hát pedig nem kéne ezt használni. Tök feleslegesen kutyul így a default MYSQL_BOTH paraméterrel meghívva legalábbis (második paramétert nem adod meg, akkor ezzel hívódik meg) numerikus tömböt asszociatív tömbbel.
Ezenkívül pedig nagyon gyorsan felejtsd el a mysql_ kezdetű függvények használatát (ezt rohadt nagy piros betűkkel írják a hivatalos doksiban is! ), és használj helyette mysqli-t vagy PDO-t. Gondolom valami régi fos tutorialt vettél elő, ahol még ezt használják, olvasgass valami újabb könyvet/tutorialt. -
#14276
Sk8erPeter
nagyúr
trisztan94
#14275
Sk8erPeter
nagyúr
válasz
trisztan94
#14275
üzenetére
"tehát ha a 2. találat id-jére szeretnék hivatkozni akkor
$result[1][0];
eddig gondolom világos.."
Világos, de a legnagyobb hülyeség integer tömbindexekkel hivatkozni a mezőidre, amikor tök egyszerűen megkapod asszociatív tömbként is a fetch_array()-vel, de akkor már használd a fetch_assoc()-ot, mivel tök felesleges, hogy asszociatív és numerikus tömb is legyen kutyulva...szóval akkor helyesen $result[1]['shirt_image_id'], ha már...
Persze nyilván így az éles kódban nem fogsz hivatkozni rá, mivel a $result tömbön szépen végigmész egy foreach-csel/while-lal/for ciklussal.Egyébként meg továbbra sem szégyen, inkább érdem olvasni a dokumentációt...
http://www.php.net/manual/en/mysqli-result.fetch-all.php
azonban itt is van a figyelmeztetés:
"As mysqli_fetch_all() returns all the rows as an array in a single step, it may consume more memory than some similar functions such as mysqli_fetch_array(), which only returns one row at a time from the result set. Further, if you need to iterate over the result set, you will need a looping construct that will further impact performance. For these reasons mysqli_fetch_all() should only be used in those situations where the fetched result set will be sent to another layer for processing."A fetch_assoc-nál meg ott van a példa is a doksiban az objektumorientált kódra:
<?php
$mysqli = new mysqli("localhost", "my_user", "my_password", "world");
/* check connection */
if (mysqli_connect_errno()) {
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
$query = "SELECT Name, CountryCode FROM City ORDER by ID DESC LIMIT 50,5";
if ($result = $mysqli->query($query)) {
/* fetch associative array */
while ($row = $result->fetch_assoc()) {
printf ("%s (%s)\n", $row["Name"], $row["CountryCode"]);
}
/* free result set */
$result->free();
}
/* close connection */
$mysqli->close();Szóval nem értem, mi a gond:
a saját kódodban kigyűjtheted az eredményeidet egy másik tömbbe is, ha nagyon akarod:$myResults = array();
.....................
while ($row = $result->fetch_assoc()) {
$myResults[] = $row;
// de itt babrálhatsz az eredményeiddel így:
echo $row['shirt_image_id'] . ': '.$row['description'];
}
....................
itt felhasználhatod a $myResults tömbödet, amire akarod...
Ha ezt pl. json_encode-olni akarod, akkor nyilvánvalóan olyan módon gyűjtsd ki ezeket az adatokat a $myResults tömbbe, hogy az szűrve legyen, és csak azt a mezőt és olyan módon add vissza a kliensoldalnak, ahogy az elfogadható (pl. ha nem akarod egy az egyben a mezőneveidet visszaadni, akkor nevezd el máshogy, vagy tudom is én, mi az elvárás nálad).Szerk.:
Az pedig gázos, ha így van tagekkel ellátva a bejegyzésed, hogy vesszővel elválasztva beokádod egyetlen mezőbe:
[categories] => {utazás,párizs,trisztán}
Pfuj, broáf! -
#14274
Sk8erPeter
nagyúr
trisztan94
#14273
Sk8erPeter
nagyúr
válasz
trisztan94
#14273
üzenetére
"Tényleg, hozzászoktam már a C#-os és Java-s szintaktikához egy picit, kiment a fejemből."
Hogy mi van?! Az meg hogy jön ide?
Ha megnézed a C#-os példát a doksiban, ott mégis hol látsz indexeket?
Pont ezért nem értettem a meglepettségedet, mert én is úgy tudtam, hogy emellett elvileg C#-ozol és Javázol is... -
#14271
Sk8erPeter
nagyúr
trisztan94
#14267
Sk8erPeter
nagyúr
válasz
trisztan94
#14267
üzenetére
Most komolyan, sírjunk vagy nevessünk?
Dokumentáció olvasgatása és értelmezése néhanapján megy?
-
#14256
Sk8erPeter
nagyúr
PumpkinSeed
#14241
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#14241
üzenetére
Az hogyan lehetséges, hogy egy PHP+MySQL-es könyvet HÁROMSZOR elolvastál, állítólag mindent tudsz belőle, és ilyenek gondot okoznak, például az, hogy rájöjj, hogy itt valami "pusztító alpáriság" történik?
Javaslom, inkább könyvolvasás helyett vagy MELLETT GYAKOROLJ rengeteget, önmagában az, hogy olvasgatsz, nem fog rávezetni a probléma-megoldásra. Saját tapasztalatok, saját hibázások kellenek, hogy tanulj is belőle. Persze mindezt a kísérletezést localhoston tedd.
-
#14255
Sk8erPeter
nagyúr
The DJ
#14226
Sk8erPeter
nagyúr
válasz
The DJ
#14226
üzenetére
Szívesen, bár nem sokat segítettem. Sajnos annyi fölös időm nincs, hogy átnézzem a teljes plugint, meg rájöjjek, miért van nálad IPN-para.
Az pedig nem meglepő, hogy így sincs változás, de azt hittem, ez egyértelmű volt, hogy igazából csak kódjavítás történt az API-nak megfelelően, kissé szépítve (de még így is gányul hagyva) ezt a tákolást - az volt a vicces, hogy a plugin fejlesztője ezek szerint b@szott áttanulmányozni az API-t, hogy legalább felkészítse azt hibára is. Tehát most annyit javítottam a kódon, hogy legalább a plugin ismerje fel a hibát, amennyiben az van, ha ilyen WP_Error-t kapsz, akkor legalább ne kapj egy okádék fatal errort. Bár így is ocsmány, hogy a "hibakezelés" emberünknél abból állt, hogy nyomatott egy jó kis exit()-et a kód kellős közepén, ha para volt. Nem ám felhasználóbarát hibaüzenet, vagy valami.
Mondjuk az ilyenekben a WordPress amúgy is borzalom, nem tudom, mostanság hogy van, de régen emlékszem, akárhányszor elküldtem egy WP-s űrlapot, amennyiben az hibát mutatott, akkor az mutatott egy szinte üres lapot a hibaüzenettel, amely arra szólított fel, hogy nyomjam meg a böngésző "Vissza" nyilát, és akkor vissza tudok térni az előző oldalra. Nem ám normálisan le lettek volna kezelve a kommentelőűrlap hibái, és "felhasználóbarát" (vagyis inkább elvárható) módon újból megmutatta volna az űrlapot, a hibaüzenetekkel együtt.
Amúgy ez a link, amit küldtél, szintén elkeserítő, mert gyors átpörgetés alapján a fejlesztő (??? vagy inkább romboló) azt a gányolmányt belerakta a pluginjébe ("Thanks! I'll include your patch in the next release." - remek!), mármint azt, hogy objektumként kezeli a response-t, ami egy array az API szerint, és mindez kiderül úgy, hogy az ember a doksi megkeresésével és olvasásával 5 másodpercet tölt, mint én tettem...
Na, szóval most gondolom "IPN Request Failure" az eredmény, ami most nem meglepő.Melyik az a plugin, amit használsz? Nem mintha ismernék WordPress pluginokat, de nem tudom egyszerűen elképzelni, hogy ne lenne valami normális webshopplugin hozzá.
Itt mindenképp próbálkozz meg a kérdéssel (angolul nyilván):
http://wordpress.stackexchange.com -
#14225
Sk8erPeter
nagyúr
PumpkinSeed
#14224
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#14224
üzenetére
Ilyen durva önkritikát nem tudom, olvastam-e már, jót röhögtem, de azért ennyire ne légy szigorú önmagadhoz -
#14221
Sk8erPeter
nagyúr
The DJ
#14219
Sk8erPeter
nagyúr
válasz
The DJ
#14219
üzenetére
Gyors rápillantás alapján (nem merültem bele, közöm nincs a WordPress-hez, de a hibák elég nyilvánvalóak):
eleve rossz a visszatérési érték vizsgálata, mert ahelyett, hogy megnézné, egyáltalán elvárt értéket kapott-e eredményül, egyből tömbszerűen kezeli a visszatérési értéket - pedig esetedben nyilvánvaló a hibaüzenetből, hogy NEM tömböt kapsz vissza, hanem egy WP_Error objektumot ("Fatal error: Cannot use object of type WP_Error as array"). Ennek meglétét, ahogy itt a doksiban írják, az is_wp_error függvénnyel lehet vizsgálni.A kód tehát egy szar. Így néz ki most:
$response = wp_remote_post( $paypal_url, $options );
if ( 'VERIFIED' == $response['body'] ) {
$this->paypal_ipn_values = $received_values;
$this->session_id = $received_values['invoice'];
} else {
exit( "IPN Request Failure" );
}erre kéne javítanod, felhasználva a WordPress API-t (amit most látok először
):$response = wp_remote_post( $paypal_url, $options );
if ( is_wp_error($response) ) {
// meglehetősen undorító gusztustalan hányadék ez az exit()-es "hibakezelés"...!!!
exit( "IPN Request Failure" );
}
elseif($response['body'] == 'VERIFIED') {
$this->paypal_ipn_values = $received_values;
$this->session_id = $received_values['invoice'];
}
else {
// tököm tudja, itt mi lenne!
}A lényeg: nálad sajnos abba az ágba fog futni a kód, ahol azt fogja írni, hogy "IPN Request Failure". Ergo itt még valami mindig nem tiszta, valamiért IPN-problémád van. Most ennyire volt időm, szóval konkrétan nem tudom, miért van ez.
-
#14185
Sk8erPeter
nagyúr
Petyyyyy
#14183
Sk8erPeter
nagyúr
-
#14184
Sk8erPeter
nagyúr
trisztan94
#14182
Sk8erPeter
nagyúr
válasz
trisztan94
#14182
üzenetére
Miért lenne undorító?
-
#14181
Sk8erPeter
nagyúr
DNReNTi
#14179
Sk8erPeter
nagyúr
válasz
DNReNTi
#14179
üzenetére
Most nézem, hogy átsiklottam az előtte írt "Másrészt szerintem ilyen feltételeknél nem célszerű a '===' használata mert például ha ez a helyzet:" mondatrészen, és amit idéztem, emiatt totál az ellenkezőjét jelentette. Szóval nem volt kellően egyértelmű.
(#14180) PumpkinSeed :
szívesen. -
#14178
Sk8erPeter
nagyúr
Vision
#14164
Sk8erPeter
nagyúr
válasz
Vision
#14164
üzenetére
Pedig éppen neked linkeltem be korábban egy kissé eltérő esetet...
-
#14177
Sk8erPeter
nagyúr
PumpkinSeed
#14175
Sk8erPeter
nagyúr
válasz
PumpkinSeed
#14175
üzenetére
A kiíratásnál a FALSE érték castolódik empty stringre.
Két lehetőséged van: castolod kiíratás előtt integerre, vagy var_exportot használsz a boolean-érték kiíratására, igénytől függően.Példa a te kódodhoz igazodva:
print (int)$er1;
ekkor 0-t fog kiírni.
VAGY:
print var_export($er1, TRUE);
ekkor 'false'-t fog kiírni (mint string).
-
#14176
Sk8erPeter
nagyúr
DNReNTi
#14172
Sk8erPeter
nagyúr
válasz
DNReNTi
#14172
üzenetére
"$elso = 6;
$masodik = '6';
Akkor ez egyenlőtlenség lesz, mivel a $masodik egy string típusú változó, hiába 6 az is, de szöveg nem szám. Ezt megelőzendő perfekt a sima == kifejezés."Pont a lehető legrosszabb példát írtad, mert ez úgy, ahogy van, nem igaz.
Ebben az esetben az if($elso == $masodik) pont, hogy IGAZ lesz, mivel castolódik.
Éppen itt jön a képbe az, hogy csak az if($elso === $masodik) (lásd három egyenlőségjel, típusvizsgálattal) lesz csak HAMIS. -
#14158
Sk8erPeter
nagyúr
Vision
#14153
-
#14152
Sk8erPeter
nagyúr
Vision
#14151
Sk8erPeter
nagyúr
válasz
Vision
#14151
üzenetére
Ja, én is elég sokat szoptam vele még két éve pl. NuSOAP-pal, hogy sikerüljön úgy működésre bírni, hogy egy C#-os sima konzolos alkalmazás (SOAP-kliens) segítségével kommunikálni a SOAP-szerverrel:
http://stackoverflow.com/questions/6986350/generating-wsdl-with-nusoap-return-struct-with-various-types-int-string-arrNa, ilyenekre például nagyon nehézkes a PHP. Ugyanezt a feladatot C#-pal megoldani (legenerálni egy/több osztályból a WSDL-t, stb.) kb. 10 perc.
-
#14149
Sk8erPeter
nagyúr
Speeedfire
#14148
Sk8erPeter
nagyúr
válasz
Speeedfire
#14148
üzenetére
Most SOAP-ról beszélsz?
http://php.net/manual/en/book.soap.php -
#14135
Sk8erPeter
nagyúr
trisztan94
#14133
Sk8erPeter
nagyúr
válasz
trisztan94
#14133
üzenetére
Ha megnézed, a táblázatban 175x175px-es méretben jelenik meg, míg a kép maga 100x100px-es. Utóbbi önmagában nem baj (hogy ekkora a thumbnail), ha valóban akkora méretben kell, mert lehet vele spórolni a letöltendő adatot, de ha a jelentősen lebutított képet ennyivel felnagyítod, az már ilyen csúnya lesz. Ergo csak nagyobb méretben kell legenerálni a thumbnailt, maga a thumbnail készítésének módja ettől még nem biztos, hogy hibás.
-
#14109
Sk8erPeter
nagyúr
biker
#14107
Sk8erPeter
nagyúr
Most mi van? Excel-mezőbe akarsz berakni lényegében - kvázi - egy screenshotot? Nekem eléggé zavaros lett a végére, mert idekeverted az Excelt, a Mac-es Pages-t, szervert, kliensoldalt, és a hsz. végére már fingom sem lett, mi is a pontos cél (amit az elején még értettem, a végére már nem).
-
#14108
Sk8erPeter
nagyúr
trisztan94
#14106
Sk8erPeter
nagyúr
válasz
trisztan94
#14106
üzenetére
Nincs.
Amúgy sem triviális, hogy mi az, hogy "duplikált adat" a Te fogalmaid szerint... Ki tudja, mire gondolsz. Duplikált elég sok minden lehet. Komplett rekord egyezésére gondolsz? Vagy csak egy mező egyezésére? Nem mindegy. Mindenesetre query-t kell majd írnod, ne a PDO-nál keresd a mágiát. -
#14090
Sk8erPeter
nagyúr
trisztan94
#14088
Sk8erPeter
nagyúr
válasz
trisztan94
#14088
üzenetére
Huhh... A jogosultságokkal kapcsolatos javaslat még mindig nem jött át?
-
#14087
Sk8erPeter
nagyúr
CSorBA
#14079
Sk8erPeter
nagyúr
válasz
CSorBA
#14079
üzenetére
Azért annyiból mindenképp igaza van, hogy a példakódokat pont hülyebiztosra kellene írni, hogy akinél a short_open_tag ki van kapcsolva, annál is működjön a kód.
(#14085) Athlon64+ : +1.
-
#14068
Sk8erPeter
nagyúr
Speeedfire
#14067
Sk8erPeter
nagyúr
válasz
Speeedfire
#14067
üzenetére
De ne szívass már, hát a többiek pontosan erre javasoltak megoldásokat... Remélem, kandi kamerás átverés...
-
#14066
Sk8erPeter
nagyúr
Speeedfire
#14062
Sk8erPeter
nagyúr
válasz
Speeedfire
#14062
üzenetére
Most mi történt veled, delírium, aztán vissza a kezdetekhez?
(#14060) Petyyyyy :
Gondolom ők is értékelték azt az ominózus idézett írást. Azt a könyvet nem ismerem, de ha műszaki könyvtárból ki tudsz venni hasonlókat, akkor kísérletezz, borító alapján sajna nem lehet ítélni. -
#14051
Sk8erPeter
nagyúr
Petyyyyy
#14044
Sk8erPeter
nagyúr
válasz
Petyyyyy
#14044
üzenetére
"Ez azt jelenti, hogy a behelyettesítés mindenképpen megtörténik, még akkor is, ha az nem hajtódik végre (például egy olyan if utasítás törzsében, amelynek feltétele nem teljesül)."
Honnan szedted ezt a baromságot? Már hogy futna le egy nem teljesülő feltétel törzsében lévő kód? Már korábban is írtam, hogy ez lehetetlen. Különben mégis mi a frászra használhatnád a feltételes szerkezeteket, ha azok hatástalanok lennének? ============================
(#14047) trisztan94 :
"En az observer-t szoktam hasznalni java alatt, hasznalhato az php-val is? Esetleg valami ami jobb vele?"
Ahogy már írták, ez a kérdés úgy rossz, ahogy van. -
#14038
Sk8erPeter
nagyúr
Chrystall
#14037
Sk8erPeter
nagyúr
válasz
Chrystall
#14037
üzenetére
Nem vizsgálgattam túl sokat, de az nem túl jó, hogy pl. megtöröd a táblázatot azzal, hogy a záró </table> taget kiszeded. A többit nem néztem. Mindenesetre átmenetileg CSS-sel is eltüntetheted a formot, amíg rá nem jössz a végleges megoldásra.
Itt tuti tudnak segíteni (angol nyelven):
http://wordpress.stackexchange.com/ -
#14035
Sk8erPeter
nagyúr
Chrystall
#14034
Sk8erPeter
nagyúr
válasz
Chrystall
#14034
üzenetére
Sajnos nem ismerem a WordPress-t pluginfejlesztés szintjén, szóval ebben nem tudok segíteni. Drupalban úgy néz ki a moduláris felépítés, hogy a saját moduloddal/sminkeddel be tudsz avatkozni az adatok betöltésébe, az oldal kódjába, renderelésébe, egyebekbe különböző pontokon, az oldal különböző részeit felül tudod bírálni (amelyeket más modulok generáltak le), így a kódok szétválaszthatók és külön-külön fenntarthatóak maradnak, és egy modulfrissítés során nem törlődik mindenféle belenyúlásod. Feltételezem, van valami hasonló WordPress esetén is, de mondom, ezt a részét nem ismerem.
-
#14032
Sk8erPeter
nagyúr
DNReNTi
#14029
Sk8erPeter
nagyúr
válasz
DNReNTi
#14029
üzenetére
"A require() a szigorúbb. Betölti a fájlt abban az esetben is ha az egy nem teljesülő feltételben van"
Az lehetetlen.A többi amúgy stimmel, a lényeg nagyon röviden, hogy az include a fájl hiánya vagy más para esetén warningot okoz, a require fatal errort, a _once végű függvények pedig ugyanezt csinálják, csak annyi különbséggel, hogy valóban csupán egyszer töltik be a megadott fájlt.
(#14028) Petyyyyy
"Az egyikük minden alkalommal betölti az adott fájlt, a másik csak akkor, ha szükség van rá."
Az include_once(), require_once() függvényekre gondolsz, de ez így nem pontos, hogy csak akkor tölti be, ha szükség van rá, inkább akkor tölti be a fájlt, ha még korábban nem töltötte be (ergo mindenképp "szükség van rá", ha a kódban ezt mondod, de nem mindegy, hányszor).=============
Szerk.:
(#14031) kenwood :
ja, hogy így, OK. -
#14030
Sk8erPeter
nagyúr
Chrystall
#14025
Sk8erPeter
nagyúr
válasz
Chrystall
#14025
üzenetére
Ott kezdődik, hogy nagyon rossz ötlet közvetlenül belegányolni az ilyen pluginekbe, ha moduláris felépítésű a dolog, és saját pluginnel bele tudsz nyúlni az oldal megjelenésébe, akkor ott kell elintézni az ilyesmit, persze azt is odafigyeléssel. Ahogy már írták, simán lehet, hogy "elszáll" az oldal apró hibától is, azt nem tudhatjuk, mit ronthattál el.
(#14026) kenwood :
"nem tudom,hogyan nyultal bele a phpba,de az editort nem ajanlom,mindig ftpn keresztul erdemes modositani."
Ezt hogy érted? -
#14018
Sk8erPeter
nagyúr
Tele von Zsinór
#14013
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#14013
üzenetére
Ja tényleg, van ez a kukacos módszer is, kösz
-
#14012
Sk8erPeter
nagyúr
mobal
#14010
Sk8erPeter
nagyúr
"Archívum létrehozására mi a legjobb módszer? Hogyan tudnám legokosabban kinyerni a hozzászólásokhoz tartozó dátumból (int) az évszámokat, hónapokat?"
Na de most akkor melyik a kérdés? Mit értesz archívum létrehozása alatt?Dátumra:
http://php.net/manual/en/class.datetime.php
arra viszont figyelj oda, hogy a DateTime konstruktora NEM UNIX timestampet vár, de erre is van megoldás:
http://www.php.net/manual/en/datetime.settimestamp.php
(vagy inicializálás előtt konvertálod date()-tel...) -
#14006
Sk8erPeter
nagyúr
Speeedfire
#14004
Sk8erPeter
nagyúr
válasz
Speeedfire
#14004
üzenetére
Ez hogy jön ide? És ha ő a túrótortát jobban szereti, mint az almáspitét, akkor máris megvan a véleményed róla? Ez kb. ilyen szintű vita.
Egyébként elindult a szokásos Linux vs. Windows témában történő e-pénisz-méregetés, aminek keretében megint elhangzott pár vélemény, miszerint az a hozzáértő és vagány srác, aki terminálban pötyörészve állít be mindent (meg érted, az tök gizda, amikor valaki odanéz a monitorára, és csak karakteres felületet lát, és akkor olyan hozzáértőnek tűnik). Ha kattintgat, akkor biztos csak egy hülye egységsugarú vérpisti. Hagyjuk már ezt a hozzáállást, annyira lejárt és felesleges. Nyilván egy csomó webszerver esetén totál felesleges a GUI, ezért nincs is, az ügyes rendszergazda meg terminálból is tök jól tudja konfigurálni a dolgokat. De ez a rendszergazda nem lesz kevésbé ügyes, ha egy Windows-szerveren, az IIS Managerben, grafikus felületen állítja be ugyanazt, vagy hogy szándékosan pejoratívabban fogalmazzak, "összekattintgatja". IIS-t is lehet buzerálni akár konzolból, sőt, szerkesztgethetsz XML-fájlokat, ha jólesik, és nyilván sok esetben erre van szükség, de mivel van hozzá tisztességes grafikus felület, bizonyos módosításokhoz hidd el, hogy nem lesz kedved pötyörészni, amikor gyorsan megcsinálhatod ugyanazt a szemnek kellemesebb felületen.
(Évekig az Apache konfigfájljait buzeráltam, és nagyon nem hiányzik.) Sok minden meg bármelyik OS alatt épp scripteléssel, batch-fájlokon keresztül, stb. gyorsabb. Tök jó, ha valaki ezeket vágja, nagyon hasznos, sőt, sokszor nélkülözhetetlen, és sok feladat így nagyon felgyorsítható. Mindenki azt választja, ami adott feladatra neki a legkényelmesebb és leggyorsabb, meg nyilván ami adott, szerintem emiatt nem érdemes egymás torkának esni (és a végén már olyanokból ítélkezni, mint hogy kinek melyik grafikus felhasználói felület a tetszetősebb ). -
#13566
Sk8erPeter
nagyúr
ahetaton
#13559
Sk8erPeter
nagyúr
válasz
ahetaton
#13559
üzenetére
Egyelőre hagyd a francba JavaScriptes megoldásokat, első dolog, hogy legyen megoldva normálisan a szerveroldali validáció és feldolgozás, utána jöhet minden más kliensoldali szépítgetés. A required attribútum is csak HTML5-ös újítás, így olyan doctype-od is kell, hogy legyen, meg értelemszerűen a HTML5-öt nem támogató böngészőkben ez nem fog működni.
Azt kellene megoldanod, hogy amennyiben egy külön feldolgozó fájlban (lásd form elem action attribútumában lévő fájl) történik a form elküldött adatainak validálása, feldolgozása, akkor mondjuk ott átmenetileg egy session-változóba tedd a felhasználónak szóló figyelmeztetéseket, korábban kitöltött értékeket, majd az eredeti oldalra irányítsd vissza a felhasználót, ott írasd ki a figyelmeztetéseket, töltsd ki az űrlapot a korábban megadott adatokkal, majd töröld a session-változót. Tehát ennek az oldalnak a kiíratása ugyanaz, mint egyébként, csak pluszban ellenőrizned kell azt is, hogy adott session-változó az üzenetekkel, kitöltött adatokkal be van-e állítva, ha igen, kiíratsz mindent, kitöltesz mindent, ha nem, akkor pedig marad az üres form.
Ha azonos oldalon történik a validálás/feldolgozás, mint ahol a form is van (aminek mondjuk hátránya az F5 megnyomása során a böngésző figyelmeztetése, hogy biztosan el akarod-e küldeni újra az adatokat), akkor pedig értelemszerűen ugyanarra az oldalra rakod ki a figyelmeztetéseket, és újra kitöltöd a formot a kapott adatokkal (felhasználónak ne kelljen újra begépelnie). -
#13546
Sk8erPeter
nagyúr
Peter Kiss
#13545
Sk8erPeter
nagyúr
válasz
Peter Kiss
#13545
üzenetére
"Hiába raknak a Drupal alá Symfony2-t, amíg "bizonyos kódrészletek kompatibilitási okokból megmaradnak", magyarul a szarkupacból egy egész halom lesz. Nice move."
Jól van, látom rettenetesen sok értelme volt megírnom az előző bőbeszédű, lehetőleg a korábbinál jóval produktívabb, inkább alátámasztást célzó hozzászólásomat.
A lényege az előzőnek igazából pont az volt, hogy "csak azért is" indokból ne szarozzunk le egy rendszert, úgy beállítván, hogy "én úgyis sokkal szebbet, jobbat írnék". Lehet, hogy nem csak az általad írt csodarendszerekkel oldhatók meg webfejlesztési feladatok. Bocs, ha ezzel letörtelek. (Bár nem hiszem, hogy épp ettől csökkenne az ordító önbizalmad.)
Nem gondoltam volna, hogy egy érvre, amit direkt én hoztam fel, mint negatívumot, egyből lecsapsz, mint gyöngytyúk a takonyra. De örülök, ha ezek szerint szebbé tettem az estédet, mert ismét izomból fikázhattál valamit. Sikerült ismét értelmes irányba terelned a beszélgetést.Egyébként megkérhetnénk Parciékat, hogy tegyék egyszerűbbé a fórumozásodat, random generáljanak neked a szar/fos/nevetséges/dilettáns/gyökér/idióta/hülye/értelmetlen/komolytalan/ócska/... szavak valamelyikéből egyet a textarea-ba új hsz. megírásakor, hogy neked csak a mondatba ágyazás legyen a dolgod.
-
#13544
Sk8erPeter
nagyúr
Tele von Zsinór
#13541
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#13541
üzenetére
"Ha van időd és türelmed egy elég meredek tanulási görbére"
http://wiki.answers.com/Q/Does_a_steep_learning_curve_mean_learning_fast_or_slowly"In common (technically incorrect) usage, "steep learning curve" is meant to indicate that to learn the subject/technique takes a long time and is difficult. "
Én is így gondolom, de egyszerűbb volt belinkelni egy pont ezt részletesen kifejtő cikket, mint saját szavakkal leírni. Néha nagyon jól jön, ha az ember rákeres, mielőtt részletesen elkezd fejtegetni egy témát, valszeg már előtte leírták. -
#13543
Sk8erPeter
nagyúr
Peter Kiss
#13526
Sk8erPeter
nagyúr
válasz
Peter Kiss
#13526
üzenetére
"mikor nem tudtad elkapni a PDO-nak vagy minek a kivételeit"
Ez a "PDO-nak vagy minek" kicsit viccesen hangzott, mintha az valami szintén nagy szar lenne. -
#13542
Sk8erPeter
nagyúr
Peter Kiss
#13505
Sk8erPeter
nagyúr
válasz
Peter Kiss
#13505
üzenetére
Sorry, csak most tudok reagálni, kissé leterhelt vagyok mostanság.
Nem, a szavaimat picit kiforgattad, nem azt mondtam, hogy a CMS-készítők mindent jobban csinálnak. Ha félreérthető volt, amit írtam, és mégis így lehetett értelmezni, akkor elnézést, nem így értettem.
A "CMS-készítők" elég fura kategória. Pontosabban elég tág. Felhasználói visszajelzések, patch-ek alapján is javítgatnak egy elég komplex rendszert, így aztán esélyes, hogy gyorsabban megoldanak olyan felmerülő problémákat, amikkel esetleg a saját rendszerednél csak később találkozol, és esélyes, hogy bevált gyakorlatokat fognak alkalmazni, mert ha nem, akkor sanszosabb, hogy többeknél kib@ssza a biztosítékot, akik mondjuk igencsak helytelenítik az adott módszert. De ha belegondolsz, az open source frameworkök továbbfejlődésének is ez az egyik forrása, igazából nem kell ehhez nagyon pátoszos mondatokat hangoztatni, hogy a "közösség ereje", meg hasonlók, mert van mögötte bőven tartalom. Ilyen alapon a "közösség ereje" dönt a Stack Overflow-n és hasonló fórumokon is (majd a közösség eldönti, hogy valaki egy rakás szart rakott fel, vagy jó a válasza).
Ettől függetlenül persze simán lehet, hogy adott feladatot ezerszer jobban oldod meg, mint ahogy a CMS vagy más, közösség által fejlesztett cucc (ne korlátozzuk CMS-re, mert ez a topicban mint látom, szitokszó lett) adott részében sikerült (csak hogy feltételes dicséret is legyen), de az is lehet, hogy ugyanazt a végeredményt lassabban sikerül elérned, vagy adott hibaforrás jóval később derül ki. Igaz, publikus sem lesz, így a hiba kihasználása is kissé nehézkesebb lesz egy csúnyabácsi által."Láttad te már a Drupal forrását? A modulokét? Szerinted normális emberek csinálták?"
Igen, láttam a forrását, valószínűleg sokkal többet nézegettem már, mint Te. Egyetértek azzal, hogy ez a régi procedurális örökség így teljesen lecsupaszítva, egyszerűen megközelítve egy hányadék. De ez a PHP 4-es időkből maradt fenn, nem két perc váltani. De ugye vágod, hogy a 8-as Drupal Symfony-alapokon fog futni? (Pontosabban fut, a jövő időt azért használom, mert a stable megjelenéséig nyilván bőven van még mit csiszolni.) Persze bizonyos kódrészletek kompatibilitási okokból megmaradnak, ez annyira nem meglepő. Igaz, személy szerint jobban támogatnám a teljes korábbi örökségek kukába való kib@szását, hogy ne kelljen csúf kódrészletekkel találkozni pusztán kompatibilitási okokból, de egy ilyen radikális lépés valszeg elég sokaknak elég fájó lenne. Normális emberek csinálták, alkalmazkodva az adottságokhoz. Cikk: Drupal programming from an object-oriented perspective.
Egyébként szerintem megőrülnél, ha C-ben programoznál, hogy tisztán (nem kerülő megoldásokkal) nem tudnál OOP-ben programozni, mert egyszerűen nem adottak rá a lehetőségek. (Vagy például más nyelven, de az adott környezetben túl sok overheadet jelentő objektumorientáltság túl nagy luxus lenne, így az nem lenne használható.)
Na, de visszatérve a lényegre: szerinted a Symfony is egy szar? Hogy a Drupal jövőjét boncolgassuk.Csak még egyszer, a tisztánlátás érdekében, hogy ne tarts elvakultnak: látom sok helyen a Drupal forráskódjában, hogy bőven van mit javítani, igen, vannak rettenet szar megoldások is, és alapvetően én is jobban örülnék egyébként tisztán objektumorientált szemléletnek, de nem mondom minden NEM OOP-s kódra azt, hogy az úgy szar, ahogy van. Ebben valószínűleg amúgy sem értünk egyet, ahogy eddigi kommentjeidből leszűrtem (ha valami nem OOP, akkor csakis egy fos lehet), így erről nem is próbállak meggyőzni. De ha nagy általánosságban kijelented mindenről, ami Drupal, hogy nem normális dilettáns gyökerek írták, akkor valószínűleg picit szemellenzősen állsz a dolgokhoz, meg nem láttál még egész jól megírt modulkódot (értsd: egy modult sem feltétlenül kell azonosítani a teljes Drupal-kóddal (próbálkozások alapvető OOP-szemlélet Drupalba való beleerőszakolására), bár való igaz, a hookok rendszere miatt van egyfajta megkötöttség). Nem szeretnék példálózni, mert nincs kedvem a végeláthatatlan fikázásokhoz, biztos vagyok benne, hogy bármiben találnál fogódzót saját érved alátámasztására (t.i. hogy a Drupal szted szar, ha törik, ha szakad).
Inkább én lennék már kíváncsi arra, hogy van-e egyáltalán olyan rendszer, olyan kód, amit dicsérsz, amit elfogadsz hibáival együtt? (Van olyan kód, amiben nincs hiba? A kérdés költői.) Komolyan, mindenféle rossz szándék nélkül, nem nagyon láttam még tőled olyan kommentárt, amiben valamit tényleg dicsérnél. Általában a szarkasztikus, rendkívül lefitymáló kommentek voltak a jellemzők (mármint kivéve a saját kódjaid kapcsán), szívesen látnék tőled olyan dolgot, amit dicsérsz. Most ezt tényleg nem köcsögösködésből mondom, hanem az eddig látottak alapján. Az utolsó bekezdésedből is ez derül ki.
Ja, még annyi, hogy az általad említett problémákra egészen biztos, hogy van Drupalban is megoldás, csak ismerni kell a megfelelő modulokat. Én is meg szoktam lepődni a fórumokat böngészve, hogy milyen modulok léteznek, amikről addig fingom sem volt, mégis egész korrekten lettek megoldva. Ha konkrét problémát kell megoldani, rá kell kérdezni mindre drupal.hu-n, drupal.org-on, vagy főleg a Stack Exchange családba tartozó Drupal Answers-ön. Tuti érkezni fog rá valamilyen kész javaslat. Jó, van ezernyi igény, amire egész pontosan adott modul nem lett kitalálva. Viszont az is elképzelhető, hogy olyan, aki tényleg átlátja a Drupal működését, meg jó modulokat tud írni, az sokkal gyorsabban elkészíti a feladatot, mint más egy saját rendszerben. Az is lehet, hogy nem. Teljesen egyén- és igényfüggő, ahogy máskor sem, ebben sem érdemes általánosítani. Tehát azt sem lehet kijelenteni, hogy egyedi rendszerben minden könnyebben megoldható. Attól függ.
A CMS-ek összes nyűgjét-baját szerintem sokan látják, akik a topicban aktívan tevékenykednek (pl. túlzott erőforrás-igény egy saját rendszerhez/komoly keretrendszerhez képest), én is, és lehet, hogy a dumámtól függetlenül a CMS szitokszó marad, de azért legalább megpróbáltam.
Kulturált reakciót viszont szívesen olvasok, mert maga a téma érdekes, nem kell, hogy ebből flamewar legyen (bár már az). -
#13503
Sk8erPeter
nagyúr
Coyot
#13502
Sk8erPeter
nagyúr
"ragaszkodsz is hozzá foggal körömmel"
Hát pont nem, ne fordítsd már ki a szavamat, ha kérhetem.
Ti kezdtetek el nagyon vicces érveket felhozni amellett, hogy márpedig ez NEM megoldható CMS-sel, és jöttek a gyökérségek, hogy dehát az nem olyan rugalmas, mint a saját ki tudja milyen tákolmányom. Erre reagálva elmondtam, hogy ez nem így van. Nem én ragaszkodom hozzá foggal-körömmel, arra hívtam fel a figyelmet, hogy nem kell a kérdéshez szemellenzősen állni.
De nyilván mindent ki lehet forgatni."egyáltalán nem user friendly az adminisztrációs felület"
Látszik, hogy nem ismered. Olyan felületet tolsz ki a megfelelő jogosultságokkal a júzernek, amilyet akarsz, hogy még a szomszéd Mari néni is megértse. Minden lószarba belenyúlhatsz. (Jó, nyilván korlátokkal.)"Más kérdés hogy jön egy exploit hullám és végigcseszik az összes oldalát "
Na ez Drupalra pont nem nagyon jellemző: ha megnézed az osztott tárhelyek blogjait, általában a WordPress és Joomla jön ki vesztesen. Ez most nem elfogultság, hanem ez a tendencia."az ügyfeled megoldást fog várni, nem mondhatod azt neki, hogy várjál majd a közösség megoldja"
Hát bakker, megoldod te, nagyon nagy rejtély. Pl. csinálsz egy patch-et, amivel megoldottad magadnak, aztán a modul issue queue-jában szépen nyitsz egy új issue-t, ha még nincs megemlítve a szóbanforgó bug, és feltolod a patch-edet, amit ha megfelelően írtál meg, committolnak is. Máris hozzájárultál valamivel az ilyen jellegű közösségi fejlesztésekhez. Ez nem egy magasztos f@szság, hanem működő dolog.Én nem mondtam egy szóval sem, hogy ne tedd a saját rendszeredet a fejlesztendő rendszer alá, ha jól működik, bevált, bizonyított, akkor tegyed, nyilván. De ne kezdjük már el terjeszteni a hülyeségeket, mert az senkinek sem jó. Főleg ne legyünk szemellenzősek.
-
#13501
Sk8erPeter
nagyúr
Vision
#13500
Sk8erPeter
nagyúr
válasz
Vision
#13500
üzenetére
De igen, meggyorsítja, csak ismerni kell a megfelelő modulokat. Facebook-integráció miért olyan nagy dolog? Nagyon jó és folyamatosan fejlesztett modulok vannak erre a célra Drupalban. Videótutorialokat is kap az ember, ha akar.
A reszponzív dizájn, mobilos skin megint nem értem, miért is lenne ellenérv. Erre pedig normálisan kommentezett, igényes, könnyen átszabható alapsminkek vannak.
Ez pont egy olyan feladat, aminek az összes pontjára alkalmas lehet egy CMS. Mint említettem, csak ismerni kell a rendelkezésre álló eszközöket, és főleg nem ismeretek hiányában (szemellenzősen) nyilatkozni valamiről. -
#13499
Sk8erPeter
nagyúr
Coyot
#13498
Sk8erPeter
nagyúr
"egy ilyen feladat megoldására, mint ami a példa is volt ennél is saját modulokat kell írnod, ami nem teszi épp átláthatóvá a rendszert"
Hogy mi van? Nem értem az érvet: nem mindegy, hogy a saját rendszeredben írod meg akárhogyan, vagy egy modult készítesz a feladatra? 
(És akkor ez egy "erre a feladatra írt motor" lesz...) Egyébként pont Te magad mondtad most, hogy nincs se rövid, se hosszú távú modulfejlesztési és -felhasználási tapasztalatod Drupallal (és gondolom ugyanígy Athlon64+-nak sincs, de ő szeret amúgy is szélsőségesen nyilatkozni), tehát akkor így nehéz vitába szállni, ha úgy írsz le valamit, hogy még sosem volt vele dolgod.
Modulok szűrésére is van mód. Igen, éles rendszernél sok modulod lesz: épp ezért moduláris a rendszer, ami nem kell, azt ki tudod kapcsolni. Ergo az sem kér erőforrást.
Igen, a Drupal egyébként nem egy két perc alatt megtanulható valami. De nem is csak egy blogolásra kitalált valami. -
#13497
Sk8erPeter
nagyúr
Coyot
#13496
Sk8erPeter
nagyúr
* sigh * De jó lenne már végre valami értelmesen alátámasztott érvet is olvasni, nem csak a berögzött klisészerű hülyeségeket. Legalább olyat, amiből az derül ki, hogy az illetőnek volt dolga már ilyennel.
Egészen evidens, hogy egy saját rendszert te formálgatsz, buzerálod, írogatod, szép lassan egyre nagyobbra nő, rájössz, hogy na, most már valami frameworkszerű működést kellene kialakítani, bizonyos keretek közé szorítani, MVC-szerű működést kreálni, lám, egy pár év b@szkurálás után felfedezed a spanyolviaszt, létrehozol valami olyasmit, amit mások már megcsináltak helyetted, csak valószínűleg sokkal jobban. Most a lényeg szempontjából teljesen mindegy, hogy egyelőre egy nagyobb szabadságot adó keretrendszerről vagy egy valamelyest kötöttebb CMS-ről beszélünk. Tök jó, hogy kreáltál egy saját rendszert, de aztán mindenféle plusz módosítás plusz macerát igényel, és nincs egy igen nagy közösség mögötte, akik javítják a hülyeségeidet. Tehát nem vitás, hogy saját rendszert úgy formázol, úgy tákolsz vele, ahogy csak akarsz. De nehogy már a bizonyos szabályok betartását megkövetelő rendszereket azért ne használjuk, mert akkor nekünk márpedig alkalmazkodni kell, vagy külső dokumentációt olvasni. Valóban tragédia.
Igen, előnye is van, más nem lát bele a kódodba. Igen, pontosan tudod, hogyan fejlesztetted, a legapróbb részletekig ismered. Kérdés, megtérül-e az a jópár év befektetés, amíg igazán stabillá alakítod a saját rendszeredet.Na, de még vakerászhatunk oldalakat a szokásos klisékről, de a baj az, hogy a konkrét feladatra egyikőtök sem támasztotta alá normálisan, miért is ne lenne alkalmas egy igényesen létrehozott, pont a foglalás célját betöltő modul. Lehet, hogy ismernetek kellene a kritizált rendszert, és nem csak orrfennhordós módon hozzáállni mindenhez, amit nem ti hoztatok létre.
-
#13495
Sk8erPeter
nagyúr
Peter Kiss
#13494
Sk8erPeter
nagyúr
válasz
Peter Kiss
#13494
üzenetére
A szokásos jól alátámasztott, rendkívül meggyőző érv. -
#13493
Sk8erPeter
nagyúr
Peter Kiss
#13492
Sk8erPeter
nagyúr
válasz
Peter Kiss
#13492
üzenetére
"Egy belvárosi ~40 szobás panzió számára" miért is nem lehetne megfelelő?
Feltételezem, nem óriási forgalomnak lenne kitéve. Nagy forgalomnál valami nagyon minimál CMS lehet a megfelelő, hogy optimalizálni lehessen, és ne legyen a CMS által kínált sallangokkal annyira terhelve.
Persze az is kérdés, pusztán előítéletből nyilatkozol, vagy használtál is már valami normális CMS-t, igényesen megírt modulokkal. -
#13491
Sk8erPeter
nagyúr
Peter Kiss
#13489
Sk8erPeter
nagyúr
válasz
Peter Kiss
#13489
üzenetére
Azért egy CMS esetén talán ennél olcsóbban is ki lehet hozni, vannak foglalós modulok, meg reszponzív sminkek, meg mobilra optimalizáltak is; bár igaz, nyilván van egy alapára, de pontos igénytől, specifikációtól függ sztem, valóban 2 misi lesz-e a vége...
De végül is simán el lehet menni odáig is.Erről most az jutott eszembe, hogy egyszer egy volt főnökömhöz jött valaki, de épp nem volt ott, így addig is velünk beszélte meg, mit szeretne, mondta, hogy árajánlatot szeretne kérni egy ingatlan.com-hoz hasonló oldalra. Lehessen ugyanúgy szépen szűkíteni és rendezni a keresést, legyenek szép galériák, térképbeágyazás, lájkgombok, bejelentkezés, regisztráció, mindenféle adat nyilvántartása, ehhez tartozó komplex admin-felület, lájk-gombok, apjaf@sza. Aztán a legvégén hozzátette, hogy nagyon reméli, hogy mi itt megoldjuk neki úgy 35 ezer Ft környékén, de max. 40-et szánna rá.
Hát nem bírtuk ki röhögés nélkül. Pont ilyen árakon vesztegetik az ilyen oldalakat... -
#13479
Sk8erPeter
nagyúr
Speeedfire
#13474
Sk8erPeter
nagyúr
válasz
Speeedfire
#13474
üzenetére
NetBeans memóriaigényét is tudod korlátozni:
http://stackoverflow.com/questions/1557883/how-to-reduce-netbeans-memory-usage -
#13478
Sk8erPeter
nagyúr
Tele von Zsinór
#13476
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#13476
üzenetére
Nem szedték ki.
http://social.technet.microsoft.com/wiki/contents/articles/910.how-to-enable-telnet-client-in-windows-7.aspx
Nálam nincs engedélyezve, de lehetne:
-
#13475
Sk8erPeter
nagyúr
Tele von Zsinór
#13471
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#13471
üzenetére
Nyilván van Task Scheduler Windows 7 alatt is (és feljebb is lesz), miért szedték volna már ki?
"Így futó webszerverre sem lesz szükséged."
Ez így oké, de később azt írod, wget http://localhost/foobar.php-vel kéne ütemezni; most lehet, hogy félreértem, amit írsz, de ez hogy működne futó webszerver nélkül?
Vagy azt ettől függetlenül írtad, hogy arra rávilágítva, hogy nem feltétlenül kell proxy script? -
#13466
Sk8erPeter
nagyúr
Blue@X
#13464
-
#13463
Sk8erPeter
nagyúr
Blue@X
#13462
Sk8erPeter
nagyúr
válasz
Blue@X
#13462
üzenetére
Attól függ, az adott űrlapnál neked GET- vagy POST-metódusra van szükséged, mindkettővel átmegy az adat... a szervered meg egyébként csak megkapja az adatokat, a kliensed "viszi át", de inkább küldi el a szervernek a megfelelő adatokat a megfelelő metódussal a HTTP-protokoll használatával. Tehát inkább az a kérdés, hogy a szervered hogyan kapja meg az adatokat, és az melyik tömbből elérhető: ha GET-metódust használsz a formnál, akkor a $_GET tömbből, ha POST-metódust használsz, akkor a $_POST tömbből. A $_SESSION-nek itt még ebben nincs szerepe, az más tészta (pl. adott munkamenet erejéig tárolni akarsz valamilyen adatokat a kliensről).
-
#13453
Sk8erPeter
nagyúr
Speeedfire
#13452
Sk8erPeter
nagyúr
válasz
Speeedfire
#13452
üzenetére
Hát most ebben a kérdésben nem tudok igazságot tenni.
-
#13451
Sk8erPeter
nagyúr
Peter Kiss
#13450
Sk8erPeter
nagyúr
válasz
Peter Kiss
#13450
üzenetére
De nem értem, ez most javaslat akart lenni, hogy használja azt?
Mert akkor tényleg nem értem még mindig, miért lenne az neki jó... -
#13449
Sk8erPeter
nagyúr
Peter Kiss
#13447
Sk8erPeter
nagyúr
válasz
Peter Kiss
#13447
üzenetére
Itt miért kéne már htmlentities()?
-
#13441
Sk8erPeter
nagyúr
Peter Kiss
#13440
Sk8erPeter
nagyúr
válasz
Peter Kiss
#13440
üzenetére
Akkor másképpen fogalmazok: kezdő ne akarjon adatbázis-wrappert csinálni, mert csak egy katyvasz lesz belőle.
Meg amúgy is Dunát lehet rekeszteni az ilyenekkel. -
#13434
Sk8erPeter
nagyúr
Speeedfire
#13431
Sk8erPeter
nagyúr
válasz
Speeedfire
#13431
üzenetére
"Hogy fordítva?"
Úgy, hogy nem az Oracle-fejlesztőknek kell ráfeküdniük izomból a PHP-val való együttműködésre, hanem a PHP fejlesztőinek... -
#13433
Sk8erPeter
nagyúr
pvt.peter
#13428
Sk8erPeter
nagyúr
válasz
pvt.peter
#13428
üzenetére
Igazából azt pötyögted be, ami kommentekben is megtalálható, túl sok új nincs benne. Ez a query1(), query2() elég mágikus név, mit akarsz vele megvalósítani? Mindenesetre már az elnevezés is rossz. De legfőképp az, hogy fel akarod fedezni a spanyolviaszt: ne akarj n+1-edik adatbázis-kommunikációs wrapper osztályt csinálni, ott a mysqli és a PDO, valamint remek ORM-ek vannak. Írtad, hogy a mysql_ függvények használatára vagy kényszerítve, de ezt az érvet sajnos nem tudjuk elfogadni.
Tehát minimum mysqli vagy PDO, a mysql_ kezdetű függvények használatáról 2013-ban már nincs is értelme beszélni.
Volt már korábban itt egy (v. több) hitvita a topicban, hogy Singleton-minta jó-e vagy sem, a vége az lett, hogy több érv szól a nem mellett (itt olvashatsz róla többek közt: [link], meg persze a topicban, a Singleton szóra rákeresve). -
#13427
Sk8erPeter
nagyúr
Speeedfire
#13426
Sk8erPeter
nagyúr
válasz
Speeedfire
#13426
üzenetére
"De ha gondolod próbáld rekonsturktuálni oracle alatt pdo-val ezt a dolgot, mert kíváncsi lennék rá."
Milyen dolgot? Én már az elejére sem emlékszem.Igazából csak arra lettem volna kíváncsi, rájöttél-e, hogyan bírálhatod felül a Yii erőszakos kivételkezelését, mert úgy tűnt, nem tudod elkapni a keletkező kivételt, mert már előbb kitolja a kimenetre a Yii, ami gáz.
"Egyszerűen az oracle nem akarja támogatni a pdo-t. "
Nem fordítva kéne, hogy legyen a fejlesztési irány? -
#13422
Sk8erPeter
nagyúr
Speeedfire
#13406
Sk8erPeter
nagyúr
válasz
Speeedfire
#13406
üzenetére
sikerült azóta rájönni, mi a para?
-
#13421
Sk8erPeter
nagyúr
Andoidtibi
#13418
Sk8erPeter
nagyúr
válasz
Andoidtibi
#13418
üzenetére
Amit most csinálsz:
egy <table> elembe 15-ször kiíratod egy <ul>-be az aktuális elemet.
Ez szintaktikai hiba (meg nem a feladatnak megfelelő): <table> elemen belül ezek lehetnek:
http://www.w3.org/TR/html-markup/table.html.
Tehát <table> után jöhet egy <caption>, <colgroup>, <thead>, <tbody> vagy <tfoot> elem, vagy esetleg egyből a <tr> (táblázat sora), ami pedig <td>-(ke)t (táblázat oszlopa) tartalmazhat.
De <ul> semmiképp sem következhet egyből. Ezenkívül az <ul> elemen belül csak <li> elemek szerepelhetnek.
Itt van egy egyszerű 3 oszlopos, 3 soros táblázat, a felső sor a fejléc:
http://jsfiddle.net/JH48Z/amit Te szeretnél, annak a kimenete így néz ki szintaktikailag helyesen:
http://jsfiddle.net/JH48Z/1/
vagy <tbody> nélkül is jó:
http://jsfiddle.net/JH48Z/2/Na, tehát ennek megfelelően kell kiíratnod, ez az első, amit végig kell gondolnod. Próbáld meg az összes lépést egyesével végiggondolni, akár papírra is leírhatod, ha úgy egyszerűbb (algoritmizálj).
Először ki kell íratni a <table> elemet (majd a végén, a tartalom bepakolása után le kell zárni). Aztán jön a <tr>, most csak egy sort szeretnél, tehát akkor ezt csak egyszer kell kiíratnod, majd ebbe kerül majd a 3 <td>, a <td>-ken belülre pedig az 5-5 listaelem (<ul><li>...</li></ul>). De hülyebiztosra kell elkészítened a kódot, számítani arra, hogy a tömb elemeinek száma változni fog. Pl. működjön úgy is, ha csak 10 elemed van, meg akkor is, ha 632.
Most vegyük azt, hogy mindenképp azt szeretnéd, hogy mindig legyen 3 oszlop, és mindig 5 elemet írjon az adott oszlopba, már ha van annyi (ha már nincs annyi, akkor a maradékot pakolja bele az aktuális cellának aktuális listájába).
Ha tök általánosan akarod megoldani, lesz három ciklusod egymásba ágyazva. Egyikben kiírod a szükséges számú sort (itt most 1, de lehetne jóval több is), a benne lévő ciklusban a szükséges számú cellát (itt 3), az azonbelül lévő ciklusban pedig a listaelemeket íratod ki.
Amire szükséged lesz, a felső egészrész egyszerű kiszámítására vonatkozó függvény: ceil()Egy elég általános megoldás, amit gyorsan bepötyögtem, kipróbáltam, jó:
$elementsArray = array("Egy","Kettő","Három", "Négy" , "Öt" , "Hat" , "Hét" , "Nyolc" , "Kilenc" , "Tíz", "Alma" , "Dió" , "Mák" ,"Körte" , "Cseresznye"
, "asd", 'asd', 'qwe', 'retkljwer', 'xycbm'
);
$nrOfElements = count($elementsArray);
// szükséges listaelemek száma
$nrOfNeededListElements = 5;
// szükséges oszlopok száma
$nrOfNeededColumns = 3;
$nrOfNeededRows = ceil($nrOfElements/($nrOfNeededListElements*$nrOfNeededColumns));
// $nrOfCellsToFill = ceil($nrOfElements/$nrOfNeededListElements);
$nrOfElementsPrinted = 0;
echo '<table class="list-items-table">';
for($row = 0; $row < $nrOfNeededRows; $row++){
// sor
echo '<tr>';
for($cell = 0; $cell < $nrOfNeededColumns; $cell++) {
// <td>-t mindenképp kiírjuk, üresen is (bár elvileg nem feltétlenül muszáj)
echo '<td>';
// akkor írjuk csak ki az <ul>-t, ha szükséges
if($nrOfElementsPrinted < $nrOfElements) {
echo '<ul class="list-items">';
for($i = 0; ($i < $nrOfNeededListElements) && ($nrOfElementsPrinted < $nrOfElements); $i++) {
echo '<li>';
echo $elementsArray[$nrOfElementsPrinted];
echo '</li>';
$nrOfElementsPrinted++;
}
echo '</ul>';
}
echo '</td>';
}
echo '</tr>';
}
echo '</table>';Azért jó, hogy általános, mert változtathatod benne ezt a két változót:
$nrOfNeededListElements = 5;
$nrOfNeededColumns = 3;így az elsővel meghatározhatod, hány listaelemre lesz szükséged (neked most 5 kellett), a másodikkal pedig azt, hogy hány oszlopra van szükséged (itt 3). Ha átállítod másra, úgy is működőképes.
Itt láthatod, mi lesz a kimenet (egy sorba pakolja, ezzel most nem foglalkoztam, hogy legyen elválasztva a kódban sortöréssel - lásd PHP_EOL):
Ergo így fog kinézni, ide bemásoltam a kimenetet:
http://jsfiddle.net/JH48Z/3/ -
#13404
Sk8erPeter
nagyúr
Speeedfire
#13399
Sk8erPeter
nagyúr
válasz
Speeedfire
#13399
üzenetére
Ebben a formában azért ez elég furcsa... Nem is tudod felülbírálni? Mert ez alapján olyan, mintha komolyabb hibákra nem dobhatnál egy szép felhasználóbarát hibaoldalt, hanem majd a Yii szépen megmondja, hogy itt aztán gáz van, de feltételezem, azért ezt megoldották valahogy, elég régi keretrendszerről van szó...
-
#13403
Sk8erPeter
nagyúr
don.racz
#13400
Sk8erPeter
nagyúr
válasz
don.racz
#13400
üzenetére
Sok szerencsét hozzá, de azért ez itt nem így működik. Inkább úgy, hogy leírod szépen a komplett problémát, mutatsz példakódot, megmutatod, mire jutottál eddig, aztán megpróbálunk segíteni. De a fórum nem privát segítség-megoldásokra, meg egyéni Skype-olásokra való. Tiszteld mások szabadidejét is.
-
#13392
Sk8erPeter
nagyúr
spammer
#13390
-
#13384
Sk8erPeter
nagyúr
spammer
#13383
Sk8erPeter
nagyúr
válasz
spammer
#13383
üzenetére
Jaja, jól teszed, az úgy a legjobb.
Most látom, már én is megzavarodtam, és szintén RewriteEngine-t írtam RewriteRule helyett
Mindjárt szerkesztetem egy modival az előzőt, hogy ne ez maradjon benne.www.example.com/articles/110/ez-egy-nagyon-erdekes-cikk
erre meg valami ilyesmi illeszkedik:
RewriteRule ^(\w+)/(\d+)/(.+)$ index.php?page=$1&id=$2 [QSA,L]
(itt a 3. részt, tehát az "ez-egy-nagyon-erdekes-cikk" stringet nem vettem figyelembe, mert a struktúrád szerint az most nem is kell)
-
#13382
Sk8erPeter
nagyúr
spammer
#13381
Sk8erPeter
nagyúr
válasz
spammer
#13381
üzenetére
Úgy, hogy olyan regexpet használsz a RewriteRule-nál, ami a számokra illeszkedik, a "view" szócskát meg "beledrótozod".
Pl. ilyesmi:
RewriteRule ^(\d+)$ index.php?page=view&id=$1 [QSA,L]Ez illeszkedik arra, amit írtál. A \d minden numerikus karakterre illeszkedik. A +-szal pedig azt várod el, hogy egy vagy több ilyen minta legyen a stringben (tehát szerepelhet benne simán 9 vagy 6432 is). A ^ a string kezdetét jelöli, a $ pedig a legvégét, azért jó jelen esetben így korlátozni, mert pl. nem illeszkedik arra a mintára, hogy "a321b" vagy "a321" vagy "321b".
De egyébként érdemesebb beszédes neveket használni az URL-nél, pl. ilyesmi:
www.example.com/articles/110/ez-egy-nagyon-erdekes-cikkRegExp tesztelésére tudom ajánlani többek közt ezeket:
http://regexpal.com/
http://gskinner.com/RegExr/
utóbbi Flash-alapú, de nagyon beszédes segédlet van hozzá. Mindkettő ajánlott.[ Módosította: BomiBoogie ]
-
#13376
Sk8erPeter
nagyúr
spammer
#13373
Sk8erPeter
nagyúr
válasz
spammer
#13373
üzenetére
Igazából mi a nem szimpatikus rajta?
Hogy nem olyan egyszerű, mint a lepkefing? Amúgy sokszor CMS-eknél/frameworköknél azt csinálják, hogy minden URL-t ráfuttatnak az index.php-re, fix query stringként (pl. index.php?q=adsasd/123/asd), aztán az adatbázisban az URL aliasok táblájában keresik meg a kapott query stringet, és ez van leképezve az alkalmazás működésének megfelelő "valós" címekre.
De az általad linkelt módszer is teljesen jó. -
#13347
Sk8erPeter
nagyúr
spammer
#13345
Sk8erPeter
nagyúr
válasz
spammer
#13345
üzenetére
"Azzal működött, nem az volt a probléma, hanem hogy simán beírva a $dest vagy $dest2 nem ment."
Pedig de, az probléma, amit írtam.
Nézd meg még egyszer ezt a stringet:
'origins=04429&destinations=$dest&mode=driving&units=imperial&sensor=false'
mint látható, sima aposztrófot használsz, így a $dest nem fog behelyettesítődni, még jó, hogy rossz eredményt kapsz, mert így küldi el a szervernek: destinations=$dest, ahogy van (szóval a szerver a $dest-et kapja értékül).
Amúgy Te magad mondtad, hogy nem működött úgy.<form id="destCalc" action="<?php echo $_SERVER["PHP_SELF"]; ?>" method="post">
itt ez az echo-zás tökéletesen felesleges.
Ezt nyugodtan cseréld le így:
<form id="destCalc" action="" method="post">
az üres action pont azt csinálja, hogy önmagára küldi el a formot.
Mondjuk gondolom azt vágod, hogy ennek megvan az a hátránya, hogy a böngésző cs×szeget F5 nyomkodásakor, hogy biztos el akarod-e küldeni még egyszer a POST-adatokat.Amit viszont most nem értek, hogy miért POST-metódussal küldöd el az adatokat, amikor korábban GET-et használtál. Így nem is merülne fel az a probléma, amit az előbb említettem.
"oldalfrissítés nélkül betöltse a php kódot (hogy lássam az eredményt)"
Ezt most nem egészen értettem. Mit is szeretnél?Ha jQuery+AJAX témáról van szó, akkor javaslom a jQuery topicot. A PHP-része persze jöhet ide, mindenesetre hint: json_encode()-dal küldd vissza a kliensnek az adatokat, úgy lesz a legkönnyebb kezelni.
-
#13344
Sk8erPeter
nagyúr
sebastien19
#13338
Sk8erPeter
nagyúr
válasz
sebastien19
#13338
üzenetére
JavaScripttel lehet ellenőrizni, hogy milyen gomb lett lenyomva a billentyűzeten vagy az egéren, erre korábban írtam egy szemléltető kódot, amit itt ki tudsz próbálni:
http://jsfiddle.net/Sk8erPeter/EAjYe/A baj viszont az, hogy elvileg az event object módosítható, meghamisítható, így talán csak a másodpercenkénti irreálisan magas kattintásszámot tudnád kiszűrni kliens- és szerveroldalon egyaránt. Na, hogy ez mennyi, az már jó kérdés.
-
#13329
Sk8erPeter
nagyúr
Sk8erPeter
#13328
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#13328
üzenetére
még annyi, hogy ha nem akarod kiíratni a fejléceket, akkor kommenteld ki ezt a sort:
curl_setopt($handle, CURLOPT_HEADER, true);
ezután így használhatod könnyedén:$json_decoded_data = json_decode($result);
echo $json_decoded_data->pool_name; -
#13328
Sk8erPeter
nagyúr
#68216320
#13322
Sk8erPeter
nagyúr
válasz
#68216320
#13322
üzenetére
Ilyenkor érdemes megnézni a visszatérési értékeket, és ha gond volt, akkor megnézni a hibát, pl. a Te kódodnál valahogy így:
$result = curl_exec($handle);
if($result === false){
echo 'Curl error: ' . curl_error($handle) . '. Curl error no.: '. curl_errno($handle);
}
else {
..................
}a hibaüzenet pedig ezt fogja írni:
"SSL certificate problem, verify that the CA cert is OK. Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed"
(hibakód: 60)Ezt a hibát pedig ez fogja megoldani:
http://stackoverflow.com/questions/6400300/php-curl-https-causing-exception-ssl-certificate-problem-verify-that-the-ca-cer/10566962#10566962curl_setopt($handle, CURLOPT_SSL_VERIFYPEER, false);
Viszont figyelj a biztonsági problémára, amire a linkelt hsz.-ben felhívják a figyelmet.
-
#13295
Sk8erPeter
nagyúr
Brown ügynök
#13294
Sk8erPeter
nagyúr
válasz
Brown ügynök
#13294
üzenetére
Nem is úgy értettem, hogy a motorba nyúlj bele.
-
#13293
Sk8erPeter
nagyúr
Brown ügynök
#13292
Sk8erPeter
nagyúr
válasz
Brown ügynök
#13292
üzenetére
Miért is nem játszanak? A request feldolgozásának kezdetére nem tudsz injektálni saját kódot?
Egyébként .htaccess fájlba ez kell, hogy kerüljön:
# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
php_flag magic_quotes_gpc off
</IfModule>Így nem "száll el", ha az adott modul nincs betöltve.
-
#13290
Sk8erPeter
nagyúr
Brown ügynök
#13289
Sk8erPeter
nagyúr
válasz
Brown ügynök
#13289
üzenetére
Kerülő megoldásnak a kommentekben szereplő módszerek:
http://www.php.net/manual/en/security.magicquotes.disabling.php#91653
http://www.php.net/manual/en/security.magicquotes.disabling.php#91585 -
#13276
Sk8erPeter
nagyúr
Con Troll
#13274
Sk8erPeter
nagyúr
válasz
Con Troll
#13274
üzenetére
Persze, úgy, hogy először kiíratod a <table> csomópontot, majd a for ciklusod csak ezután kezdődik, ekkor íratod ki a sorokat-oszlopokat, majd a ciklus után lezárod a </table>-lel.
Itt úgy lenne logikus, hogy van egy fejléce a táblázatnak, "Eltelt idő" és "Pillanatnyi aktivitás" feliratú oszlopokkal, és ezalatt kezdődik rendezve a kiíratás.
Csak gyorsan bepötyögött szemléltetésként: http://ideone.com/hCnDEr
Nyilván a for ciklusmagban lévő részt cseréld le a saját szövegeidre, értékeidre a <td>-ken belül.
Pedig kényelmes lenne.
Tényleg érdekelne! 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Nem neked mondom, a kérdezőnek, meglep néha az ilyen mértékű lustaság.
(És akkor ez egy "erre a feladatra írt motor" lesz...) Egyébként pont Te magad mondtad most, hogy nincs se rövid, se hosszú távú modulfejlesztési és -felhasználási tapasztalatod Drupallal (és gondolom ugyanígy Athlon64+-nak sincs, de ő szeret amúgy is szélsőségesen nyilatkozni), tehát akkor így nehéz vitába szállni, ha úgy írsz le valamit, hogy még sosem volt vele dolgod.
Új hozzászólás Aktív témák
Hirdetés
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- Autós topik
- Eldurvul a Nova Lake-kel az Intel-féle hibrid dizájn
- Építő/felújító topik
- A GravaStar analóg klaviatúráira nem mondható, hogy konformisták volnának
- Macska topik
- Napelem
- Itt vannak az ASUS legszerényebb NVIDIA Blackwell architektúrás VGA-i
- Hálózati / IP kamera
- BestBuy topik
- További aktív témák...
- GL65 9SD 15.6" FHD IPS i7-9750H GTX 1660Ti 16GB 256GB NVMe + 1TB HDD gar
- ZBook Fury 16 G9 16" FHD+ IPS i7-12850HX RTX A2000 32GB 512GB NVMe magyar vbill ujjlolv IR kam gar
- AKCIÓ!!! GAMER PC: Új i5-14400F +RTX 4060/5060/4070/5070 +16-64GB DDR4! GAR/SZÁMLA! 50 FÉLE HÁZ!
- Elite Dragonfly G3 13.5" FHD+ IPS érintő i5-1235U 16GB 512GB NVMe ujjlolv gar
- Újszerű 17.3" FHD (1920x1080) IPS 40pin 144Hz matt LED kijelző. AUO B173HAN04.9
- Azonnali készpénzes Sony Playstation 5 lemezes és digitális felvásárlás személyesen/csomagküldéssel
- Telefon felvásárlás!! Samsung Galaxy S23/Samsung Galaxy S23+/Samsung Galaxy S23 Ultra
- Azonnali készpénzes félkonfig / félgép felvásárlás személyesen / csomagküldéssel korrekt áron
- Intel Core 2 Quad Q9550 2.83GHz LGA775 Processzor
- Jo Nesbo: LEOPÁRD (nem olvasott)
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest