- gban: Ingyen kellene, de tegnapra
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- Gurulunk, WAZE?!
- Geri Bátyó: B550 szűk keresztmetszet, de mi és miért?
- sh4d0w: Csak a profit - emberélet nem számít
- vrob: Az IBM PC és a játékok a 80-as években
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Magga: PLEX: multimédia az egész lakásban
Új hozzászólás Aktív témák
-
#21200
polymorphin
csendes tag
#68216320
#21178
polymorphin
csendes tag
válasz
#68216320
#21178
üzenetére
Java (spring?) utan erthetobb lesz, a Laravelben tul sok a "magic", megsporolsz par WTF-ot. De igazabol a Laravel is oke ha gyosran ossze akarsz dobni valami hasznhatot. IDE-nek egyertelmuen PhpStorm (EAP ingyenes ahogy emlitettek).
Ami meg standard a PHP vilagban:
- PhpUnit: unit, feature tesztekhez
- xDebug, debugger
- PHPCS, coding standard (formazas)
- psalm/phpstan, statikus analizis, pluszban docblockban tudsz arrayshape-et, generics-et hasznalni#21193
Laravel dokumentacioja eleg jo pedig, foleg kezdoknek, konyvet senki nem hasznal. -
pelyib
tag
válasz
#68216320
#21171
üzenetére
PHPStormnak van egy EAP (early access program) nevu valtozata, ami ingyenes. Amikor lejar, torlod, letoltod az ujat, telepites, folytatod ahol felbeszakadt.
VS Code is egesz hasznalhato, kell par plugin (opcionalisan az Intelephense pluszban). En a devcontainer megoldasat nagyon kedvelem.
Onsanyargatoknak meg termeszetesen VIM, en az utobbi fel evben a NeoVim-t hasznalom, nem egy PHPStorm de nekem bejon. Termeszetesen ennek a setupolasahoz egy elet is keves
-
coco2
őstag
válasz
#68216320
#21171
üzenetére
A válasz attól is függ, mennyire szeretnéd megérteni azt, amit csinálsz? Ha csak legyen kész, használj bármit, amire copy / paste-elhető példákat találsz. Összehajigálsz mindent tech stack-be, és reméled, hogy soha semmi nem lesz hibás későbbi verziókban, nem fognak összeakadni a dolgok és társai
Ha meg alapokat tanulni szeretnél, maga a php már egy framework, afölött nincsen szükséged másikra. Ami kell, osztályok formájában megírod te, és lesz talán egy kicsi rálátásod arra, néhány FW-ben miért úgy vannak a dolgok, ahogy, illetve felis mered majd már ránézésre a feature-ök alapján, ha némelyik eszköz egy összehajigált vacak. A csapásirány árnyoldala, hogy temérdek sok időt fogsz elhasználni tanulásra, ami közvetlenül nem hasznos. Ha türelmed nincs - sok türelmed - inkább az első opciódat válaszd. -
nevemfel
senior tag
-
miroon
aktív tag
válasz
#68216320
#21171
üzenetére
Szia!
IDE-nek phphoz én a PhpStorm-ot mondanám
Vannak külön laravel helper, symfony helper stb bővítmények amikkel még tovább lehet okosítani.A framework elég sok mindentől függ szerintem, én laravel párti vagyok.. de ha nagyjából ismered a laravelt akkor egy symfonys projekt se fog rajtad kifogni - és ez szerintem fordítva is igaz.
Laravelnek szerintem az egyik nagy előnye,hogy baromira jól dokumentált.
-
pelyib
tag
válasz
#68216320
#19993
üzenetére
cli-ben:
belepsz a project konvytarabaphp /eleresi/ut/composer.phar init
Initcializalod a projectet, ertelemszeruen valaszolsz, ezzel letrejon a composer.json file.
Bovebbenmajd
php /eleresi/ut/composer.phar require clegginabox/pdf-merger:dev-master
BovebbenEkkor mar van a project konyvtarban egy ./vendor konyvtar, abban pedig egy autoload.php
Ennek az fajlnak a betoltese kell kb az elso lepesnek lennie az alkalmazasodban.
BovebbenOrom, boldogsag. Ha nem akarsz rogton a projectedben jatszani, akkor letrehozol egy ures foldert, es ott ugyan ezeket megteszed, es figyeled az eredemenyt.
-
#68216320
törölt tag
válasz
#68216320
#19385
üzenetére
Ez így működik, de akkor minden fájl elejére kelleni fog behívni az autoloader-t? Valahogy nem lehet automatikusan használtatni vele, ha use-t lát?
<?php
spl_autoload_register(function ($class_name) {
include $class_name . '.php';
});
use Model\TestModel;
$test = new TestModel();
$test->testMethod();
?> -
#18492
PumpkinSeed
addikt
#68216320
#18491
PumpkinSeed
addikt
válasz
#68216320
#18491
üzenetére
A Laravel-nek nagyon jó a dokumentációja pl itt egy csomó tutorial: [link], illetve itt a teljes videó a kezdetektől, hogy mi fán is terem a Laravel, és hogyan kellene használni.
-
#18092
fordfairlane
veterán
#68216320
#18085
fordfairlane
veterán
válasz
#68216320
#18085
üzenetére
Ti milyen megoldást használtok ilyen esetben?
A kettő nem zárja ki egymást. Kezelheted a form kirajzolását, a form submitot és a hibakezelést egy helyről, egy handlerből, de a részműveletek több helyen. Itt kettészedtem nézetre és minden másra. Természetesen ez így még mindig nagyon kezdetleges, de remélem, átjön a lényeg, és az újraküldés ellen védett.
form_handler:
<?php
$form_errors = array();
if($_SERVER["REQUEST_METHOD"] == "POST") {
// validálás
$form_errors["email"] = "Ez az email már foglalt";
$if(!count($form_errors)) {
// mentés
// ...
header("Location: " . $_SERVER["SCRIPT_NAME"] . "?success=1");
exit;
}
}
$success = isset($_GET["success"]?true:false);
require_once("form.php");form.php:
<?php
<?php if(success): ?>
A regisztráció perfektül organizálódik.
<?php endif; ?>
<form method="post">
<input type="text" name="email">
<?php if(isset($form_errors["email"])): ?>
<div class="errorlabel"><?=htmlspecialchars($form_errors["email"])?></div>
<?php endif; ?>
</form> -
#18090
Sk8erPeter
nagyúr
#68216320
#18085
Sk8erPeter
nagyúr
válasz
#68216320
#18085
üzenetére
Az első mindenképpen ocsmány megoldás, mivel így nem válik szét a megjelenítés és az adatok validálása, feldolgozása, adatbázisba írása (meg hasonló műveletek). A form kiírásának semmi köze nem szabadna, hogy legyen ahhoz, hogy aztán mit kezdesz az adataiddal. Szóval mindenképp válaszd külön a kettőt. Ezért szokás szétválasztani a különböző rétegeket (lásd MVC-szemlélet és társai).
-
#18080
Tele von Zsinór
őstag
#68216320
#18079
-
DNReNTi
őstag
válasz
#68216320
#18074
üzenetére
Írtam rá egy sima egyszerű random string generátort, egy while ciklusban 32 karaktert dob össze, kisbetű-nagybetű-számok kombinációból, aztán ellenőrzi hogy létezik e már, ha igen kezdi elölről. Elég kicsi az esélye amúgy, hogy bármikor is újat kelljen generálni, de az ördög nem alszik, így üzembiztos. Ezenkívül persze az adatbázisban a hash mező unique. Ezzel nekem még sosem volt gond.
-
DNReNTi
őstag
válasz
#68216320
#18072
üzenetére
Nálam erre a bevált módszer egy random, de egyedi hash generálása adott eseményhez, ilyen az aktiválás, elfelejtett jelszó, fiók törlés, email cím változtatás. Külön táblában tárolom ezeket a felhasználóhoz és az eseménytípushoz kötve. Én törölni sem szoktam, de nagyobb felhasználóbázisnál, azért érdemes egy ütemezett archiválás.
-
#18000
Sk8erPeter
nagyúr
#68216320
#17999
Sk8erPeter
nagyúr
válasz
#68216320
#17999
üzenetére
Nem, nem az a baj vele, hogy nem "hordozható", hanem hogy túl sok mindent akar csinálni az osztályod - éppen ahogy j0k3r! írta, és tök igaza van -, olyat is, ami nem tartozik az ő hatáskörébe, és hogy idézzem a kollégát, "A te esetedben a User osztálynak csak annyi dolga kellene, hogy legyen, hogy egy ilyen entitást leírjon". Tehát ha van egy felhasználó osztályod, akkor az írjon le felhasználóra vonatkozó attribútumokat (milyen tulajdonságai vannak) és műveleteket (miket tud a felhasználó csinálni), de ne lehessen vele tök más felhasználókat is szerkesztgetni, törölgetni, hozzáadni, mert az már nem tartozik rá, hogy az adatbázisban milyen egyéb felhasználók vannak, főleg nem szabad itt, hogy azokat még kezelgetni is tudja. Ilyesmire tényleg egy külön osztály való, aki kezeli ezeket az entitásokat egy "magasabb" szinten, és ő tudhat is róla, hogy milyen felhasználók vannak.
-
j0k3r!
őstag
válasz
#68216320
#17997
üzenetére
OOP során egy ökölszabály, hogy egy osztály csakis egy valamiért feleljen ([link])
A te esetedben a User osztálynak csak annyi dolga kellene, hogy legyen, hogy egy ilyen entitást leírjon. Kicsit magyarosan (és csúnyán) fogalmazva a User osztálynak nem kell tudnia arról, hogy ő hogyan van tárolva a háttérben (MySQL, xySQL, stb.), mivel őt mentik el, nem pedig ő ment.
A leírtak alapján valami ilyesmi vonalon indulnék el:
User {
Id
FirstName
LastName
Email
// other properties
getFullName()
// other helper methods
}
SignInManager {
Login(email, password, persistent)
Logout()
}
UserManager {
AddUser(User user)
EditUser(User user)
DeleteUser(userId)
} -
j0k3r!
őstag
válasz
#68216320
#17993
üzenetére
Add át ctor paraméterként, és akkor már sokkal szebb lesz a kód, illetve egy fontos programozási (OOP) alapelv is teljesülni fog: [link]
Miért van a User osztálynak AddUser metódusa? Ezt inkább valami User/AccountManager jellegű osztályba tenném. Szerintem ezt gondold át még egyszer
-
#17994
Sk8erPeter
nagyúr
#68216320
#17993
Sk8erPeter
nagyúr
válasz
#68216320
#17993
üzenetére
Ez így tényleg ronda, eleve kerülendő globális változókat használni, de miért nem passzolod át egyszerűen akár a konstruktorban, akár valamelyik metódus paramétereként a szükséges változót?
(#17989) mobal:
Jól hangzik elméletben, de a szolgáltatók többségénél még mindig nem MariaDB van, hanem MySQL. -
sztanozs
veterán
válasz
#68216320
#17800
üzenetére
bindValue(":valami_ertek", null, PDO::PARAM_INT);
esetleg
bindValue(":valami_ertek", isset($postValamiErtek) ? $postValamiErtek : null, PDO::PARAM_INT);
Ha 0 értéket szeretnél állítani, akkor esetleg:
bindValue(":valami_ertek", isset($postValamiErtek) ? $postValamiErtek : 0, PDO::PARAM_INT); -
#17588
Sk8erPeter
nagyúr
#68216320
#17587
Sk8erPeter
nagyúr
válasz
#68216320
#17587
üzenetére
Hát igen, az az egyik példa phpMyAdmin-alternatívának, úgy tudom, a phpMyAdmin egyáltalán nem működik MySQLi-kiterjesztés nélkül (pl. PDO-val).
Igazából ha korábban MySQLi-t használtál, akkor nem szabad, hogy nagy érvágás legyen átállni PDO-ra. A PDO-nak más szintaktikája van, szerintem egy fokkal könnyebben használható (számomra legalábbis jobban "kézreáll" az API), a prepared statementeknél használhatóak nevesített placeholderek (érdemes használnod, nem pedig a MySQLi-ből megszokott kérdőjeleket, persze ezek is működnek, sőt, van olyan eset, amikor pont erre van szükség (pl. amikor dinamikusan állít össze az ember egy előkészített utasítást)), és egyéb előnyei is vannak, valószínűleg nem lesz túl sok problémád az átállással.
Szoktam linkelgetni a topicban Tele von Zsinór kolléga PDO-val kapcsolatos cikkét, fusd át, mert igazából minden lényeges dolog benne van az elinduláshoz (pl. ami fontos, hogy a kapcsolat inicializálásakor a karakterkódolást kapásból UTF-8-ra állítja, ÉS hiba esetén exceptionök dobására utasítja a PDO-t). -
#17582
fordfairlane
veterán
#68216320
#17580
fordfairlane
veterán
válasz
#68216320
#17580
üzenetére
Sok framework meg CMS használja a PDO-t, ezért a PDO jelenlétének esélye elég nagy. Kábé 5-6 éve nem használok más DB API-t. Nem is értem, mások miért foglalkoznak még ezekkel a mysql* meg mysqli* könyvtárakkal. Persze a mysql régről maradhatott, de a mysqli-re, mint vendor specifikus könyvtárra nincs igazán indok.
-
Zedz
addikt
válasz
#68216320
#17577
üzenetére
Csak mysql_ támogatott? Nem vagyok nagy PHP guru, de ha jól tudom ez már nem támogatott dolog, így ha saját szakállra dolgozol azon a tárhelyen, szerintem keress másikat. Miért fontos, hogy mind a kettő támogatva legyen?
-
cucka
addikt
válasz
#68216320
#17264
üzenetére
Ez esetben generáld le a képeket on-the-fly. Nem tudom, minek kell sz*pasd magad a base64-el. PHP-ból ugyanúgy ki tudsz szolgálni egy bináris jpeg filet, mint egy sima html-t, csak be kell állítani a megfelelő header-öket.
(Arra gondolj, hogy ha van egy html oldalad ahol van 100 ilyen generált kép, na az lassú lesz. Ez esetben fizess be egy nagyobb tárhelyre és generáld le előre a különböző verziókat. Esetleg csinálhatsz intelligens cache-elést, ahol a gyakran használt fileokat legenerálod előre, a ritkábbakat meg ad-hoc. Ez van, szarból nem lehet ostort fonni.) -
#17263
Sk8erPeter
nagyúr
#68216320
#17260
-
válasz
#68216320
#17258
üzenetére
A CPU idő és RAM többe kerül mint a tárhely, de te tudod...
Ha pedig komolyan probléma a sok kép kezelése, akkor CDN használatát javaslom.(#17260) PeachMan
ha az oldal betöltődik már nem kell a képre várni, az egész egyben jelenik meg
A base64 kódolás 33%-kal nagyobb méretet eredményez, az nem probléma ha tovább tart az oldal betöltése?másrészt nincs cache-elve és képcsere esetén rögtön az újat látom
A cache használatának oka van.
A problémák elkerülésére új fájlnevet szokás adni pl. img.jpg?v=123 -
-
disy68
aktív tag
válasz
#68216320
#17208
üzenetére
Ez már erősen a javascript topicba való, ha további kérdés lesz, azt inkább oda:
Az első a DOM manipuláció. Ajánlani tudom ennek kezelésére (és sok egyéb feladathoz is) a jQuery használatát. Nagyon jól lehet vele a DOM elemeket kezelni a CSS-ből is ismerős selectorok segítségével. Így el tudod érni az általad kívánt elemeket (form-ot pl. id vagy class alapján) és azt csinálsz vele, amit szeretnél.
A második a DOM események felhasználása. Az eseményekhez különböző (akár több) eseménykezelőt köthetünk, amiben az esemény hatására csinálunk dolgokat (pl. egy select változás eseményére megváltoztatjuk a formunkat).
És egy kis szemléltető form változtatásra jQuery segítségével.
-
#17139
fordfairlane
veterán
#68216320
#17137
fordfairlane
veterán
-
-
#17059
Sk8erPeter
nagyúr
#68216320
#17057
Sk8erPeter
nagyúr
válasz
#68216320
#17057
üzenetére
Most, hogy engedélyezted, cseréld is le az összeset
https://gist.github.com/jankkhvej/1117678 -
disy68
aktív tag
válasz
#68216320
#16887
üzenetére
Ez a kiszolgáló beállításától függ, milyen hash függvényt használ hány bit/karakter:
128-bit digest (MD5)
4 bits/char: 32 char SID
5 bits/char: 26 char SID
6 bits/char: 22 char SID160-bit digest (SHA-1)
4 bits/char: 40 char SID
5 bits/char: 32 char SID
6 bits/char: 27 char SIDA vonatkozó beállítások: session.hash_function és session.hash_bits_per_character
-
#16731
fordfairlane
veterán
#68216320
#16730
fordfairlane
veterán
válasz
#68216320
#16730
üzenetére
Nem tudom mik ezek, de a httpd-sni.conf-ból lestem ki.
Az AllowOverride valami olyasmi, hogy engedélyezheted, hogy .htaccess-ből milyen webszerver-direktívát írhatsz felül.
Most hogy jobban megnéztem a httpd.conf-ot, két AllowOverride is van benne. Egy általános jellegű, és egy a webroot directoryjára. Elég az utóbbinál engedélyezni a .htaccess-t. Illetve az "All" sem feltétlen szükséges, le lehet szűkíteni a felülírható direktívák körét a megfelelő kulcsszóval. Persze ha dev szerverről van szó, akkor nem érdemes ennyire belemenni a részletekbe.
Ez nyilván biztonsági megfontolásokból van így beállítva, hogyha egy támadó valami hiba folytán .htaccess fájlt tud létrehozni a szerveren, azzal ne tudja a webszervert átkonfigurálni.
-
#16729
fordfairlane
veterán
#68216320
#16728
-
#15830
Tele von Zsinór
őstag
#68216320
#15824
Tele von Zsinór
őstag
válasz
#68216320
#15824
üzenetére
Igen, ezzel az is megbízhatóan megoldható. A feladat ennyi:
- kigyűjteni az összes képet (erre nagyon jó az xpath)
- végigmenni ezeken, és:
- csinálni egy linket úgy, hogy működjön vele a JS nézegető
- gyerekének berakni a képet
- majd a képet az eredetiben kicserélni a linkrekemkriszt98 a problémád az (volt), hogy az end() függvénynek nem változót adtál át - megcsinálja, de ha úgy van beállítva a hibajelzésed, akkor figyelmeztet, hogy nem jó.
Ez a függvény a paraméterében referenciát vár, mert módosítja a kapott változót, egészen konkrétan a tömb belső mutatóját átállítja az utolsó elemre majd visszaadja azt. Ennek az átállításnak nincs értelme akkor, ha nem változót adsz át, mint ahogy te tetted először. És ezért oldódott meg, amikor fordfairlane kolléga tanácsára hallgatva szedted szét a kódod.
-
#15157
trisztan94
őstag
#68216320
#15155
trisztan94
őstag
válasz
#68216320
#15155
üzenetére
Nem tudsz class-t adni a kepekhez? Onnantol kezdtve csak jQuery.attr() fuggvennyel tudod cserelni a href-et es .before-al es .after-el beszurni az a tag-eket.Ha nem tudsz osztalyt hasznalni, akkor meg egy tag selectorral is meg lehet ugyanezt csinalni.Jo, most esett le, hogy ez a PHP topik, es nem a weblap Keszites..
Es hogy PHP-val kell megoldani, ugy most hirtelen nincs otletem. -
#15145
csabyka666
veterán
#68216320
#15143
-
#15142
csabyka666
veterán
#68216320
#15141
-
#15069
Sk8erPeter
nagyúr
#68216320
#15065
Sk8erPeter
nagyúr
válasz
#68216320
#15065
üzenetére
"A DD-on látható kód ASCII kódokat csinál belőle?"
Igen. (Épp ezért csak ékezetmentes domainek esetén működik, mondjuk úgyis az a gyakoribb.)"Mert arra gondoltam, annál talán jobb, ha generálok egy tömböt a mail-ben használható karakterekkel és azokból rakom össze a címet. Esetleg lehetne, hogy mindig másképp keveri a karaktereket össze a tömbbe. Ez túlbonyolítás?"
A válasz megint csak igen. Jelen esetben nem sok értelme van korlátozgatni, hogy mik a használható karakterek: pontosan tudod előre, hogy milyen email-címet akarsz legenerálni, azoknak meg - ékezetmentes domaint feltételezve - pontosan tudod az ASCII-kódját. Akkor mi a gond?
ord() - Return ASCII value of character
Neked pontosan ez kell. Már ha úgy akarod, ahogy írtam egy lehetséges megoldást a nagyon sokból, hogy szerveroldalon ilyenformán előállítod az email-cím ASCII-karaktereit, aztán kliensoldalon (JavaScripttel) meg összerakod a rendes email-címet. Ennek a megoldásnak mondjuk annyi hátránya van, hogy a szerver- és kliensoldal megvalósítása email-cím generálása tekintetében függ egymástól, de hát na bumm, ez most belefér.
Mondjuk semmiképp sem a DynamicDrive-on látható ocsmány document.write-os megoldással kéne megcsinálnod, hanem úgy, hogy például adott osztállyal ellátott elemben végrehajtod ezt a konvertálást.De még csomóféleképpen meg lehet oldani, mint az előző hsz.-ben írtam.
-
#15062
Sk8erPeter
nagyúr
#68216320
#15061
Sk8erPeter
nagyúr
válasz
#68216320
#15061
üzenetére
Kiírathatod képként az e-mail-címet (persze ne generáld le a képet minden alkalommal nyilván). Kiírhatod a címet valami teljesen érthető, de mégsem komplett módon: peachman KUKAC dzsímél PONT com . Még azt is csinálhatod, hogy szerveroldalon picit obfuszkálod az e-mail-címet, aztán kliensoldali mutatvánnyal kalapálod össze újból. (Hasonló megközelítés lehet, ha összehozod szerveroldallal (bár nem pont ilyenre gondoltam, de teljesen mindegy): ez legenerál egy kliensoldali kódot az e-mail-cím kiíratására, mondjuk általában a dynamicdrive-on található kódok vagy elavultak, vagy undorítóak (itt se tudtak volna kitalálni jobbat a document.write helyett...), de az ötletet felhasználhatod.) Vagy akár Flash-sel kirakhatsz egy gombot, ami a cím vágólapra másolására szolgál. Neadjisten on-demand töltöd be a címet AJAX-szal... Meg ilyenek.
-
#15056
fordfairlane
veterán
#68216320
#15052
fordfairlane
veterán
válasz
#68216320
#15052
üzenetére
A Hozzaszolas osztály Blog-ja alatt kellene egy User objektum és ott az Image()-el megkapnom a profilkép útvonalát.
A Hozzaszolas objektum egyik attribútuma a User, a userId a User attribútuma. A Hozzaszolasnak, legalábbis ebben a kontextusban, nincs szüksége az userId-ra, jobb, ha nem is tud róla.
<?php
class User {
private $userId;
public function __construct($userId) {
$this->userId = $userId;
}
public function getImagePath() {
$userId = $this->userId;
// construct userimagePath
return $userImagePath; // ez megadná a User profilképének útvonalát
}
}
class Hozzaszolas {
private $user;
public function __construct($user) {
$this->user = $user;
}
public function getHTML() {
$userImagePath = $this->user->getImagePath();
return $html; // egy DIV-et adna vissza a hozzászóló profilképével, nevével, hozzászólás szövegével, stb.
}
}
$user = new User(1);
$hozzaszolas = new Hozzaszolas($user);
$app->response($hozzaszolas->getHTML()); -
#15054
Peter Kiss
őstag
#68216320
#15052
Peter Kiss
őstag
válasz
#68216320
#15052
üzenetére
Szóval pl. a Hozzaszolas class felelne azért, hogy letöltse valahonnan a hozzászólásokat, majd mindenből csináljon HTML kimenetet?
OO módon a Hozzaszolas osztály kb. semmit sem tud, van pár field-je gettere settere a nyilvánvaló adatokhoz, de fogalma sincs arról, hogy hol van tárolva, illetve hogyan kell megjelennie. Maximum képes fenntartani egy relációt a kapcsoló User-rel, bár ezt sem közvetlenül, hanem csak közvetetten, ORM cuccok megoldják ezeket, de nem jelenti azt, hogy neked is így kell.
Azt látom, hogy jelenleg van egy farönköd, és azt kérdezed, hogyan lesz ebből székelykapu, de odáig igen hosszú az út.
Valami kisebb feladattal kellene próbálkozni elsőnek.
-
Az űrlapon ellenőrzés, a külön php-ben megint ellenőrzés és adatbázisba íráshoz meg ugye mindig escape vagy prepare.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
A problémák elkerülésére új fájlnevet szokás adni pl. img.jpg?v=123
Új hozzászólás Aktív témák
Hirdetés
- Telefon felvásárlás!! Samsung Galaxy A70/Samsung Galaxy A71/Samsung Galaxy A72
- DDR3 BAZÁR! 8GB 16GB 1333MHz 1600MHz 2400MHz DDR3 memória garanciával hibátlan működéssel
- Lejárt a gyártói garancia? Mi tovább támogatjuk az IT infrádat!
- www.LicencAruhaz.hu OLCSÓ & LEGÁLIS SZOFTVEREK 0-24 KÉZBESÍTÉSSEL - Windows - Office - ÖRÖK GARANCIA
- Telefon felvásárlás!! Xiaomi Redmi Note 12, Xiaomi Redmi Note 12 Pro, Xiaomi Redmi Note 12 Pro+
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest