- Okosóra és okoskiegészítő topik
- iPhone topik
- Google Pixel 7a - venni vagy nem venni?
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
- A holnap határán: itt van minden új Galaxy promóképe
- Xiaomi 14T Pro - teljes a család?
- Garmin Instinct – küldetés teljesítve
- 200 megapixeles zoomkamerát sem kap az S26 Ultra?
- Poco X6 Pro - ötös alá
- Bemutatkozott a Poco X7 és X7 Pro
Új hozzászólás Aktív témák
-
#7571
Sk8erPeter
nagyúr
lafaty80
#7563
Sk8erPeter
nagyúr
válasz
lafaty80
#7563
üzenetére
1.) Néztél error logot? (webszerver logját, PHP logját, stb.)
2.) *nts_vc6 - ez a verzió tuti stimmel?
3.) Különben mi a célod? 32 bites oprendszeren használni Apache-ot, PHP-t, MSSQL-t, és ennyi?
Kész, külön konfigurációs lépéseket és időelb@szásokat nem igénylő megoldásokat, mint az EasyPHP, AppServ, XAMPP, próbáltál már? -
#7570
Sk8erPeter
nagyúr
D@ni88
#7567
Sk8erPeter
nagyúr
"ez miatt"
Az mit jelent?![;]](//cdn.rios.hu/dl/s/v1.gif)
Egyáltalán be van állítva a $_GET['hash']? Ha nincs, akkor nem csinál lószart se. De legalább az else ágat is kezelnéd... vagy épp dobnál egy exceptiont, ha nincs beállítva, vagy bármi egyéb, ennél ezerszer szebb megoldás is jobb lenne.
Amúgy fontold meg, amit a többiek írtak (nem ismétlem őket), hogy ne gány megoldást készíts.
Igazából ezzel a megoldással teljesen feleslegesen raktad objektumba, úgy akarod használni, mintha egy sima statikus függvényt meghívnál, és kész.
Ha nem lesz több metódusod, nyilvántartani való tagváltozód benne, akkor tökéletesen felesleges emiatt objektumot példányosítanod, ne gondold, hogy attól szebb lesz a megoldásod. Hangsúlyozom, ebben az esetben. Akkor már szebb, ha többször is hozzá akarsz mondjuk nyúlni egy eltárolt változóhoz, és ezt burkolni szeretnéd, vagy több metódust is meghívnál egyetlen összetartozó feladaton belül, és a többi, amit az ember tanul, amikor az objektumorientáltság előnyeit tanulja (hadd ne soroljam fel)...
-
#7562
Sk8erPeter
nagyúr
lafaty80
#7561
Sk8erPeter
nagyúr
válasz
lafaty80
#7561
üzenetére
Innen nehezen fogja tudni kitalálni bárki is, hogyan konfiguráltad. Pl. php.ini-ben az extension=php_mssql.dll sor szerepel-e, az ehhez tartozó dll (ntwdblib.dll) megvan-e, stb.
-
#7558
Sk8erPeter
nagyúr
BullZeye
#7556
Sk8erPeter
nagyúr
válasz
BullZeye
#7556
üzenetére
"Na meg ez, ha jól sejtem olyan, hogy megnyitja a TXT-t online, és ott szerkeszthetem, és nem olyan, hogy rákattolok, és elszíneződik."
Nyilván nem olyan, hogy kézzel kell beleszerkesztgetni, f@szságokat nem ajánlanék...
Úgy lenne megoldva, hogy amikor rákattintasz arra a számra, ami jelezné, hogy már láttad, elküldené az adatokat egy feldolgozó fájlnak, az meg a háttérben megcsinálná a fájlba írást, átírva a megfelelő változót, hogy azt az epizódot mondjuk már láttad. Te meg ugye ebből a fájlból olvasnál, így a megfelelő helyen látszana, hogy már láttad az epizódot, annak megfelelően jelenítené meg.Kész scriptet nem tudok rá mutatni, mert nyilván egyedi igényeid alakítják a kódot. Ha nem vágod a PHP-t, akkor így nehéz lesz (értsd: akkor nem lesz most működő megoldásod)... (hacsak nem találsz valakit, akinek van ideje megírni a kódot, igaz, ezt nem lenne olyan hosszú idő megírni)
"Btw jelenleg ezt a feladatot egy 634 bájtos TXT játssza el, de mondanom sem kell mennyire gáz, ha olyan gépen nézném, amin nincs ez a TXT, vagy hogy összehangolni 2-3 gép között"
Itt lenne mondjuk egy fájl, ami felelős ezért (lehet szabdalni mondjuk akár sorozatok szerint is, de minek... akkor már inkább adatbázis), abból olvasnál, abba írnál. Egyelőre elég, amíg kevés adatod van.
De mivel állításod szerint nem fogsz tudni ilyen scriptet írni, akkor csak legalább megbeszéltük, hogy elméletben sima ügy ilyet írni. -
#7554
Sk8erPeter
nagyúr
BullZeye
#7547
Sk8erPeter
nagyúr
válasz
BullZeye
#7547
üzenetére
Visszatérve a JavaScript topicból:
nem kötelező az adatbázis, de sokkal szebb lenne.
Megoldhatod akár XML- vagy JSON-fájlba írással is (most azért ezt a kettőt mondtam, mert ezek feldolgozásához, írásához nagyon jó eszközök állnak rendelkezésre).
JSON-fájl olvasásáról és írásáról itt írtam: [link].
Azt szeretnéd tehát beállítani, hogy mondjuk adott sorozat adott epizódját (vagy évadját) már láttad-e, így az erre vonatkozó adatot módosíthatod a JSON beolvasása után, majd újból fájlba írhatod a módosult adatokat (felülírva mondjuk a korábbi fájlt). Ennél egyszerűbbet nehéz lenne mondani fájlbaírós módszerrel.Szerk.:
amúgy akár SQLite-ot is használhatnál erre, és akkor még meg is könnyíted a későbbi esetleges átállást "rendes" adatbázisra. -
#7526
Sk8erPeter
nagyúr
lafaty80
#7525
Sk8erPeter
nagyúr
-
#7517
Sk8erPeter
nagyúr
Brown ügynök
#7512
Sk8erPeter
nagyúr
válasz
Brown ügynök
#7512
üzenetére
Addig becsülöd le a szerver által visszaküldendő adatmennyiség méretét, amíg nem kell komolyabb adathalmazt áttolnod a hálózaton...
Egyébként nem is csak a végleges méretről beszéltem, hanem arról, hogy PHP-ben a sztringkonkatenálás lassú, tehát plusz időbe is kerül...ezért nem érdemes vele elvégeztetni ott, ahol totálisan felesleges.
...és de, kliensoldalon nagyon nagy valószínűséggel gyorsabban fogja előállítani a kis listádat, ha ráküldöd egy for ciklusra, hogy pakolja össze a kapott adathalmaz alapján.Amúgy ezeket ne vedd kötekedésnek, inkább szakmai vitának, amiről érdemes beszélni.
===
(#7513) Athlon64+ : megnézted, kinek címeztem azt a hozzászólást, amire válaszoltál? Nem neked.
Neked én EZT küldtem. És még egyszer mondom, totálisan felesleges explicite elküldeni a 200 OK állapotkódot, MINDIG ez lesz az állapotkód, ha a fájl hibátlanul elejétől a végig lefutott, legenerálta a kimenetét (vagy nem), a böngésző megkapta azt, ÉS nem volt semmilyen kifejezett egyéb állapotkód-küldés.===
(#7515) Alukard :"Ízlések és pofonok, lényegét tekintve most variációkat taglalunk egy témára, szerintem teljesen fölöslegesen"
Szerintem egyáltalán nem felesleges egy, a témát érintő fórumban átrágni a megoldási lehetőségeket, a különböző gondolkodásmódokat. Egymástól is tanulhatunk.Egyébként oké, érthető, ha semmiképp nem tudsz mod_rewrite-ot használni, akkor nyilván az egyéb lehetőségekről kell beszélni, épp azt is tesszük.
"amint később említve lett a 404es átirányítás végett"
Milyen átirányítás? Nincs itt semmiféle átirányítás. Az arra vonatkozó kódok a 3xx-esek.
És akkor ötvenedjére is elmondom, hogy ha nem létezik a fájl, és ezt jelezni akarod a kliens felé, attól még nem biztos, hogy jó megoldási módszer az, ha ennek ellenére kiadod a 200 OK-t, sőt, attól még lehet egyéni hibaoldalad, hogy 404-es hibakódot dobsz vissza...
Pont erre linkeltem a Drupalos oldalt: http://drupal.org/asdasdasd. Nézd meg mondjuk Firebuggal vagy ehhez hasonlóval, 404-et ad vissza a nem létező oldal miatt, mégis egyéni hibalapja van... -
#7509
Sk8erPeter
nagyúr
Peter Kiss
#7508
Sk8erPeter
nagyúr
válasz
Peter Kiss
#7508
üzenetére
De a 404-es állapotkódot nem véletlenül küldi vissza a szerver a kliensnek.
Pont ezzel jelzi a szerver, hogy a kért tartalom valamilyen okból nem található.
Nem is igazán látom be, mi értelme van erőszakosan megváltoztatni a 404-es állapotkódot 200 OK-ra...
Egy példa: http://drupal.org/asdasdasd
Ez a tartalom nyilván nem létezik, ki is írja a válaszban, hogy "Page not found", ÉS ezzel együtt 404-es HTTP-kódot küld vissza. Így is van ez rendjén!! -
#7507
Sk8erPeter
nagyúr
Brown ügynök
#7498
Sk8erPeter
nagyúr
válasz
Brown ügynök
#7498
üzenetére
Én meg nem hiszem, hogy attól bonyolultabb lenne, hogy szebben valósítod meg, sőt.
Ha PHP-ben megcsináltad a konkatenálást, akkor ugyanezt megteheted kliensoldalon is, csak annyi a különbség, hogy akkor gyorsabb lesz, és kevesebb sávszélt kajál.
Annyi, hogy a JSON-nel visszakapott eredményhalmazt bejárod, és ciklikusan hozzácsapod az option tageket, ez miért lenne olyan bonyolult?
Egyébként nem mondtam, hogy hibás lenne az, amit csináltál, de van rá jobb módszer is."Szerintem tökéletes ahogy csináltam."
Ilyet fejlesztő nem mondhat, csak ha túl sok az egója!
(nehogy megsértődj, csak viccelek, de sosincs tökéletes megoldás )===
(#7499) holinorby :
<td align="right"><?php echo $product_price ?><br />
</td>Itt nem túl szép megoldás, hogy beraksz egy <br />-t. Inkább növeld a paddinget CSS-sel, vagy hasonló, de így nem túl "rugalmas" a stílus átszabása.
===
(#7504) Alukard :
Ne mondd, hogy ez szebb megoldás, mint amit Brown ügynök mond, mert nem az.
Egyébként CMS-eknél nagyon sokszor egyszerűen adatbázisban tárolják az URL aliasokat. Valószínűleg a D@ni88 által linkelt oldalon is ugyanezt alkalmazzák.
Pl. Drupalnál van egy url_alias tábla az adatbázisban: ezek olyan címekre képeződnek le, mint pl. a node/30. Ez utóbbi cím meg már mod_rewrite segítségével képeződik le a megfelelő query stringgé, PHP-vel meg ezt dolgozzák fel, majd kiszedik adatbázisból a 30-as id-jú node tartalmát."Ja, majdnem lemaradt... egy szintén fontos apróság:
header("HTTP/1.1 200 OK");"
Ez meg mi a jó büdös francnak?
Eleve 200 OK állapotkódot kap a böngésződ abban az esetben, ha a kérés hibátlanul lefutott, ÉS a szerver nem küldött más status code-ot. Ergo ez a sorod teljesen felesleges!!===
(#7506) Alukard :
"De ez legalább több helyen működik mint a mod_rewrite -os megoldás. Sok esetben futottam bele abba, hogy vagy le volt tiltva vagy nem apache futott."
A 2. mondat első felére: ahol le van tiltva, ott szólni kell a rendszergazdának, vagy szolgáltatót váltani.
A második felére: nem csak Apache-on működik az URL-átírás... IIS-nél is működik a rewrite, lásd pl. ezt: [link].Jobb CMS-eknél van is támogatás hozzá, pl. Drupalnál, Joomlánál is van IIS-támogatás.
-
#7493
Sk8erPeter
nagyúr
Brown ügynök
#7489
Sk8erPeter
nagyúr
válasz
Brown ügynök
#7489
üzenetére
Szerintem szebb megoldás, ha pl. egy PHP-tömböt json_encode-olsz, azt visszaadod a kliensoldalnak (JSON-formátumban), majd itt, a kliensoldalon generálod le az option elemeket is. Felesleges PHP-ra bízni a sok-sok sztring-konkatenálást, annak ebben az esetben csak annyi a feladata, hogy lekérje a megfelelő adatokat az adatbázisból.
-
#7492
Sk8erPeter
nagyúr
Speeedfire
#7473
Sk8erPeter
nagyúr
válasz
Speeedfire
#7473
üzenetére
"Ez nem lehet egyszerű dolog. Ha külön css fájlban a kivágott kód, legalábbis én nem tudok róla, hogy csináltak volna már ilyet."
Külső CSS-fájlnak megfelelő header küldése esetén nyugodtan megadhatsz PHP-fájlt is.
Példa:
...
<head>
...
<link href="ez_a_css_fajlod.php" type="text/css" rel="stylesheet" />
...
</head>
....A PHP-fájl tartalma meg a következő (daninet példakódját felhasználva):
ez_a_css_fajlod.php
<?php
header('Content-type: text/css');
function generateRandomColor(){
$randomcolor = '#' . strtoupper(dechex(rand(0,10000000)));
if (strlen($randomcolor) != 7){
$randomcolor = str_pad($randomcolor, 10, '0', STR_PAD_RIGHT);
$randomcolor = substr($randomcolor,0,7);
}
return $randomcolor;
}
$background_color = generateRandomColor();
$body_text_color = 'red';
?>
a img:focus, a img:hover, a img:active { background: <?php echo $background_color;?> }
body {
color:<?php echo $body_text_color;?>;
}Mondjuk gondolom kevésbé jellemző, hogy ilyet túl sűrűn alkalmaznának, de ez is működik!
-
#7491
Sk8erPeter
nagyúr
daninet
#7472
Sk8erPeter
nagyúr
válasz
daninet
#7472
üzenetére
Nem ártott volna, ha leírod, hogy most ezt külön CSS-fájlban szeretnéd megvalósítani, vagy "inline" módon. Gondolom inkább utóbbi.
Akkor pl. lehetséges mód a kiíratásra:
<?php
function generateRandomColor(){
$randomcolor = '#' . strtoupper(dechex(rand(0,10000000)));
if (strlen($randomcolor) != 7){
$randomcolor = str_pad($randomcolor, 10, '0', STR_PAD_RIGHT);
$randomcolor = substr($randomcolor,0,7);
}
return $randomcolor;
}
// ....
?>
...
<head>
...
<style type="text/css">
a img:focus, a img:hover, a img:active { background: <?php echo generateRandomColor(); ?>; }
</style>
...
</head>
<body>
.... -
#7490
Sk8erPeter
nagyúr
Brown ügynök
#7476
Sk8erPeter
nagyúr
válasz
Brown ügynök
#7476
üzenetére
Teljesen felesleges a statikus, egyáltalán nem változó dolgokat is PHP-vel kiíratni.
Amit írtál, le lehetne egyszerűsíteni így:
<style type="text/css">
a img:focus, a img:hover, a img:active { background: #<?php echo $valtozo;?> }
</style> -
#7466
Sk8erPeter
nagyúr
mobal
#7463
Sk8erPeter
nagyúr
Bocs, de ezeket a lekezelő válaszaidat igazán mellőzhetnéd, főleg, ha nincs benne érdemi tartalom.
(#7464) haromegesz14 : én is ajánlom a Drupalt, bár még viszonylag gyakorlott PHP-snek is szívás eleinte jól megérteni a működését, modulokat írni, stb., de amikor rákapsz, onnantól nagyon beindul a szekér. Szerintem mindenképp megéri kipróbálni. Mondjuk én csak ezzel szereztem hosszabb távú tapasztalatot, a többi CMS-t csak futólag ismerem, de én többségi szavazatok alapján döntöttem a Drupal mellett (pl. a Joomlával szemben nagyon dicsérték - ez is régóta tartó vita, hogy Joomla vagy Drupal, de utóbbinak igényesebb a kódja, bár még mindig nem igazán objektumorientált. Ettől függetlenül én megszerettem.).
-
#7454
Sk8erPeter
nagyúr
mobal
#7440
Sk8erPeter
nagyúr
"csinálnék egy sajátot"
Teljesen egyetértek cuckával, ez pont az a kategória, hogy egyáltalán nem éri meg sajátot írni, akármilyen nagy mókának is tartod így elsőre.
Elképesztő sok szopás árán fogsz írni egy olyat, ami még mindig tele van hibákkal és/vagy hiányosságokkal.
Ezentúl már csak azért sem éri meg sajátot írni, mert meglévő viszonylag népszerűbb keretrendszereket sem egyszerű elsajátítani, de az legalább ér is valamit a munkaerőpiacon. -
#7420
Sk8erPeter
nagyúr
mobal
#7418
Sk8erPeter
nagyúr
Joggal. A supportjuk legalábbis katasztrófa. Én leveleztem párat egy ügyintézővel (elég gonosz lenne, ha beírnám ide a nevét
), és kifejezetten bunkó paraszt stílusa volt. Még neki állt feljebb, amikor nem teljesítettek valamit, amit vállaltak - konkrétan a rendelkezésre állással (volt, hogy órákra elment az oldal) és egy nameservercím-átirányítással volt probléma, és a reakció az volt, hogy ha nem tetszik, akkor válthatok szolgáltatót, és kábé menjek az anyámba. Persze akkor is vitatkozott az a f@sz, amikor később kiderült, hogy nekem van igazam. Hát gratulálok nekik, hogy így akarnak megtartani egy ügyfelet...
Ja, és a hivatkozási alap röviden összefoglalva: "ingyenesek vagyunk, tehát fogd be a pofád".(#7419) Speeedfire : majdnem egyszerre írtunk.
-
#7416
Sk8erPeter
nagyúr
Speeedfire
#7415
Sk8erPeter
nagyúr
válasz
Speeedfire
#7415
üzenetére
mondjuk a fenti próbálkozások annak, aki már legalább egyszer csinálta, legfeljebb 15 percét veszik el, a support meg nem hinném, hogy ennyi idő alatt válaszol
-
#7414
Sk8erPeter
nagyúr
Speeedfire
#7413
Sk8erPeter
nagyúr
válasz
Speeedfire
#7413
üzenetére
hát ja, náluk is lehetne próbálkozni
-
#7412
Sk8erPeter
nagyúr
D@ni88
#7411
Sk8erPeter
nagyúr
"mivel máskor exportáltam ki xls-be, pdfbe táblátokat php-vel, és ott kellett mókolni a htacces file-okkal."
Ezekhez minek kell .htaccess fájl?
Egyébként ha meg akarod kapni a választ a kérdésre, hogy valóban működik-e, akkor ugyan ne spórold már meg azt az 5 percet, míg kipróbálod az általam előbb linkelt dolgot... így csak szenvedés az egész probléma-megoldás.
-
#7402
Sk8erPeter
nagyúr
Peter Kiss
#7400
Sk8erPeter
nagyúr
válasz
Peter Kiss
#7400
üzenetére
Általában a document root-on kívülre érdemes.
Legalábbis pl. a Drupal Übercart-modul esetén azt ajánlják, hogy a hitelkártya-titkosításhoz szükséges hely legyen document rooton kívül.
Már ha hozzáférsz... Ha sima FTP-kapcsolaton keresztül nem férsz hozzá, akkor megpróbálhatod PHP-ből létrehozni a szükséges könyvtárat.
Pl. ha a Te oldalad document rootja itt van:
oldalad/www (vagy oldalad/public_html, vagy oldalad/htdocs, stb.)
akkor a kulcsok legyenek pl. itt:
oldalad/keys
és legyen megfelelően korlátozva a hozzáférés. -
#7401
Sk8erPeter
nagyúr
D@ni88
#7399
Sk8erPeter
nagyúr
Még az is lehet, hogy úgy általában a .htaccess fájlokat a szerverbeállítások miatt figyelmen kívül hagyják.
Erre még egy teszteset lehetséges: .htaccess Password Generator
Ha az example-re kattintasz, láthatod, hogy minek kéne megjelennie.
Próbáld ezt beüzemelni. Ha egy loginképernyő megjelenik ennek hatására, akkor legalább a .htaccess fájlokat elfogadják - ha nem, akkor nem érdemes tovább szenvedni ezen a szerveren... -
#7398
Sk8erPeter
nagyúr
D@ni88
#7397
Sk8erPeter
nagyúr
Nem működik, ha CGI-módban futtatják a PHP-t...
Még egy próbát tehetsz azzal, hogy kiszeded az <IfModule mod_rewrite.c> sort, meg a bezáró </IfModule> taget, ekkor ha be van állítva a RewriteEngine on, viszont a mod_rewrite modul nincs bekapcsolva, akkor "Internal Server Error" hibaüzenetet kapsz.
-
#7394
Sk8erPeter
nagyúr
D@ni88
#7391
Sk8erPeter
nagyúr
Először csekkolni kéne, a mod_rewrite modul be van-e töltve az Apache-ban.
Saját szerverről próbálkozol, vagy egy szolgáltató tárhelyéről?
Készíts egy phpinfo()-t (amennyiben a szolgáltatód nem volt olyan ostoba, hogy letiltotta ezt a funkciót "biztonsági" szempontokra hivatkozva).
Pl. phpinfo.php fájlon belül:
<?php
phpinfo();
?>Általában, ha a PHP az Apache module-on keresztül fut, a phpinfo()-nál az apache2handler résznél látható egy Loaded Modules sor; ha itt szerepel a mod_rewrite bejegyzés, akkor a rewrite modul be van töltve. Ha nem szerepel a felsorolásban, akkor meg is van a hiba. Pl. a szerver konfigfájljában (httpd.conf) ki van kommentezve a
LoadModule rewrite_module modules/mod_rewrite.so
sor.Most átmenetileg módosíthatnád az index.php-det úgy, hogy a legelejére beteszel egy ilyet:
<?php
echo '$_GET array: <pre>';
var_dump($_GET);
echo '</pre>';
die();
// .....
?>Ezzel kiíratod, mi van a $_GET tömbben.
Ellenőrizd, aztán meglátjuk, hogyan tovább...Egyébként ha az eddigi tesztjeidet leszarja, akkor simán elképzelhető, hogy egyszerűen nem megy a modul. Legalábbis most ennyiből nem látom, hogy valami elrontottál volna.
Szerk.:
(#7393) D@ni88 :
"Ez már egy .tk-s domainról megy."
A domainhez semmi köze. A .tk-s domained elméletben simán mutathatna akár a saját kis szervered IP-címére is, így tiéd lenne a tárhely.
A tárhelyszolgáltató szerverbeállításaitól függ, megy-e a Rewrite modul. -
#7390
Sk8erPeter
nagyúr
D@ni88
#7387
Sk8erPeter
nagyúr
Most elvileg szeretnéd "ráfuttatni" a címeidet az index.php-ra.
A rewrite modul most akkor írja át a címet, ha nem fájlról és nem könyvtárról van szó.
Ha az index.php-ben helyesen include-olod a fejlécet, oldalsávot a megfelelő helyre, akkor azt is meg kell jelenítenie. Kérdés, hogy most Te mit is csinálsz igazából a $_GET['page'] változóval, meg mi van az index.php-dben. Ebből is mutathatnál részletet.
Ja, meg az sem árt, ha a rewrite modul tényleg működik a szerveren, különben hiába van .htaccess fájlod, amiben próbálsz átírni bármit is.
Amúgy kétszer van a RewriteEngine on sorod, egyiket szedd ki.(#7386) Athlon64+ : mit mié'?
-
#7384
Sk8erPeter
nagyúr
D@ni88
#7383
Sk8erPeter
nagyúr
"Rewrite-ot mennyire érdemes használni?"
Amennyire szükséged van rá.
Egyébként nyilván abszolúte van létjogosultsága.Számomra mindenesetre a probléma-leírásod totál érthetetlen volt, ráadásul a .htaccess fájlod meg a pontos célod (pl. milyen címből mi legyen) leírása nélkül csak rébuszokban tudunk beszélni.
-
#7382
Sk8erPeter
nagyúr
Sk8erPeter
#7381
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#7381
üzenetére
Ezzel kapcsolatban még érdemes megnézni ezt:
PHP type comparison tables
és ezt:
Stupid PHP Tricks: (true == false)$a = 'string';
$b = 0;
if ( $a == true && $b == false && $a == $b )
{
echo ( 'universe broken' );
} -
#7381
Sk8erPeter
nagyúr
Brown ügynök
#7372
Sk8erPeter
nagyúr
válasz
Brown ügynök
#7372
üzenetére
"Ez így még kevés: if($users->is_admin())."
Már miért lenne kevés.
Fontos (php.net-ről):
"[...] However, in most cases the cast is unnecessary, since a value will be automatically converted if an operator, function or control structure requires a boolean argument.See also Type Juggling.
When converting to boolean, the following values are considered FALSE:
the boolean FALSE itself
the integer 0 (zero)
the float 0.0 (zero)
the empty string, and the string "0"
an array with zero elements
an object with zero member variables (PHP 4 only)
the special type NULL (including unset variables)
SimpleXML objects created from empty tagsEvery other value is considered TRUE (including any resource)."
Tehát amennyiben a példában az is_admin() függvény visszatérési értéke nem tekintendő false értékűnek a belső konverzió után (lásd a felsorolt példákat), akkor igaznak értékelődik ki.
(#7373) j0k3r! :
"(mar ha bool ertekkel ter vissza a metodus)"
a fentiek miatt nem is muszáj, hogy explicite boolean értékkel térjen vissza a függvény, ahhoz, hogy true-nak értékelődjön ki a visszatérési értéke. Persze nyilván ilyen esetben úgy ocsmány, ha nem boolean értékkel tér vissza, de nem árt tudni, hogy más esetekben is "jól" működik a függvény, ez akár sok félreértéshez is vezethet programteszteléskor. -
#7365
Sk8erPeter
nagyúr
Speeedfire
#7364
Sk8erPeter
nagyúr
válasz
Speeedfire
#7364
üzenetére
Na de ezt itt nem mondtad. Én meg épp azért "szóltam be", mert az úgy nem fog működni.
Bufferelés hiánya esetén ezt a hibát kapod:
"Warning: Cannot modify header information - headers already sent by (output started at ... in ... on line ..."
Nyilván, mivel fejléceket a HTML output után bufferelés hiányában már nem lehet küldeni.De az általam belinkelt kommentben sincs explicite ob_start() meg ob_flush().
Egyszerűen cseréld meg a kódodban a sorrendet...előbb legyen a header elküldése, utána a kiírt szöveg. -
#7363
Sk8erPeter
nagyúr
Speeedfire
#7357
Sk8erPeter
nagyúr
válasz
Speeedfire
#7357
üzenetére
header() a HTML output UTÁN?
([link]) -
#7355
Sk8erPeter
nagyúr
meone
#7354
Sk8erPeter
nagyúr
"Jelenleg az adatok egy JSON fájlba vannak tárolva.
Ezzel kapcsolatban lenne kérdésem.
Az egyik az, hogy ezeket a fájlokat hogyan lehet írni PHP segítségével van rá a neten valami minta, hogy milyen szintaxissal lehet meg nyitni a fájlt bele írni a végére majd lezárni?"Ha jól értelmezem a kérdésedet, szeretnél PHP-vel megnyitni, majd beolvastatni egy JSON-fájlt, ehhez hozzáadni adatokat, majd ismét JSON-formátumban eltárolni, és végül lezárni a fájlt.
1.) Megnyitásra, fájl tartalmának beolvastatására: file_get_contents()
2.) JSON-string PHP-s formátumra konvertálására: json_decode().
Itt hozzáadhatod akár tömbszerűen, vagy neked tetsző módon az adataidat, ezt követően:
3.) PHP-változó JSON-stringgé konvertálására: json_encode().
4.) Fájlba írásra, fájl lezárására: file_put_contents().Ennél egyszerűbb módszer erre nincs.
Pont a json_decode() kommentjei közt szerepel egy viszonylag egyszerű példa a beolvasásra:
[link]
"Make sure you pass in utf8 content, or json_decode may error out and just return a null value. For a particular web service I was using, I had to do the following:<?php
$contents = file_get_contents($url);
$contents = utf8_encode($contents);
$results = json_decode($contents);
?>Hope this helps!"
A második részre:
"Hogyan alakíthatom át ezt úgy, hogy az adatokat ne JSON fájlból szedje ki hanem MySQL és PHP kombó segítségével."
Szerintem itt rosszul értelmezed a dolgokat, vagy lehet, hogy csak rosszul fogalmaztad meg, vagy én értelek félre. Láthatóan az általad linkelt oldalon is PHP segítségével dolgozzák fel az adatokat. Hogy konkrétan MySQL- vagy más adatbázisból szedik ki az adatokat, az teljesen lényegtelen, de valamilyen adatbázisból kiszedik.
Itt annyi történik, hogy AJAX-szal kérdezik le az adatokat, és azzal is jelenítik meg a frontenden. Ettől függetlenül nem feltétlenül generálnak le emiatt egy JSON-fájlt, hogy aztán abból olvassák ki, hanem egyszerűen JSON-formátumban küldik vissza a kapott adatokat a szerverről.
Ez pl. nagyon könnyen megtehető a korábban említett json_encode() függvény segítségével.
Összeállítanak egy tömböt, vagy bármilyen más változót a kívánt adatokkal, json_encode-dal JSON-formátumúra alakítják, majd ezt echo-zzák, ezt kapja meg az AJAX-lekérés eredményeként a kliensoldal. Ezt már csak a megfelelő formátumban jQuery-vel feldolgozzák, elkészítik belőle a grafikont, stb.Ezek fényében az első pontra visszatérve: ha folyamatosan változó adatokat akarsz kiolvastatni pl. adatbázisból, mindezt PHP-vel feldolgozni, stb., akkor emiatt nehogy írj minden alkalommal JSON-fájlt, hacsak nem nagyon indokolt, az feleslegesen rendkívül erőforrásigényes.
-
#7343
Sk8erPeter
nagyúr
fi:zi'k
#7334
Sk8erPeter
nagyúr
válasz
fi:zi'k
#7334
üzenetére
Melyik webshopmotorról van szó?
Menüátszerkesztésre szinte biztos, hogy van mód admin-felületen (legalábbis egy normális önálló webshopmotor ezt lehetővé teszi), emiatt inkább ne gányolj bele a kódba. Ha mégsincs lehetőség ilyen jellegű szerkesztésre, akkor gyorsan válts webshopmotort. -
#7342
Sk8erPeter
nagyúr
TonTomika
#7341
Sk8erPeter
nagyúr
válasz
TonTomika
#7341
üzenetére
Akkor most már tudod, hogy semmi értelme ilyen módon idézőjelbe tenni, amikor a $_POST tömbbe kerül, így is-úgy is stringként fog átmenni a szerver felé.
"csúszott el a történet"
A történet el szokott csúszni? Imádom ezt a "történet" szót, semmi értelme ilyen kontextusban, de legalább jó magyartalan, és fogalmam sincs, miért, de iszonyatos nagy divatja van manapság ennek a szóhasználatnak, a legrosszabb, hogy értelmes emberek is használják ilyen módon. (Pl.: "3 ezer Ft-ba kerül a történet." Mi a tököm értelme ennek? )
Ez nagyon OFF, bocs, de ez a szó mindig szúrja a szemem. -
#7321
Sk8erPeter
nagyúr
Speeedfire
#7320
Sk8erPeter
nagyúr
válasz
Speeedfire
#7320
üzenetére
Sejtettem, hogy a PHP-s DOM-kezelő osztályokra gondolsz, csak az nem világos, hova, miért kell.
Mert mondjuk használható olyasmire is, hogy akár külső oldal legenerált HTML outputjából szedsz ki tartalmakat, ha nincs más megoldás, vagy akár saját adatbázisból kiszedett adatokat akarsz megjeleníteni, és ehhez segítségül hívod a DOM-ot megalkotó osztályokat, bár utóbbi használata szerintem nem feltétlenül indokolt, pl. teljesítménybeli szempontok miatt. Úgy értem, lassabb vagy erőforrásigényesebb lehet így legenerálni egy egész oldalt, mintha "statikus" HTML-elemekbe dinamikusan szúrsz adatot PHP-vel. Persze igénytől függ, egyéb dolgokra is használható, pl. sanszos, hogy ilyen módon egy XML-doksit áttekinthetőbben tudsz generálni, bizonyos esetekben tehát lehet, hogy pont jobb is ezeket használni, ezért kérdezősködtem vissza, kíváncsiságból, nem kötekedésből. (Na jó, az, hogy rácuppantam a "dom-olás" szóra, az az volt. 
)Amúgy meg már hogyne Doom-oztam volna!
-
#7319
Sk8erPeter
nagyúr
vakondka
#7318
Sk8erPeter
nagyúr
válasz
vakondka
#7318
üzenetére
Ilyesmit lehet szűrni a glob() függvénnyel is.
Valahogy így:<?php
$dir_to_scan = 'test_dir';
$pattern = $dir_to_scan . '/';
$pattern .= '*.zip';
foreach ( glob( $pattern ) as $filename) {
$file_array[] = $filename; // a könyvtárnévvel összefűzve gyűjti ki a fájlneveket
}
var_dump($file_array);
?>Persze a Te kódod is tökéletes (simán elképzelhető, hogy akár még hatékonyabb is), ezt inkább csak érdekességképp említettem.
=========================
(#7317) Speeedfire :
Biztos igazad van, de még mindig nem tudom, mit jelent az az ige, hogy "dom-olni".
Meg jó lenne tudni, igazából mi a célod ezzel. (Miért van szükség "dom-olásra". ) -
#7315
Sk8erPeter
nagyúr
Speeedfire
#7313
Sk8erPeter
nagyúr
válasz
Speeedfire
#7313
üzenetére
"Dom-olni akarok egy oldalt a span-ek alapján."
He?
Szép magyaros mondat, de nekem nem biztos, hogy jól sikerült értelmezni. Szóval kikeresed egy HTML outputból a <span> tageket, és ezeket az elemeket szeretnéd megkeresni, megjeleníteni, manipulálni...?Ha <pre> tagekkel íratod ki, akkor ott minden új <pre> tagnél eleve új sortöréssel kezd, szóval ott nem meglepő, ha új sorba pakol.
(#7292) mobal : "ajaxplorer tudtommal nem is használ php -t."
Elég érdekes lenne, ha egy PHP-alapú alkalmazás nem használna PHP-t...
-
#7244
Sk8erPeter
nagyúr
L3zl13
#7243
Sk8erPeter
nagyúr
Teljesen jogos.
Sanszos, hogy a filter_var($uri, FILTER_VALIDATE_URL) fv.használat esetén is igaz ez, egyébként sem százas, most hirtelen nem ugrik be, milyen URL-nél, de előfordult, hogy bugosan viselkedett (valamilyen cikkben írták a hibát), teszteltem is akkor, tehát az is hibázhat. -
#7242
Sk8erPeter
nagyúr
Speeedfire
#7241
Sk8erPeter
nagyúr
válasz
Speeedfire
#7241
üzenetére
Áhá, világos. De akkor most már magyarul minden úgy megy, ahogy szeretted volna eredetileg?
Amúgy tapasztalat alapján a Microsoft-programok a telepítéskor és máskor is csak pont olyanra kérdeznek vissza, amire nem kéne. -
#7240
Sk8erPeter
nagyúr
Speeedfire
#7239
Sk8erPeter
nagyúr
válasz
Speeedfire
#7239
üzenetére
Mármint most milyen javítás?
Az msiexec /i ...msi ? -
#7238
Sk8erPeter
nagyúr
Speeedfire
#7236
Sk8erPeter
nagyúr
válasz
Speeedfire
#7236
üzenetére
Win+R, eventvwr ?
Win 7-nél legalábbis általában már részletesebb a hibajelzés, mint pl. XP-nél.Ezt a linket a Web Deployment Agent Service-ről már láttad? >> [link].
Lehet, hogy egyszerű reinstall a megoldás, nem vágom. -
#7234
Sk8erPeter
nagyúr
Speeedfire
#7233
Sk8erPeter
nagyúr
válasz
Speeedfire
#7233
üzenetére
A deploy-oló szarságnak a portját nem tudod bekonfigolni? Eléggé csodálkoznék rajta.
Egyébként addig is kerülő megoldásnak az is jó lehet szerintem, hogy az IIS ugyanúgy 80-as porton fut, mint defaultból, addig meg leállítod az Apache-ot. Általában úgyis az Apache-ot használod, ahogy értelmezem, és csak néha használnád az IIS-t, próbából. Akkor meg a service-re beállítod, hogy csak manuálisan induljon el.
De meg lehet oldani úgy is, hogy ne vesszenek össze.Vagy harmadik megoldás, hogy IIS alá teszed a PHP-t is.
Még 2009-ben ezt írták itt:
"An upcoming projects involves Microsoft engineers working with PHP engineers to get the next version of PHP (PHP5.3 which is not yet available at this time) to perform much better in IIS. This will no doubt make some progress toward WIMP catching up with LAMP in performance.""és 2-4 karakter között az url, több nem lehet."
Gondolom itt nem URL-t akartál írni, hanem TLD-t...URL-validálásra csak egy gyors példa (Google):
[link]
function isValidURL($url){
return preg_match('|^http(s)?://[a-z0-9-]+(.[a-z0-9-]+)*(:[0-9]+)?(/.*)?$|i', $url);
}Vagy ez: [link].
Nem teszteltem mondjuk agyon, de itt egyből ki lehet próbálni a működését a reguláris kifejezésnek: [link].
De a legegyszerűbb, php.net-ről: [link]
$uri = 'http://example.com';
$isValid = filter_var($uri, FILTER_VALIDATE_URL); -
#7231
Sk8erPeter
nagyúr
Speeedfire
#7229
Sk8erPeter
nagyúr
válasz
Speeedfire
#7229
üzenetére
Itt azt írja valaki, idézem: "Check if you have "SQL Server Reporting Services" running, it uses port 80. If you stop it (from the Reporting Services Configuration Manager) you'll be able to run apache."
Egyébként most azt szeretnéd, hogy az Apache a 80-ason, az IIS a 81-esen, igaz? Milyen SQL szervered van fent?Egyébként Windows-on cmd-ből netstat -a -val is tudsz listázni (melyik portok foglaltak).
-
#6936
Sk8erPeter
nagyúr
Siriusb
#6924
Sk8erPeter
nagyúr
válasz
Siriusb
#6924
üzenetére
Szerintem az "ágyúval verébre" inkább a Joomla esetében igaz.
Nekem a Drupal 7-es verziójának AJAX-alapú admin-felülete nagyon tetszik, könnyen kezelhetőnek és áttekinthetőnek találom, a 6-os verzió admin-felülete viszont számomra kifejezetten kényelmetlennek és kicsit káoszosnak tűnik. Persze meg lehet találni benne a dolgokat, meg nyilván vannak template-ek akár az admin-felület testreszabására is, de az kicsit jobb, hogy a 7-esben ez már eleve adott.
Csak ugye az a gáz, hogy a 7-eshez még viszonylag "kevés" template és modul készült el, inkább még mindig csak a 6-oshoz találhatók ilyenek, pl. webshopmodulokból is inkább legfeljebb beta-verziókat találtam, vagy egyáltalán nem (mint asszem az Übercarthoz sincs kész a 7-es). Tudtommal elég sok minden változott a 7-es változatban, így még lehet, hogy várat is magára sok modul elkészítése.
Na, szóval igazából amire ki akartam lyukadni, hogy nekem végül is jó lenne a 6-os, de annak az admin-felülete egy átlagos felhasználó szemszögéből (ne az itteni fórum látogatóiból indulj ki, akik vélhetően nem egységsugarú júzerek) nem tűnik olyan kényelmesnek (vagy csak nem találtam hozzá megfelelő skint, ha van ilyen, szívesen fogadom), a Joomláé talán valamennyivel kézenfekvőbb meg kicsit szebb - kód meg pár egyéb dolog szempontjából viszont a Drupal a jobb választás; Joomla talán a kicsit több elkészített választható template meg modul miatt. Persze valóban, ízlések és pofonok különböznek.
Szóval tényleg nincs igazság! -
#6935
Sk8erPeter
nagyúr
Brown ügynök
#6933
Sk8erPeter
nagyúr
válasz
Brown ügynök
#6933
üzenetére
Hogy érted azt, hogy "minden művelet előtt"?
Csak a script elejére kell betenni ezt a kódot, a lefutásáig akkor már használhatók a session elemei. -
#6934
Sk8erPeter
nagyúr
Alukard
#6929
Sk8erPeter
nagyúr
válasz
Alukard
#6929
üzenetére
Szerintem adatbázis-kapcsolati objektumok létrehozásához érdemes lehet a Singleton-mintát alkalmazni. Többnyire az embernek dinamikus weblapok készítésekor egyetlen adatbázis-kapcsolati objektumra van szüksége, persze lehetnek kivételek, de általában előbbi a jellemző.
A kódodban a protected láthatóságú tagváltozóknak semmi szerepe nincs, mivel nem rendeled hozzájuk az értékeket (nincs ilyen sor: $this->sql_host = "localhost"; stb.), hanem csupán lokális érvényességű változóid vannak (pl. $sql_host), így azoknak nem sok értelme van. Mivel tulajdonképpen úgyis csak egyetlen helyen (connect() függvény) csatlakozol az adatbázishoz, nem biztos, hogy érdemes egyáltalán eltárolni ezeket az értékeket az objektumon és leszármazottain belül máshol is elérhető tagváltozókba.
A "var" kulcsszó használata elavult, és igazából értelmetlen is jelen esetben, az nyugodtan lehetne protected (vagy private, de akkor a leszármazottak nem látják).
Az előbbieken túl a $query-ket sehol nem ellenőrzöd, nem kerülöd el az esetleges SQL Injectiont vagy rosszindulatot nem feltételezve csupán esetleges hibákat azzal, hogy escape-eled az átadott stringet (mysql_real_escape_string).
Plusz ha már OOP, akkor már kivételeket is illendő lenne használni, ez a die() ill. ekvivalense, az exit() nagyon ronda megoldás, ahelyett, hogy a megfelelő helyeken kezelnéd az egyes hibákat, egyből leállítod a szkript futását.
Ezenkívül a hibaüzenetbe is muszáj belekötnöm: ez a "Ne zaklasd a rendszergazdát" elég furcsa egy hibaüzenet, inkább neked kéne elnézést kérned a júzertől, hogy para van az adatbázissal, nem még jól le is cseszni.Én személy szerint a PDO-t használom, és ajánlom is a használatát. Támogatja az adatkötést, plusz azt, hogy ne kelljen explicite mindenhol escape-elni a stringeket (elintézi magának), és még sok egyebet, ráadásul full objektumorientált, és szerintem áttekinthetővé teszi a kódot.
Feltettem pastebinre azt az osztályt, amit a Singleton-mintának megfelelően írtam, általában ezt az osztályt használom adatbázis-kapcsolat kiépítésére. A konstruktor és a copy konstruktor privát láthatóságú, így kívülről nem példányosítható tetszőleges számban az objektum.
Van egy külön konfigfájlom, ahol definiálom a saját konstansokat, többek közt az adatbázis-jelszót és -felhasználónevet, ezeket a konstansdefiníciókat most az elejére tettem, középen jön maga az osztály, az osztály kódja alatt pedig egy példa látható a használatára: [PDO Singleton DB class].
Hátha bárki hasznát veszi. -
#6906
Sk8erPeter
nagyúr
cucka
#6904
Sk8erPeter
nagyúr
És én ennek hol mondtam ellent?
Ezt írtam, idézem még egyszer: "Ezenkívül igen, alapvetően egyszeres öröklődés van, tehát egy osztálynak egy őse lehet, DE bármennyi interfészt megvalósíthat"Az továbbra is alapvető különbség marad, hogy míg az absztrakt osztályban definiálhatsz függvényeket, addig az interfészekben nem, ott csak kötelezően előírod, hogy a leszármazottak mit valósítsanak meg...
És igen, tulajdonképpen ahogy írod is, a csupa absztrakt függvényt tartalmazó osztály egyenértékű lehet az interfésszel, de nyilván C#-ban és Java-ban sem véletlenül létezik a két különböző stuktúra.
Tulajdonképpen most nem is vitatkozunk, csupán kiegészítgetjük egymást. -
#6905
Sk8erPeter
nagyúr
Forza_JUVE
#6889
Sk8erPeter
nagyúr
válasz
Forza_JUVE
#6889
üzenetére
Hali!
Szerintem továbbra is maradj a reCAPTCHA-nál.
A korábbi kérdésedre azért nem kaptál itt választ, mert egyben bepakoltál egy tökéletesen formázatlan kódot, így ember legyen a talpán, akinek van kedve ezt végigböngészni (vagy türelme kimásolni, majd berakni NetBeans-projektbe, és ott rámenni az autoformázásra, majd elkezdeni a kutakodást).
Eleve nem is a tutorial szerint használtad a PHP-kódot: [Using reCAPTCHA with PHP].
Itt írja az igen egyszerű példakódot, csupán ezt kell bemásolnod arra az oldalra, ahol a captchát kiíratod, példa:
<html>
<head><title>reCAPTCHA</title></head>
<body> <!-- the body tag is required or the CAPTCHA may not show on some browsers -->
<!-- your HTML content --><form method="post" action="verify.php">
<?php
require_once('recaptchalib.php');
$publickey = "your_public_key"; // you got this from the signup page
echo recaptcha_get_html($publickey);
?>
<input type="submit" />
</form><!-- more of your HTML content -->
</body>
</html>A kiemelt rész a lényeg.
Validáláskor pedig ezt csinálod:
<?php
require_once('recaptchalib.php');
$privatekey = "your_private_key";
$resp = recaptcha_check_answer ($privatekey,
$_SERVER["REMOTE_ADDR"],
$_POST["recaptcha_challenge_field"],
$_POST["recaptcha_response_field"]);
if (!$resp->is_valid) {
// What happens when the CAPTCHA was entered incorrectly
die ("The reCAPTCHA wasn't entered correctly. Go back and try it again." .
"(reCAPTCHA said: " . $resp->error . ")");
} else {
// Your code here to handle a successful verification
}
?>Halál egyszerű.
Én ezt javaslom captchák közül.=======
(#6893) LW:
ha már pastebin-re másolod a kódokat, akkor válaszd is ki a PHP-szintaktikát, hogy megfelelően kiemelje, épp az a lényeg, hogy úgy lesz gyorsan átlátható! -
#6903
Sk8erPeter
nagyúr
cucka
#6902
Sk8erPeter
nagyúr
Uhh, bocs, a "néhány" szó nekem elkerülte a figyelmem, vagy hirtelen másképp értelmeztem, de akkor így rendben van.
De legalább így jól ki van fejtve, hátha másnak is hasznos lesz."Az abstract class és az interface között az alapető különbség nem az, hogy az egyikben lehetnek definiált függvények, a másikban pedig nem, hanem hogy az interface az egyetlen eszköz php-ban, amin működik a többszörös öröklődés."
Most ebbe is hadd kössek bele.
Az is alapvető különbség, amit én írtam, mivel az interfész tulajdonképpen csak egy "mintát" ír elő, amit meg kell valósítani. Az absztrakt osztály sokszor ennél konkrétabb szerkezetet határoz meg. Ezenkívül igen, alapvetően egyszeres öröklődés van, tehát egy osztálynak egy őse lehet, DE bármennyi interfészt megvalósíthat (vesszővel elválasztva az egyes interfészek neveit az implements kulcsszó után). -
#6900
Sk8erPeter
nagyúr
Siriusb
#6886
Sk8erPeter
nagyúr
válasz
Siriusb
#6886
üzenetére
"ha valamikor bővíteni kell az oldal funkcionalitását, csak jobban jársz..."
Mire gondolsz konkrétan? Csak azért kérdezem, mert elvileg a Joomla is könnyen bővíthető, és számtalan modult készítettek hozzá, ráadásul úgy tudom, az egyes template-ek és modulok sok esetben visszafelé is kompatibilisek (ezt saját tapasztalatból nem tudom se cáfolni, se alátámasztani, csak hallottam olyantól, aki használ Joomlát egy ideje), míg ez Drupalról eddigi tapasztalataim alapján nem elmondható.
Sok fórum olvasgatása során mondjuk arra jutottam én is, hogy a Drupal jópár szempontból "profibb", a kódja szebb, letisztultabb, ráadásul brutálhosszú dokumentáció van hozzá. Másik szempont mondjuk, hogy a Joomlához meg esetleg épp a nagyobb népszerűsége miatt lehet több helyen segítséget találni gyors keresés után."Részemről örülök, hogy már belevágtál ilyen projektbe, én is a Te tudásodból élek :
" Na, ne túlozz. A menüs linkeket köszi, bár asszem már találkoztam velük, de most jobban áttanulmányozom.
Ja tényleg, azt elfelejtettem mondani, hogy amennyiben valamelyik részre az "Elsődleges hivatkozások" nevü menürészt bepakolom, ott tök jól látszik a menühierarchia, tehát azt elvileg simán tudnám felülbírálni CSS-sel és/vagy JavaScripttel, hogy hogyan jelenjen meg, nekem csak az volt a fura, hogy elvileg az alapmenürendszernek kapásból kéne tudnia ezt a lenyíló menüs dolgot.(#6888) PazsitZ :
"a drupal vezet globális használatban"
Tényleg? Csak mert eddig úgy tudtam, még mindig a Joomla a népszerűbb, ezért is van, hogy sokkal több template és modul található meg hozzá, mint Drupalhoz...
Mondjuk én csak abból indulok ki, amiket fórumokon és egyéb helyeken olvastam, de az nagyjából mindenhol egybecsengett, hogy a Joomla épp amiatt jóval népszerűbb (állítólagos statisztikák alapján, én ilyeneket mondjuk nem nézegettem), mert kattintgatós módszerrel szinte még a hülye is össze tud vele dobni egy egyszerűbb oldalt. Drupal meg mondjuk állítólag nehézkesebb ilyen szempontból. Őszintén szólva utóbbit sem értem, miért, legalábbis a 7-es változatnál, mert ott egy nagyon fasza AJAX-os felületen full egyszerű cikkeket írogatni, menüket hozzáadni, meg a többi dolgot megvalósítani, ilyen szempontból nem találtam nehezebbnek a Joomla-nál. DE kipróbáltam a Drupal 6-ost is, az még tényleg nem ennyire kézenfekvő, szerintem a 7-es felülete sokat egyszerűsödött."Viszont ezzel szemben sokkal többre képes, mint a joomla."
Milyen szempontból? Úgy tudom, jogosultságok és SEO terén pl. a Drupal erős, de Joomlához meg szinte nincs olyan modul, ami ne lenne megtalálható neten.Ja tényleg, még egy szempont, ami engem még inkább a Drupal felé lök: nálam fejlesztés közben a php.ini-ben a hibajelentéssel kapcsolatos alapbeállítás az E_ALL | E_STRICT, hogy a legszigorúbb hibaellenőrzés legyen bekapcsolva, így elkerülve a későbbi bakikat, és a Joomlánál ezen beállítás esetén szinte nincs olyan menüpont, amelyikbe belelépve ne kapnék valami PHP-hibát (az E_STRICT beállítás tényleg elég szigorú). Ez számomra nagyon zavaró. Ahogy észrevettem, Drupalnál ezzel szemben erre is odafigyeltek, mert a Drupal menüpontjainak böngészgetése közben egyáltalán nem látok PHP-s hibát.
Sokan mondják, hogy ezek a hibajelentések figyelmen kívül hagyhatók, és felesleges foglalkozni velük, de ezzel nem értek egyet. Fejlesztés közben legyen bekapcsolva, így lehet megtanulni elkerülni nemtörődömségből, igénytelenségből vagy épp kisebb tudáshiányból eredő bakikat (én is rengeteget tanultam ezekből). Főleg egy keretrendszernél nem mindegy, mennyire figyelnek oda az alapvető programozástechnikai hibákra, még ha azok kisebb hibák is, amik összességében nem okoznak nagy galibát. -
#6899
Sk8erPeter
nagyúr
cucka
#6894
Sk8erPeter
nagyúr
"Az absztrakt osztály lényege, hogy ez egy osztály, aminek néhány függvénye csak deklarálva van, de nincsenek definiálva (abstract függvények). Ez azt jelenti, hogy az osztály megmondja, hogy milyen pontosan függvényekre van szükség a működéséhez, de ezeket a függvényeket a leszármazottak kötelesek implementálni."
Ezt azért javítanám, mert ez így nem teljesen igaz.
Amit Te írsz, vagyis az, hogy egy osztály nem tartalmaz definíciókat, hanem csupán tartalmazza azon metódusok deklarációját, amelyeknek definícióját majd az azt megvalósító osztályoknak tartalmaznia kell, az inkább az interface-re vonatkozik: [link].
Az absztrakt osztály igenis tartalmazhat metódusdefiníciókat, mivel egy absztrakt osztálynak nem feltétlenül absztrakt az összes metódusa - lásd ezt a példát php.net-ről. Lehetnek tehát olyan osztályok, amelyek megvalósítják az absztrakt osztályt, és az ősosztályban eleve definiált függvényt fel is tudják használni, anélkül, hogy ez explicite felül lett volna bírálva - DE akár az absztrakt osztályban eredetileg is definiált metódust felül is írhatja a leszármazott osztály egy azonos nevű és visszatérési értékű metódussal.Írtam pár rövid példát a szemléltetésre:
abstract class AbstractClassExample{
public abstract function cannotBeDefinedInAbstract(){
echo 'This is an abstract function in abstract class - gives an ERROR, it won\'t be echoed!';
}
}Ez nyilvánvalóan rossz, mert abstract függvénynek nem lehet függvénytörzse, hibát is kapunk rá:
"Fatal error: Abstract function AbstractClassExample::cannotBeDefinedInAbstract() cannot contain body in D:\Honlap\www\proba\index_2.php on line 6"
Ha az adott sort lecseréljük így:
public abstract function cannotBeDefinedInAbstract();
akkor már nem kapunk hibát.A többi esettel kiegészítve itt egy hosszabb példa:
<?php
abstract class AbstractClassExample{
public abstract function cannotBeDefinedInAbstract();
public function itsAlreadyImplementedInAbstractButCanBeOverridden(){
echo 'This is derived from the abstract class!';
}
}
class ExtendsAbstract extends AbstractClassExample{
public function cannotBeDefinedInAbstract() {
echo 'This is the implemented function in derived class!';
}
public function anotherFunction(){
echo 'This is just anonther example function.';
}
}
$extendedClass = new ExtendsAbstract();
$extendedClass->cannotBeDefinedInAbstract();
echo '<br />';
$extendedClass->itsAlreadyImplementedInAbstractButCanBeOverridden();
echo '<br />';
$extendedClass->anotherFunction();
echo '<br />';
?>Ennek kimenete a következő:
This is the implemented function in derived class!
This is derived from the abstract class!
This is just anonther example function.Az itsAlreadyImplementedInAbstractButCanBeOverridden() függvény tehát egy absztrakt osztályban lett megvalósítva, a leszármazott osztály mégis eléri, és megfelelően meg is valósítja az ott szereplő kiírást.
Ez azonban felülbírálható:
class ExtendsAbstract extends AbstractClassExample{
public function cannotBeDefinedInAbstract() {
echo 'This is the implemented function in derived class!';
}
public function itsAlreadyImplementedInAbstractButCanBeOverridden() {
parent::itsAlreadyImplementedInAbstractButCanBeOverridden();
echo '<br />This comes from the derived class.';
}
public function anotherFunction(){
echo 'This is just anonther example function.';
}
}Ebben az esetben az ExtendsAbstract függvényben is megvalósítjuk az említett itsAlreadyImplementedInAbstractButCanBeOverridden() függvényt, így az felül lesz bírálva, a parent::itsAlreadyImplementedInAbstractButCanBeOverridden(); sorral viszont továbbra is érvényesül a szülőben implementált függvény összes feladata, így a kimenet a következőre módosul:
This is the implemented function in derived class!
This is derived from the abstract class!
This comes from the derived class.
This is just anonther example function. -
#6885
Sk8erPeter
nagyúr
Siriusb
#6884
Sk8erPeter
nagyúr
válasz
Siriusb
#6884
üzenetére
Hali!
Köszi a hozzászólást, nagyjából én is ezekre jutottam, de igazából még mindig nem sikerült dönteni ezek alapján sem.
Tulajdonképpen mindkettő jó valamilyen szempontból, Drupalt használtam eddig többet, de ez a lenyíló menüs dolog számomra tökéletesen érthetetlen módon nem akar összejönni, egyszerűen a HTML-kimeneten sem jelenik meg, az már jobb eset lenne, ha CSS-szarakodásra lenne szükség, de sajnos nem csak erről van szó."Mondjuk az nem világos, Neked miért lenne CMS-re szükséged, simán megírsz mindent kapásból, nem?!
"
Hát köszi a feltételezést. Meg tudnám írni az oldalt úgy, hogy jól testreszabható legyen, admin-felülete is legyen, stb., de az a baj ezzel, hogy rengeteg időt vesz igénybe, főleg az, hogy mindent elejétől a végéig meg kell írni magadtól, és lényegében ilyenkor az embernek az idő múltával fel kell fedeznie a spanyolviaszt, tehát a munkája végére nagyjából oda jut el, hogy akár nyugodtan használhatott volna erre egy keretrendszert is. Azért találom jónak ezeket, mert rengetegen fejlesztik, csiszolgatják, és valóban fel tudják gyorsítani a munkát.
Szívtam már nagyon sokat azzal, hogy admin-felületet elejétől végéig én csináltam meg, és a validálással, teszteléssel, hibák javításával, kiegészítgetéssel, megfelelő adatbázis létrehozásával és minden egyébbel együtt rengeteg időt vett igénybe - de legalább egész stabil tudásra és "fejfalbeverésre" sikerült eközben szert tenni...
Gondolj bele, akár csak azt megoldani, hogy a menürendszer tetszőlegesen bővíthető és egymás alá rendelhető legyen (szülő-gyerek viszony), a hozzá tartozó adatbázis kiépítése, majd miután ez megvan, fancy átrendezhető felületet kialakítani hozzá, nevüket és egyebeket szerkeszthetővé tenni, validálni, hogy elkerüljük a rosszindulatú kód beágyazásának lehetővé tételét, stb., már kapásból egy rohadt sok időt igénybe vevő feladat. És ez még csak egy a sok megoldandó feladat közül.
Szóval végül is nem ördögtől valók ezek a keretrendszerek, tulajdonképpen szükséges rossz, vagy épp jó, mert sok PHP-fejlesztő úgy gányolja szét az oldalát, és rakja tele biztonsági lyukakkal, ahogy kell, ezek nagy része elkerülhető Joomla, Drupal és társaival, még ha ezekben is vannak biztonsági rések - legalább nem tátonganak.Ha a Drupalhoz valakinek sikerült megoldani a lenyíló menüs problémát (adott menüpont a szülőelem, hozzátartozó gyerekelemek az almenüpontok), akkor az ne kíméljen, hogy csinálta.
-
#6883
Sk8erPeter
nagyúr
Sk8erPeter
nagyúr
Hali!
A tapasztalataitokra lennék kíváncsi. Joomla vagy Drupal?
Weblaboron és még csomó helyen késhegyre menő vitákat olvastam a témában, nagyjából tényleg Windows vs. Linux témához hasonlót.
Nektek volt tapasztalatotok ezzel kapcsolatban, hogy melyikkel tudnátok felgyorsítani a munkátokat?
Joomlát kicsit elvileg többen használják, de Drupal is népszerű, mindkettőhöz sok modul és skin/theme/template van.
Drupal 7-ben nagyon tetszett, hogy full AJAX-os és egész modern admin-felülete van az egyik skinnel, DE sajnos a 7-es változathoz még sok modult nem ültettek át.Na meg Drupalnak a 6-os és 7-es változatával is szoptam a legördülő menüknél, egyszerűen egyáltalán nem akar működni, pedig úgy csináltam mindent, ahogy ebben a tutorialban van (mondjuk ez a Gardens-re vonatkozik), plusz jól adtam meg a szülőelemeket is, tehát nem értem. Az ingyenes Drupal Gardens-es oldalon műxik a menü, ahogy kell, saját oldalon más témáknál nem.
Előre is köszi minden hozzászólást, véleményt!
-
#6845
Sk8erPeter
nagyúr
Speeedfire
#6844
Sk8erPeter
nagyúr
válasz
Speeedfire
#6844
üzenetére
Ez mondjuk nem igaz, mert VirtualHosttal Apache-ban oda irányítod a webszerver könyvtárát, ahova csak akarod. Pl. lehet, hogy az egyik projekted a http://localhost:4133123 címen elérhető, és a könyvtára - Windows alatt - a D:\ezazegyikprojekt\nos\ helyen található a vinyón, a másik meg http://blabla.local.akarmi.ize címen érhető el, és a könyvtára az F:\tokmindegy\blabla\ helyen van.
-
#6843
Sk8erPeter
nagyúr
Lacces
#6840
Sk8erPeter
nagyúr
"jó az easyphp, mert a komodo edit alatt fut szépen"
Mit értesz azalatt, hogy "fut" Komodo alatt?
Gondolom van valami konzolszerűség, amin megmutatja a kimenetet. Ettől függetlenül nem a Komodo értelmezi és futtatja a PHP-kódodat.
NetBeans-nél is be lehet állítani elvileg valahogy, hogy a konzolszerűségen megmutogassa a kimeneteket, én mondjuk a böngészőben szoktam kipróbálni, mi látszik a weboldalon a kódbeli változtatások hatására, parancssori módban a lehető legritkább esetben használom a PHP-t, de annak is van persze létjogosultsága bőven.
Meg mondjuk PHP debuggoláshoz hasznos lehet, hogy a NetBeans saját konzolán látszik a kimenet. -
#6837
Sk8erPeter
nagyúr
kadam4
#6835
Sk8erPeter
nagyúr
Hát ja, először localhoston oldd meg a problémát.
"akkor sem állítódik be a cookie"
Mármint gondolom ezalatt azt érted, hogy mindig az általad korábban írt "Warning: Cannot modify header information - headers already sent by (output started at c:\php\index.php:16) in c:\php\page.php on line 17" hibaüzenet jelenik meg.
Nekünk meg ezt kód nélkül amúgy is igen nehéz debuggolni. Azt írja egyébként, hogy az index.php 16. sorában van az első output. Ott mi szerepel? Nem biztos, hogy szándékos az az output, néha akár egyetlen karakter (pl. szóköz) is gondot okozhat, ami véletlenül odakerült.
Ha viszont az output szándékosan került a setcookie() elé, akkor az amúgy is rossz."ha az elején hívom meg, akkor szétesik az oldal szerkezete"
Ettől függetlenül a cookie-kat az elején állítsd be, úgy a logikus. -
#6834
Sk8erPeter
nagyúr
kadam4
#6833
Sk8erPeter
nagyúr
"a webtárhelyen probléma nélkül megy"
Ezt úgy érted, hogy az általad beállítani kívánt Test_Cookie is megjelenik rendesen?
Arra, hogy webtárhelyen miért mehet esetleg, arra itt volt két lehetséges magyarázat - de ezek természetesen nem jelentik azt, hogy a tárhelyen bármi "jobb" lenne, mert a probléma attól még fennáll, hogy rossz sorrendben vannak a dolgok, a cookie-kat azután próbálod beállítani, miután a headereket már elküldted a böngésző felé. Megoldás az, hogy megcseréled a sorrendjüket... -
#6801
Sk8erPeter
nagyúr
Xirtam
#6799
Sk8erPeter
nagyúr
Van tmp könyvtárad a gyökérben?
http://atw.hu/gyik#gyik5
"Miért nem működik a file feltöltés PHP-vel?A munkamenet fájlokat a PHP minden esetben a gyökérkönyvtárad alatti 'tmp' könyvtárban tárolja, ezért nincs más dolgod, mint létrehozni azt."
=============
(#6800) Forza_JUVE:
"(Ha szükséges, bemásolhatom a php kódot is.)"
Akkor tedd azt.
Kicsit nehéz lenne anélkül kitalálni, mi az ábra.
Persze a privát meg publikus kulcsot csillagozd ki, az most itt nem számít. -
#6798
Sk8erPeter
nagyúr
lalimano
#6792
Sk8erPeter
nagyúr
válasz
lalimano
#6792
üzenetére
Hali!
Én a dynamicdrive-os cucc helyett egy sokkal szebbet és egyszerűbbet ajánlanék: a jQuery load() függvényét, itt találsz rá nagyon jó doksit és példát is: [.load()]
A dynamicdrive-os kód szerintem eléggé összegányolt/-tákolt, a jQuery-s kód pedig sokkal flexibilisebb, ráadásul kisebb és áttekinthetőbb kódot is eredményez szerintem.Ingyenes oldalnak Speeedfire kolléga korábban ezt javasolta: [link]
Állítólag ez fasza, ingyenes, gyors, nincs reklámcsík. Én még nem próbáltam, de biztos nem rossz.
Szerk.: bocs, most látom, a regisztráció úgy látszik, most leállt.Akkor csak olyat tudok, aminél domaint azért kell regisztrálni (az nem ingyenes, de nagyon kevésbe kerül, kábé egy havi üveg sör ára
): newhosting.hu .
Mondjuk itt ne várj túl nagy előzékenységet az ügyfélszolgálatosok részéről (tapasztalat)...Biztos valaki tud ajánlani más ingyenes, reklámcsíkmentes oldalt is.
-
#6791
Sk8erPeter
nagyúr
helloween35
#6790
Sk8erPeter
nagyúr
válasz
helloween35
#6790
üzenetére
Mutass kódot, hátha megtaláljuk benne a hibát (ha van).
-
#6789
Sk8erPeter
nagyúr
lalimano
#6788
Sk8erPeter
nagyúr
válasz
lalimano
#6788
üzenetére
Ha azt szeretnéd, hogy ne töltődjön újra az oldal, és a cím is változzon, mindenképpen AJAX-ot kell választanod. AJAX esetén is úgy oldható meg az, hogy a cím változzon, hogy hashmarkot (kettőskereszt - #) pakolsz a címek végére. Hogy a hashmarkkal ellátott címek Google által is indexelhetők legyenek, általában úgy szokták megoldani, hogy a hashmark után még kerül egy felkiáltójel is (#!), és utána következik a cím. Példa: http://oldalad.hu/valami.php#!/masikvalami.php
Erről itt található egy Google-cikk: [link].
Ha megfigyeled, Facebooknál is sokszor ezt a módszert alkalmazzák: a cím végére esetenként kerül egy #! jel, majd a megfelelő cím, és AJAX-szal töltődik be az új tartalom. (Nem mindig csapódik hozzá ez a fajta cím, de sűrűn.)Itt is van egy lehetséges megoldása a problémának: [link]. (Egyébként leegyszerűsített megoldás, mert így a háttérben a teljes tartalom újratöltődik, és csak a megfelelő részt kivéve csapja hozzá a főtartalomhoz.)
Ahogy elnézem, Te iframe-ekkel oldod meg, az úgy elég melós, nem is egy szép megoldás.
Ha még nincs nagy tapasztalatod a webfejlesztésben, javaslom, hogy az AJAX-os megoldást egyelőre még ne próbálgasd, mert nem egyszerű.
-
#6784
Sk8erPeter
nagyúr
vakondka
#6783
Sk8erPeter
nagyúr
válasz
vakondka
#6783
üzenetére
Jaja, ezt most kipróbáltam, és tökéletesen végezte a dolgát, ráadásul ingyenes (lehet UTF-8 BOM-mal és anélkül, gondolom többnyire neked is utóbbi kell):
UTFCast
Ebből az UTFCast Express-t töltsd le, az az ingyenes változat!
Az ingyenes annyival tud kevesebbet, hogy nem mutat preview-t, meg nincs multi-threading, de gondolom ez nem olyan nagy baj. Legfeljebb kicsit tovább tart. -
#6778
Sk8erPeter
nagyúr
Fokszmulder
#6776
Sk8erPeter
nagyúr
válasz
Fokszmulder
#6776
üzenetére
Pedig az elég jó arány.
-
#6774
Sk8erPeter
nagyúr
Fokszmulder
#6773
Sk8erPeter
nagyúr
válasz
Fokszmulder
#6773
üzenetére
Az igen...
Szóval azért kerested fel a PHP-topicot, hogy hazudhass mutternak. Ha Neptun, akkor egyetemről/főiskoláról van szó, nem? Egyetemi/főiskolai hallgató lévén még anyuci elporolja a fenekedet, ha nem sikerült valami tárgy? Egy hét szobafogság? Na jó, nem szivatlak, bocs. Dehát ha már ilyen témával nevettetted ki magad, muszáj.
Amúgy az oldalak megjelenését JavaScripttel lehet a legkönnyebben módosítani, akár még kiegészítőt is lehetne írni arra, hogy bizonyos jegyeket átírjon, nem is túl nehéz... De nem adok ötleteket.===
Szerk.:
(#6775) PazsitZ: de tényleg... Arra bezzeg van esze meg ideje, hogy ilyenekkel b@szakodjon! -
#6771
Sk8erPeter
nagyúr
Fokszmulder
#6770
Sk8erPeter
nagyúr
válasz
Fokszmulder
#6770
üzenetére
Megnyitod magát a fájlt külön, és úgy ne jelenjen meg? Hogy érted igazából, hogy "ne jelenjen meg a jpg"? Maga a kiterjesztés ne jelenjen meg, vagy az egész cím? Ne lehessen direkt linkelni? Vagy mi? Amúgy mindenféle kép forrását meg lehet szerezni valahogyan, vagy valami módszerrel legalábbis mindenképp ki lehet lopni a képet a weboldalról.
Akár azt akarod, hogy ne látsszon a jpg kiterjesztés, akár azt szeretnéd, hogy ne lehessen direkt linkelni, arra javaslom a .htaccess segítségével való RewriteRule alkalmazását.
Ezekről bőven lehet tutorialokat találni neten, magyarul is.De így a végére rájöttem, hogy valszeg azt szeretnéd, hogy csak simán mutassa meg neked a fájlt, de ne lehessen elérni közvetlenül.
Használhatod a jpeg-kép PHP-ből történő kiíratására pl. az imagejpeg függvényt: [link]. Itt egyből mutat példát is kódokkal egy kép sima kiíratására.
A közvetlen elérést meg a fentebb írt RewriteRule-ok alkalmazásával kerülheted el. -
#6763
Sk8erPeter
nagyúr
ubid
#6762
Sk8erPeter
nagyúr
"A kód hibátlan, xampp nem szereti a küldözgetést."
Mielőtt már megint mást kezdenél hibáztatni magad helyett: NEM a XAMPP-pal van a baj, nem igaz, hogy "nem szereti a küldözgetést", ne terjeszd ezeket a valótlan állításokat, mielőtt nem győződtél meg annak igazságtartalmáról...
Talán megfelelően kellene konfigurálni a php.ini fájlodat.
Itt leírják, hogyan kellene: [link].===
A <body> tages résznél arra gondoltam, hogy a <body> rész után kell kezdődnie az általános kiíratásoknak, amik az oldalad törzséhez tartoznak, de valószínűleg azért gondoltam, hogy a feldolgozásod ugyanabban a fájlban történik, mint ahol magának a formnak a kiíratása is, mert ömlesztve másoltad be a kódot. -
#6757
Sk8erPeter
nagyúr
ubid
#6752
Sk8erPeter
nagyúr
Amikor programozol, saját munkád meggyorsítása érdekében először próbáld végiggondolni emberi nyelven, hogy mit is szeretnél csinálni. Miután ez megvolt, és a gondolatmenet jó, akkor EZT próbáld lefordítani az adott programozási nyelv kódjára.
Annak, amit Te írtál, emberi nyelvre lefordítva semmi értelme.
Gondold végig, mit írtál az if feltételnél: ha üres a $_POST['neve'], $_POST['cime'] ÉS a $_POST['valami'] mező IS, akkor csinálja azt, amit az utána következő blokkba írtál. A blokkban pedig szerepel egy ilyen rész, ami pont totál ellenkezője az előbbi feltételeknek, amit írtál: ha NEM üres a $_POST['neve'], $_POST['cime'] ÉS a $_POST['valami'] mező SEM, akkor írja ki, hogy el lett küldve a cuccos. Szerinted mikor kellene belelépnie ebbe a feltételbe, ha ez a fentinek éppen a totális ellentettje? Segítek: soha. Remélem érzed a tökéletes ellentmondást. Így nyilván az else ág fog lefutni, vagyis kiírja, hogy hiba van.Ezentúl az már eleve hiba a HTML-résznél, hogy a <body> tag ELÉ írod ki az üzenetet. Írd ezutánra.
Harmadik dolog, hogy problémáztál azon, hogy nem érkezik meg az e-mail. Mégis mitől kellene megérkeznie? Mutasd már meg, hol küldted el egyáltalán a levelet...
Ismét segítek: SEHOL.Tehát még egyszer: előbb gondold végig, mit szeretnél, és csak ezután kezdj el kódolni.
Szerk.:
(#6756) ubid:
nézd meg a mail() függvény leírását: [link]Te ezt írtad:
$mailcimed="cim@domain.com";
...
if(@mail($mailcimed, $targy, "Név:".$neved."\n Címe:".$email."\n Valamije:".$szoveg."\n újabb bővítmények"))
....Magyarul mindig a $mailcimed lesz a címzett, ami a cim@domain.com. Miért is kéne megérkeznie bármilyen gmailes címre?
-
#6747
Sk8erPeter
nagyúr
Sk8erPeter
nagyúr
PDO-val kapcsolatos kérdésem lenne.
Van egy lekérdezésem, amiben az eredményeket növekvő vagy csökkenő sorrendben szeretném megjeleníteni, de úgy, hogy az 'ASC' vagy 'DESC' sztringet később szeretném belepasszírozni.
Valahogy az alábbi módon gondoltam, DE erre azt az eredményt adja, hogy rossz az SQL-szintaxis:$query_str = 'SELECT * FROM guestbook ORDER BY c_id :order ';
$order = (($this->ascending==true)?'ASC':'DESC');
$stmt = $this->dbh->prepare($query_str);
$stmt->bindValue(':order', $order, PDO::PARAM_STR);
$execution_result = $stmt->execute();Tehát mintha ebben az esetben ez az érték-hozzárendelés nem működne, csak akkor, amikor valamit egyenlővé teszek egy később megadott értékkel a lekérdezésben.
Lehet, hogy késő/korán van már, de most hirtelen nem jövök rá, hogyan is kellene ezt megoldani ehelyett, úgy, hogy ne kelljen a hagyományos csúnya sztringkonkatenálást alkalmazni.Köszi!
-
#6746
Sk8erPeter
nagyúr
Tele von Zsinór
#6744
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#6744
üzenetére
Hali!
Köszi, ezt is mindenképp ki fogom próbálni!
De időközben keresgéltem, és rátaláltam az Asido-ra, amiről korábban soha nem hallottam, csak Google segítségével akadtam rá, de eddig nagyon tetszik, kézenfekvő a használata, de még ráadásul jól is működik (utóbbi már sajnos komolyan meglep, azok után, amennyi hibás képkezelő szkriptet próbáltam).
Direkt próbálgattam szélsőséges eseteket, hogy mondjuk kábé kétszer akkora képet választok vízjelnek, mint amekkora az eredeti kép, amire a vízjelet tenni szeretném, plusz átméretezem arányosan az eredeti képet, de akkor is jól működik, tehát fel van készítve az ilyen lehetséges hibákra. Ez eddig nagyon bejön, mert számtalan képmanipuláló osztályt próbálgattam már, de azoknál ez általában szarul volt megoldva. Belenézegettem a kódjába, elég összeszedettnek tűnik.
A hibakezelésnél mondjuk engem az zavar, hogy a trigger_error() függvényt használja, ami mondjuk jóval kevésbé kezelhető elegánsan, mintha mondjuk kivétel-kezeléssel lenne megoldva.
Ettől függetlenül eddig eléggé meggyőzőnek tűnik (persze nem teszteltem agyon, még csak pár példát néztem meg vele), plusz a honlapon lévő példakódokból is látszik, hogy elég sokféle esetre gondolt a készítője.
GD2, Magick Wand és Image Magick kezelésére is fel van készítve.Holnap a phpThumb-ot is kipróbálom.
Amúgy meglepő, mennyire befolyásolja az ember véleményét egy honlap: amikor megláttam ennek a phpThumb-nak a honlapját, hogy milyen ocsmány, valahogy nem jött meg a kedvem, hogy kipróbáljam.Viszont van még egy ugyanilyen nevű, a PHP Thumb, aminek kifejezetten igényes a honlapja, ami valahogy eleve kíváncsivá teszi az embert, jól áttekinthető tutorialt mellékeltek hozzá, és a kódja szép és áttekinthető a doksi alapján.
Nálam jelenleg az volt a kizáró ok, amiért nem foglalkoztam vele, hogy asszem nem lehet vele vízjelezni, de egyébként nagyon tetszetős ez is.
Csak most sajnos nálam fontos szempont, hogy legyen megoldva a vízjelezés is, nem akarok szarakodni azzal, hogy ezt is meg kelljen írnom. -
#6743
Sk8erPeter
nagyúr
Frigo
#6742
Sk8erPeter
nagyúr
Hali!
Jaja, ez nagyon fasza LENNE, főleg a phMagick wrapper osztállyal, de sajnos a tárhelyen elég korlátozottak a lehetőségek, telepíteni nem lehet, és nyilván, maguktól ezt az osztályt nem telepítették...
Meg a phMagick-hez az exec() fv.-nek is engedélyezve kell lennie, mert ez elvileg rendszerhívásokat intéz.Tehát olyan megoldáshoz szeretnék folyamodni, amit nem kell telepíteni.
De azért köszi!Minden további ötletet szívesen várok!
-
#6741
Sk8erPeter
nagyúr
Sk8erPeter
nagyúr
Tudnátok linkelni JÓL BEVÁLT képkezelő osztályt? Tudjon arányos átméretezést és testreszabható vízjelezést (pl. kép melyik sarkába legyen pakolva vízjel, vagy hogyan is legyek egész pontos, lássa el logóval a képet), ezenfelül ne rontson a kép minőségén.
DE még jobb lenne, ha esetleg túl nagy méret esetén (azalatt NE) le tudna faragni a méretből mégis úgy, hogy kicsit butít a képen, hogy ne foglaljon el olyan rohadt nagy helyet (bár igaz, sok esetben az igazán nagy méretű képek jó nagy kiterjedésűek is, ha átméretezek, valószínűsíthetően a méret is jelentősen csökken - de nem mindig van így, mindegy, lényeg, hogy legyen valahogy megoldva).Lehet, hogy ez így egyszerre sok, nem tudom, én implementáltam ezekhez hasonló jellegű függvényeket (a 'butítós' módszert leszámítva) még jóval korábban, amikor azért a jelenlegihez képest is bőven voltak hiányosságaim (most is rengeteg van), és elég időigényes lenne újból, igényesen megírni, szépen osztályba szervezve, megfelelő hibakezeléssel (pl. dobjon kivételt).
Előre is köszönöm!
-
#6740
Sk8erPeter
nagyúr
Sk8erPeter
#6737
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#6737
üzenetére
Itt korrigálnám magam:
"(pl. Komodo IDE-ben vagy phpDesignerben rámész, hogy ugorjon a metódus deklarációjára, és akkor beleugrik abba a fájlba, ahol ezek megtalálhatók)"
Rájöttem, hogy pl. a dom.php nevű fájl, ami tartalmazza az osztály- és metódusdeklarációkat, a Komodo IDE-n keresztül csak azért elérhető, mert az Eclipse a projektkönyvtárba legenerált egy .metadata nevű könyvtárat, amin belül a .plugins/org.eclipse.php.core/__language__/d112eb25/ könyvtár tartalmazza jópár PHP függvény, osztály, metódus, különböző nyelvi elemek deklarációját.
Elég furcsa nevű könyvtár, azt a generált azonosítót a végén hirtelen nem vágom, minek kell odapakolnia (mivel történhet esetleges ütközés vagy hasonló, ami szükségessé tenné).Ezt miért nem a /home/user könyvtárba generálja, vagy valami olyan helyre, ami bárhonnan elérhető (akár Windows-on belül is pl. Users\<user>\akármi\)? Mondjuk speciel ebben az esetben nem volt baj, mert a Komodo IDE kevesebb erőforrást zabál, mint az Eclipse, és ugyanez igaz a phpDesignerre is, így egy ideje ezeket használom az Eclipse és NetBeans helyett is, nem ártott, hogy ott van az a projektfájl.
De lehet, hogy csak valami tévedés következtében került bele pont a projektkönyvtárba, és nem valami ésszerűbb helyre, most nem nyomoztam utána.Ja, és amúgy ha a projektkönyvtárban nincs benne az említett fenti könyvtár (aminek mondjuk gondolom nyilván más neve is lehetne, a lényeg, hogy a projektkönyvtáron belül megtalálható legyen valahol), akkor a definícióra ugrás nem működik, helyette hibaüzenetet kapok Komodo IDE-ben:
"Cannot show definition: symbol is defined in the stdlib or in an API catalog. Would you like to open the online language help for this symbol?"
Ekkor a Yes-re kattintva csak a hivatalos php.net-es dokumentációt hozza elő, amiből hirtelen nehezebb kiigazodni, mint a metódusfejlécek fölötti kommentekből. -
#6737
Sk8erPeter
nagyúr
Inv1sus
#6735
Sk8erPeter
nagyúr
válasz
Inv1sus
#6735
üzenetére
Adott oldal meghatározott tartalmának kiszedéséhez javaslom a DOMDocument osztály tanulmányozását. (többi, DOM-mal kapcsolatos osztály: [link])
Itt is elérhetők olyan függvények, mint JavaScriptben, hogy getElementById(), getElementsByTagName(), stb.
A dokumentációja php.net-en mondjuk elég gyenge, nekem elég sokat kellett tanulmányoznom a metódusok fejlécei fölött lévő kommentelt részeket, amik a dom.php-ben elérhetők voltak (pl. Komodo IDE-ben vagy phpDesignerben rámész, hogy ugorjon a metódus deklarációjára, és akkor beleugrik abba a fájlba, ahol ezek megtalálhatók).
Viszont nagyon hasznos, jól működik.Persze az input mezőből történő submitolást már JavaScripttel kéne elintézned.
-
#6730
Sk8erPeter
nagyúr
D@ni88
#6729
Sk8erPeter
nagyúr
[link]
"Essentially they are ZIP files that are full of XML files that when opened with the a proper application turn into a friendly word document."Kínál lehetséges .htaccess-es megoldást is a problémára.
AddType application/vnd.ms-word.document.macroEnabled.12 .docm
AddType application/vnd.openxmlformats-officedocument.wordprocessingml.document docx
AddType application/vnd.openxmlformats-officedocument.wordprocessingml.template dotx
AddType application/vnd.ms-powerpoint.template.macroEnabled.12 potm
AddType application/vnd.openxmlformats-officedocument.presentationml.template potx
AddType application/vnd.ms-powerpoint.addin.macroEnabled.12 ppam
AddType application/vnd.ms-powerpoint.slideshow.macroEnabled.12 ppsm
AddType application/vnd.openxmlformats-officedocument.presentationml.slideshow ppsx
AddType application/vnd.ms-powerpoint.presentation.macroEnabled.12 pptm
AddType application/vnd.openxmlformats-officedocument.presentationml.presentation pptx
AddType application/vnd.ms-excel.addin.macroEnabled.12 xlam
AddType application/vnd.ms-excel.sheet.binary.macroEnabled.12 xlsb
AddType application/vnd.ms-excel.sheet.macroEnabled.12 xlsm
AddType application/vnd.openxmlformats-officedocument.spreadsheetml.sheet xlsx
AddType application/vnd.ms-excel.template.macroEnabled.12 xltm
AddType application/vnd.openxmlformats-officedocument.spreadsheetml.template xltx -
#6715
Sk8erPeter
nagyúr
D@ni88
#6714
Sk8erPeter
nagyúr
Azzal van baja, hogy a $message változóhoz, ami akkor szerepelt először, hozzá akarod fűzni a $message változót, amiben még nyilvánvalóan nincs tartalom (a kiértékelés jobbról balra történik).
Valahogy így:
...
$message = "This is........" . $message . "\n\n";
A megoldás egész egyszerűen annyi, hogy azt a $message hozzáfűzést a 20. sorban szedd ki. A többi helyen maradhat.Ha csatolmányokat akarsz küldeni, javaslom, hogy használd erre a célra inkább a PHPMailert, SwiftMailert, stb...
Meg amúgy is... -
#6703
Sk8erPeter
nagyúr
D@ni88
#6701
Sk8erPeter
nagyúr
Kiegészítve Tele von Zsinór hozzászólását:
ha a form action attribútumánál a PHP_SELF-re szeretnél hivatkozni, akkor igazából tök felesleges kitölteni az action attribútumot, egyszerűen hagyd üresen, és kész. Ezzel a problémád meg is oldódott, és az oldalad kódja valid marad.
Megerősítésként lásd ezt is: [link]
Tehát ez működőképes:
<form action="" method="post">
<p><input type="submit" /></p>
</form> -
#6699
Sk8erPeter
nagyúr
Alukard
#6697
Sk8erPeter
nagyúr
válasz
Alukard
#6697
üzenetére
A korábban megmutatott függvényekkel nincs semmi baj, ha erre gondolsz, azok használati módjával van baj, ahogy cucka le is írta. Nyugodtan használd az ott szereplő függvényeket, csak jó sorrendben, jó helyen.
A saját kódok írogatásának előnye, hogy előbb-utóbb belédrögzül egy csomó minden, rengeteget lehet így tanulni - de persze sok buktató is van az elején. Plusz sok a gányolás. Azon a korszakon mindenki átesik. Mindkét módszernek van előnye, a másik előnyeit Tele von Zsinór előttem leírta.
-
#6696
Sk8erPeter
nagyúr
Alukard
#6694
Sk8erPeter
nagyúr
válasz
Alukard
#6694
üzenetére
"megtanulom, hogy hogyan ne gányoljak kezdőként (annyira)"
Akkor első lépésként gyorsan felejtsd el azt a tanácsot, hogy kapcsold ki a notice-ok jelzését (fejlesztésnél NE kapcsold ki), és ahol nem nagyon-nagyon muszáj, ott ne használd a kukac jelet a hibaüzenetek elnyomására, hanem oldd meg másképp. -
#6692
Sk8erPeter
nagyúr
fordfairlane
#6687
Sk8erPeter
nagyúr
válasz
fordfairlane
#6687
üzenetére
"Mindenesetre a notice problémát leggyorsabban static változódefinícióval lehet megoldani. Esetleg kikapcsolni a notice-ok kijelzését."
Ha tényleg ilyen megoldásokat alkalmazol, akkor látom keményen megtanultad az évek alatt, hogy hogyan lehet a legkörmönfontabban elnyomni a hibák kijelzését úgy, hogy lehetőleg ne zavarjon a fejlesztésben, ja és sűrűn használhatod ilyen alapon a @ (kukac) jelet is a hibák elnyomására, az biztos mindent megold!Visszatérő téma...
-
#6680
Sk8erPeter
nagyúr
cucka
#6679
Sk8erPeter
nagyúr
Ja persze, az nem is baj, hogy opcionális, azt speciel nem hibaként írtam (vagy nem úgy akartam).
Majd lehet, hogy megpróbálom jelezni a szerzők felé, hogy esetleg azt javíthatnák, hogy legyen egy getter metódusa a hibáknak, bár nem tudom, mennyire fogják figyelembe venni a véleményezést. -
#6672
Sk8erPeter
nagyúr
cucka
#6671
Sk8erPeter
nagyúr
"Errorinfo protected (v. private) kéne legyen és kéne mellé írni egy getErrorInfo()-t."
És én szerinted mit mondtam? Ugyanezt.
"Vagy maradhat public, de akkor a __set-ben le kell kezelni azt az esetet, amikor kívülről piszkálják. (Egyébként simán elképzelhető, hogy le van kezelve, csak elkerülte a figyelmedet, nincs előttem a phpmailer forrása)"
Szerinted miért mondtam azt, amit mondtam? Mert néztem a forráskódot, és TUDOM, hogy nincs lekezelve... Azért nem kell eleve hülyének nézni az embert. Egyébként meg a "miért férek hozzá" költői kérdés volt...nyilván tudom, hogy ennek nem így kell lennie, pont erről magyaráztam, hogy szar a koncepció.
Az ErrorInfo-ra vonatkozó rész:
public $ErrorInfo = '';
Ennyi, ezt lehet beállítani a SetError() metódusban.
__set() mágikus függvényhasználat NINCS sehol (ezt sem kútfőből szedtem, hanem a forráskódot tanulmányozva jelentem ki...)
Van egy sima set() függvény, ami alatt van egy ilyen sor:
@todo Should this not be using __set() magic function?A karakterkódolási stringekről meg annyit, hogy ha már felsorolták szinte az összes MIME-típust is a _mime_types fv.-ben, akkor ez is belefért volna.
Persze ez nem számít igazán hibának."Igen, de az én kivételeim nem jelennek meg a képernyőn, hanem kapok róluk szépen formázott emailt (és ugyanez igaz a hibákra is)
"
Nálam is ugyanez a helyzet... Ez attól még nem mond ellent annak, hogy elegánsabb, ha kivételt dobál az osztály, és azt a megfelelő helyen elkapjuk, mintha kiszednénk a publikus ErrorInfo stringből a hibát, ha a Send false-szal tér vissza... -
#6670
Sk8erPeter
nagyúr
Sk8erPeter
#6669
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#6669
üzenetére
Ja igen, és a SetError() metódus protected, míg maga a tagváltozó ($ErrorInfo) nem, ez kissé egészségtelen koncepció szerintem.
A SetError helyesen protected, de magának a tagváltozónak is legfeljebb annak kéne lennie... -
#6669
Sk8erPeter
nagyúr
cucka
#6665
Sk8erPeter
nagyúr
Amúgy ez fura, azt nézem, hogy a PHPMailer osztályban (5.1) egyáltalán nincs is ellenőrzés arra vonatkozóan, hogy a felhasználó nem cseszte-e el a karakterkódolás bepötyögését, pl. egy karakterkódolás-beállító függvény formájában, ellenben rengeteg tagváltozó publikus, ami szerintem kicsit ellentmond a klasszikus OOP-elveknek (persze nem csak erről szól az OOP, de ha már lehet, egy helyen megvalósítjuk a változók beállításának megfelelő ellenőrzését is - egyből a beállításkor).
Ez már csak azért is szar, mert bármikor megcsinálhatnám, hogy tételezzük fel, úgy van példányosítva az osztály, hogy nem dobál kivételeket, de történik valami hiba, aztán én mondjuk ezt csinálom:
$mail->ErrorInfo = null;
vagy hasonlót - miért férek hozzá kívülről az ErrorInfo-hoz?
Nekem ez kicsit furcsa. Persze ennek semmi értelme, hogy én ezt csináljam, csak saját magamat szívatnám vele, de szerintem a lehetőség se legyen meg rá, hogy az ember ekkora baromságot csináljon, ha már OOP, és lehetne mondjuk protected (private nem lenne jó az esetleges leszármaztatás miatt).
Lehet, hogy a függvénybe ugrálásnak nagyobb az overheadje, de szerintem itt mondjuk nem számítana a különbség - így lehetne pl. egy setCharSet() metódus vagy valami hasonló, amiben elsőként ellenőrzi a függvény a kapott paramétert, hogy létezik-e egyáltalán olyan karakterkódolás, és amennyiben nem, akkor dobna egy kivételt (vagy beállítaná az ErrorInfo változót, és kiírná a hibát, ha úgy van beállítva (default)).(Egyébként gondolom Te is így példányosítod a PHPMailert:
$mail=new phpmailer( true );
hogy dobáljon kivételeket, nem?) -
#6661
Sk8erPeter
nagyúr
lesaux
#6660
Sk8erPeter
nagyúr
Nincs mit. És végül melyik megoldást választottad?
PHPMailer vagy egyéb?Hogy érted, hogy nincsenek ékezetek? Krikszkrakszokat rak be helyette? A karakterkódolásnak stimmelnie kell, tehát a dokumentumnak, amiből küldöd, szintén UTF-8-nak kell lennie, ha a levelezőrendszert is arra állítottad. Vagy fordítva, a levelezőrendszert "hangold" a másik karakterkódolásra.
-
#6659
Sk8erPeter
nagyúr
Alukard
#6658
Sk8erPeter
nagyúr
válasz
Alukard
#6658
üzenetére
Pl. ezek közül válogass.
De ez nem PHP-kérdés. -
#6652
Sk8erPeter
nagyúr
lesaux
#6651
Sk8erPeter
nagyúr
Fentebb van az e-mail-küldésre használható függvény, amit írtam neked.
Abban van az alábbi rész kikommentezve, ott szedd ki a kommentet (a /* nyitó és */ záró részt), majd az if(IS_LOCALHOST){ sort is, meg ennek a blokknak a záró kapcsos zárójelét ( } ), és hagyd bent az alábbi részt, úgy, hogy a megfelelő helyekre a saját adataidat írod (SMTP_HOST, SMTP_USER, SMTP_PASS konstansokat cseréld le a sajátodra):
//küldjük SMTP-vel
$mail->Mailer = 'smtp';
$mail->SMTPAuth = 'true';
$mail->Host = SMTP_HOST;
$mail->Username = SMTP_USER;
$mail->Password = SMTP_PASS; -
#6646
Sk8erPeter
nagyúr
lesaux
#6645
Sk8erPeter
nagyúr
Próbáld ki akkor a PHPMailerrel, töltsd le, majd másold a megfelelő helyre, amit majd beállítasz a $phpmailer_path változóban. Tehát ezt változtasd meg annak a helyére, ahova pakolod a fájlt!
Aztán másold be az alábbi függvényt annak a fájlnak az elejére, ahol a levélküldést szeretnéd csinálni (egy részt kikommenteztem benne, ami neked most valszeg nem kell, meg nálam definiálva van egy-két konstans egy konfigfájlban, de bennehagytam, hátha mégis szükség lesz SMTP-küldésre később). Függvénybe tettem, hogy ne kelljen mindenhol külön megírni:
/**
* send_email() - E-mail küldése (localhoston SMTP-vel)
* Kivétel: phpmailerException() levélküldési hiba esetén
* Exception(), ha nem létezik a fájl vagy nem elérhető
*
* @param string $to
* @param string $toName
* @param string $from
* @param string $fromName
* @param string $subject
* @param string $message
* @return none
*/
function send_email( $to, $toName, $from, $fromName, $subject, $message ) {
$phpmailer_path = $_SERVER['DOCUMENT_ROOT'].'/PHP/classes/class.phpmailer.php';
if(!file_exists($phpmailer_path)){
throw new Exception('Nem elérhető a PHPMailer osztály!');
}
//PHPMailer osztályt include-oljuk
require_once($phpmailer_path);
// példányosítjuk a PHPMailer osztályt, és jelezzük, hogy szeretnénk,
// ha kivételeket dobna (ne írja ki egyből a képernyőre a hibaüzeneteket)
$mail=new PHPMailer( true );
// karakterkészlet
$mail->CharSet = 'utf-8';
// feladó címe
$mail->From = $from;
// feladó neve
$mail->FromName = $fromName;
// címzett; címzett neve
$mail->AddAddress( $to, $toName );
// tárgy
$mail->Subject= $subject;
// levéltörzs
$basedir = $_SERVER['DOCUMENT_ROOT']; //pl. esetleges csatolandó képek miatt (így stimmel az elérési út)
$mail->MsgHTML($message, $basedir);
/*
//csak saját gépen küldjük SMTP-vel
if(IS_LOCALHOST){
$mail->Mailer = 'smtp';
$mail->SMTPAuth = 'true';
$mail->Host = SMTP_HOST;
$mail->Username = SMTP_USER;
$mail->Password = SMTP_PASS;
}
*/
// a levél elküldése
$mail->Send();
}Majd amikor magát a levélküldést szeretnéd végrehajtani, a sima mail() függvényed és a mostaniak HELYETT ezt tedd be:
$to = 'le****@vipmail.hu';
$toName = 'lesaux';
$from = 'nemtom@lepesfalvi.hu';
$fromName = 'Valaki János';
$subject = 'Új látogató érkezett';
$host = gethostbyaddr($_SERVER["REMOTE_ADDR"]);
$visitor_IP = $_SERVER['REMOTE_ADDR'];
$message = "Új vendég nyitotta meg az oldalt!\nIP-je: $visitor_IP\nHostja: $host";
// a levél elküldése
try { //kivétel, ha nem sikerült az elküldés...
send_email( $to, $toName, $from, $fromName, $subject, nl2br($message) );
} catch (Exception $e) {
echo ' Hiba a levélküldés során (log_errors()): '.$e->getMessage();
}Persze a hibaüzenetet nem muszáj echo-zni, ha naplózol, de azt már rádbízom.
Remélem így már működni fog! Ne felejtsd el a $phpmailer_path változót beállítani arra a helyre, ahova Te pakolod a class.phpmailer.php fájlt!
(Bár persze nem garancia az, hogy most a PHPMailer osztályt használod a klasszikus mail() függvény helyett, hogy most már elfogadja a leveledet a szerver, amire küldöd. De legalább most már PHPMailer osztállyal küldesz levelet, amúgy is ajánlott inkább ilyen vagy ehhez hasonló levelezőosztállyal küldeni.)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
(Átfutva a hsz.-edet valóban az maradt meg, hogy MySQL, mert az esetek 95%-ában itt ahhoz szoktak segítséget kérni, nem figyeltem, sorry.)
Egyébként nem is csak a végleges méretről beszéltem, hanem arról, hogy PHP-ben a sztringkonkatenálás lassú, tehát plusz időbe is kerül...ezért nem érdemes vele elvégeztetni ott, ahol totálisan felesleges.
Mégis 404-et küld vissza, nem véletlenül.
(nehogy megsértődj, csak viccelek, de sosincs tökéletes megoldás 
Ismét segítek: SEHOL.
Új hozzászólás Aktív témák
Hirdetés
- Dell Precision 7560 15.6" FHD IPS i5-11500H RTX A3000 32GB 512GB NVMe gar
- SAMSUNG 1TB 990 PRO M.2 NVME PCI-E 4.0 x4 - Új - 7450-6900 MBs - Eladó!
- Thinkpad T14 Gen4 14" FHD+ IPS i5-1345U 16GB 256GB NVMe magyar vbill gar
- L14 Gen1 27% 14" FHD IPS Ryzen 5 4500U 16GB 256GB NVMe ujjolv új akku gar
- Thinkpad T14s Gen3 14" FHD+ IPS i5-1245U 16GB 256GB NVMe IR kam gar
- Bomba ár HP X360 11 G5 - Intel 4020 I 4GB I 128GB SSD I 11,6" HD Touch I Cam I W11 I Garancia!
- Realme 7i 64GB, Kártyafüggetlen, 1 Év Garanciával
- Ikea Eilif Paraván - Asztali elválasztó
- Xbox Game Pass Ultimate kedvező áron, egyenesen a Microsoft-tól! - AUTOMATA BOLT
- Telefon felváráslás!! Xiaomi 13T, Xiaomi 13T Pro, Xiaomi 14T, Xiaomi 14T Pro
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest