Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
Ez konkrétan egy WordPress-oldal. Elvileg pont azért szeretik, mert átlagfelhasználó is viszonylag gyorsan össze tud dobni benne egész jól kinéző honlapot (megfelelő "sminkkel"), kódolás nélkül. Szóval próbáld ki vagy ezt, vagy másik CMS-t, és saját magadnak össze fogsz tudni állítani különösebb bonyodalom nélkül rövid idő alatt is egy egyszerűbb honlapot.
Az általad linkelt oldal is igazából csak kihasználja a CMS adottságait, a hozzá készített pluginek telepítése után, egy CMS-ben ilyet összekattintgatni egyáltalán nem nagy művészet. Nyilván utána kell olvasni, melyik plugint tudnád felhasználni ilyen célokra, de gugli, hivatalos oldal tanulmányozása, meg esetleg egy témában érintett fórum (utóbbi legyen az utsó mentsvár alapos keresgélés után) segítségével biztos elég gyorsan meg fogod kapni a válaszokat. A lényeg, hogy kódolás nélkül is meg lehet oldani. Komolyabb dolgokhoz már el kell kezdeni szorgalmasan tanulni a különböző webfejlesztési nyelveket.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Dagaddt #8578 üzenetére
Ez nem jó.
1.) Ne Notepadet használj ilyen célokra, azt felejtsd el. Kezdetnek például ez nagyon jó:
http://notepad-plus-plus.org/
2.) Nem sima "UTF-8" kell neked, hanem "UTF-8 without BOM",
Notepad++-ban például a "Convert to UTF-8 without BOM" menüponttal tudod átkonvertálni az ANSI-kódolású fájljaidat. Ne csak simán átkapcsolj az Encode in UTF-8 without BOM-ra, mert akkor nem konverzió történik, így az ékezetes és egyéb speciális karaktereid elcsesződnek.Mivel UTF-8-at használsz, mindenhol következetesen "UTF-8 without BOM" karakterkódolásúak legyenek a fájljaid!
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Dagaddt #8575 üzenetére
"Később a gyorsabb írás miatt lehet elhagyom a lezárókat."
Nem kell elhagyni a lezárókat a self-closing tageknél HTML5 esetén sem, mert NEM hiba.
Tehát ez pl. valid HTML5-ben is:<img src="valami.png" alt="Valami" title="Valami" />
A végén aláhúztam a lezáró perjelet. Bizonyos helyeken, ahol számíthat a szintaktika-kiemelés, a parse-olás miatt jobb a lezárót is kirakni, pl. jsFiddle-nél lezáratlan, hibás tagnek mutatja a szerkesztő. Most ez csak egy példa volt, de egyébként nyilván nem hiba, ha elhagyod a lezárót.
Ez valóban XHTML-es "örökség", de én jobb' szeretem így használni, számomra szebbé teszi a kódot, aztán mindenki azt csinál, amit akar.Sk8erPeter
-
Sk8erPeter
nagyúr
Szívesen, hát igen, ha csak hobbioldalnak indul, akkor teljesen jól megfelel egy ilyen CMS-sel kreált megoldás is. (Egyébként hozzátenném, CMS-t komolyabb célokra is lehet használni, bár erőforrás-igényesebb lesz, mintha valaki igényesen (!) megírja kézzel, esetleg framework segítségével. De ne hidd el, ha azt mondják, hogy a CMS kezdő dolog, mert az baromság, csak nem ismerik rendesen. )
Aztán később, ha úgy érzed, mégis érdekel, akkor beleláthatsz a mélyébe, de akkor már ne CMS kódjának az elemezgetésével kezdd kapásból, mert az túl komplex ahhoz, hogy ne menjen el 1 óra alatt a kedved az egésztől. A másik meg az, hogy bizonyos CMS-ek nem feltétlenül nevelnek jó kódolási módszereket az emberbe (khmmm...nemakarokneveketemlíteniJoomla...khmm ), így fenntartásokkal kell kezelni őket. De a lényeg, hogy nem kezdőnek való egy komplex rendszer kódja.
Akkor kezdd az elejétől.
Na, szóval próbálkozz valamelyikkel, aztán majd meglátod.Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #8605 üzenetére
Itt elolvashatsz mindenféle hasznos infót, nagyon jó oldal:
http://diveintohtml5.info/Sk8erPeter
-
Sk8erPeter
nagyúr
Teljesen egyetértek martonx véleményével.
Valami CMS-ről van szó, ahol adott jQuery-verzióhoz vagy kötve? Mert ott szokott ilyen gond lenni, hogy nem lehet csak úgy kicserélni a jQuery-verziót, mert előfordul, hogy az alaprendszer bizonyos elemeihez kötődő scriptek olyan kódokat tartalmaznak, amik valamilyen okból nem kompatibilisek az új jQuery-változatokkal. (Drupalnál a jQuery Update modul pl. arra szolgál, hogy lecserélje az adott jQuery-változatot a lehető legfrissebb, agyontesztelt változatra, így annál tutira nincsenek kompatibilitási gondok az adott verzióig.)Konkrétan mihez kellene egyébként? Melyik plugin az, amelyik régi változathoz van kötve? Vagy ilyesmiről van szó, amit előbb leírtam?
Megnéztem kíváncsiságból ezt a jQuery Vector Maps plugint, jópofa, működik még a jQuery 1.10.1 változatával is, úgyhogy gondolom nem ezzel van a gondod, pontosabban ezt szeretnéd lazán csatolt módon beépíteni valahogy a rendszerbe, csak ez elég rossz módszer, hogy duplázni akarod a jQuery-változatokat, hogy kétszer legyen betöltve.
Sk8erPeter
-
Sk8erPeter
nagyúr
"A függvényt ami a divbe belepakolja a dolgokat az előző térképnél nem a head-ban hívtam meg, hanem a body-ban, és lehet emiatt nem működött."
Teljesen mindegy, amíg:
1. pl. $(document).ready() event handlerrel intézed el
2. a script tag és a kódod az érintett elem után van: ekkor már a böngésző renderelte az elemet, így a kód akár a ready event handlertől függetlenül is bekerülhet.Tipikus hiba ezek elfelejtése szokott lenni.
"A tied kb ugyanaz, de volt hozzá teljes példa"
Mármint milyen "enyémről" van most szó? Ha a modulra gondolsz, ahhoz nem igazán kell példa, mivel annak annyi a dolga, hogy egy igen rövid kóddal lecseréli az aktuális jQuery- és jQuery UI-változatot egy agyontesztelt frissebbre... JavaScriptben programozni meg talán ne egy modul bemutatóoldalán akarják megtanítani az embereket... (De majd írd le, mire gondoltál, ha nem erre.)[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz spammer #8616 üzenetére
csak annyi megjegyzés, hogy nem csak WebKitre optimalizálunk (lásd -webkit prefix, de nincs -moz prefix)
pl. itt le lehet generáltatni könnyen: http://www.css3maker.com/Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #8631 üzenetére
Milyen jó lenne tudni, hogy mit és hogyan csinálsz, nem csak magunktól találgatni.
Amúgy a TinyMCE-nek és a CKEditornak is kifejezetten jó a dokumentációja.(#8628) PumpkinSeed :
Colorbox(#8630) PumpkinSeed :
jól belenyúltál a nem éppen kezdőknek való feladatba JavaScriptben, de hajrá...Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #8633 üzenetére
Teljesen mindegy, honnan érkezik az adat, a kérdésed tudtommal nem ezzel kapcsolatos volt, tehát épp arra gondoltam, ami érinti a kérdésedet, hogy hol és hogyan akarsz CSS-definíciókat megadni a TinyMCE textarea-jában lévő elemeknek, és hogy olvastad-e a dokumentáció vonatkozó részét...
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
SEO-szempontból nem jó nyelvenként akár aldomainekre bontani, egy oldalon belül érdemes nyelvenként, pl. /en, /de, stb.
Ezt olvasd el, pont ugyanerre kérdeztem rá direkt SEO-szempontból:
http://prohardver.hu/tema/kereso_optimalizalas_seo/hsz_336-337.htmlSk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #8643 üzenetére
Igen, pontosan ezért kérdeztem, mert ebből kiderült, hogy nem olvastad a dokumentáció vonatkozó részét.
Explicite meg kell adni a TinyMCE-nek, hogy melyik CSS-fájlt használja.
Kivéve az inline-szerkesztőnél, tudtommal ott az oldal CSS-ét használja. De nézd meg a doksiban.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #8649 üzenetére
"De ha Illuval kezdesz akkor PS-t nem nagyon fogsz használni, mert rájössz, hogy az Illu sokkal jobb."
Dobj be egy ilyen mondatot a Photoshop topicba, és nézd meg a reakciókat.
Egyébként az ilyen "sokkal jobb"-mondatok legtöbbször valahol sántítanak. Attól függ, milyen szempontból, milyen célra, és így tovább.Sk8erPeter
-
Sk8erPeter
nagyúr
Nem pontosan azt írja, hogy kis weblapokra jó igazán, hanem hogy maga a keresőoptimalizálás azért nem egy egyszerű és olcsó dolog (meg időigényes), nagy honlapoknál valszeg van elég oldalra mutató link, stb., amik kellenek a SEO-hoz (most itt kissé sok lenne leírni, meg én sem értek hozzá), kis oldalnál kevésbé lesz esély minden egyes aldomainre megszerezni pl. ugyanazt az értékelést Google-bácsitól.
Épp ezért a levont konzekvenciád ennek tükrében nem helyes, mert ha minden egyes országra külön-külön domaint regelsz (vagy külön aldomaineken szerepelteted), és mindegyiken alapvetően egyező, csak más nyelvű tartalmat szerepeltetsz, akkor azt a Google nem biztos, hogy díjazni fogja. Igazából pont ez volt a lényege annak, amit küldtem.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Milyen tekintetben különbözik az adatbázis? Egyébként a Google-t marhára nem érdekli az adatbázisod.
Az a lényeg, hogy az általa olvasható tartalom, az oldalad HTML-kimenete milyen minőségű, mennyire logikusan strukturált, szemantikailag korrekt-e a felépítése, blabla (ez inkább SEO-s téma), és ha a tartalmad adott esetben túl sokban hasonlít egy másik oldal tartalmára, akkor az akármilyen mértékű duplikációt nem értékeli pozitívan, hátrább kerülhetsz a találati listában. Nyilván hogy ez mennyire jön elő nálad, az csakis az oldalaidtól függ."Másrészt a SEO-ról annyit, hogy nekem van ingyenes joomla meg wordpress, és abban is ott van a keresőoptimalizáltság."
Ezzel még túl sokat nem mondtál. Attól még, mert valamelyik CMS-t használod, attól a Google keresőrobotja nem fog elélvezni örömében, bőven kell csiszolni ezeken is a jó végeredmény eléréséhez (az alapértelmezett megjelenés lehet, hogy nem rossz, de ez nem azt jelenti, hogy SEO-szempontból ne lehetne rengeteget javítani rajta).Ezek egyébként csak tanácsok, lehetséges válaszok a kérdésedre segítő szándékkal, nem muszáj ám megfogadni.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #8661 üzenetére
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz trisztan94 #8669 üzenetére
"Most viszont a megrendelő külön kérése volt, hogy a lehető legkevesebb js ill 0 szerveroldal legyen benne"
A megrendelőd önjelölt szakértő?
Olyasmit kér, aminek a tartalmából kiderül, hogy fogalma sincs, miről beszél, és/vagy hatalmas nagy tévedésekben él, szóval erről beszéld le. De előtte azért tudakold már meg, hogy mégis miért kér ilyen butaságot.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz trisztan94 #8673 üzenetére
"Ő ismeri a javascriptet, meg a weboldal készítés mesterségét, de lusta megcsinálni. Legalábbis ezt állítja.
[...]
Szerk: Továbbá ki lett kötve, hogy csak éz kizárólag HTML 4-ben készülhet az oldal, mert az már egy 10+ éves szabvány, az jól megy mindenütt."Remélem így érzed az icipici ellentmondást...
De hogy a lényegre térjek:
1. tök indokolatlan, hogy kihagyd az egysoros AJAX-os JavaScript-kódolást.
2. ha kihagyod a dologból az AJAX-ot, akkor semmibe sem kerül váltogatni id-k szerint JavaScripttel VAGY sima CSS3-mal (!) a divek megjelenítését, ha egyben az összes aloldal tartalmát egyszerre megjeleníted különböző divekben.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Hát Notepad++-ban az egész projekt összes fájlját megnyitni nagyon brutális overkill a feladatra, főleg, hogy a Notepad++ is el fog azért szüttyögni vele egy darabig, bármily gyors is (mivel syntax highlight, kódblokkok megjelenítése a kódban, stb. azért szintén időt vesz igénybe), szóval ez a lehető legrosszabb módja a fájlban való kereséseknek.
Amit mindenkinek ajánlok viszont könyvtárakban ÉS fájlokban (PDF- és Office-fájlokban is normálisan) való keresésre, több szálon, gyorsan:
Agent Ransack
Számomra már a nélkülözhetetlen asztali alkalmazások közé nőtte magát, annyira gyorsan lehet vele keresni (a Windows beépítettjénél, Total Commander beépítettjénél mindenképp ezerszer gyorsabb). Lehet vele reguláris kifejezések, dátum és egyebek alapján is szűrni (ezek nem is nagy újdonságok, inkább a gyorsasága az érdekes).Sk8erPeter
-
Sk8erPeter
nagyúr
Szívesen! Én is sokáig TC-hez ragaszkodtam, mert önmagában a keresője annak is nagyon jó, legalább ugyanennyire szűrhető, de sajnos lassú, aztán megtaláltam ezt, és nálam a hosszas keresésekre teljesen kiváltotta, és nagyon bevált. Nálam a progi 13,6 MB-ot foglal, szóval nem egy helyzabáló. Remélem, beválik neked is.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz martonx #8703 üzenetére
Ez nagy terhelésnél tényleg így van, szűk keresztmetszet lehet egy CMS túl nagy overheadje annak bizonyos esetekben felesleges komplexitása, számtalan plusz query-je miatt.
Mondom ezt annak ellenére, hogy önmagában közel sem tartom egy gyűlöletes szitokszónak a CMS-t, mint a fórumban sokan mások.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz martonx #8719 üzenetére
Hát ez a honlap tényleg undorítóra sikerült.
(#8714) Phvhun :
hát elég hosszú a listám, szerintem itt megölnének, ha elkezdenék róluk itt OFF-olni.
Annak viszont örülök, ha nálad is bevált a progi.===
(#8733) trisztan94 :
ez még a múltkori, jQuery topicban kitárgyalt para volt, hogy kicsit túl sok mindent behúztál, CSS-ekkel együtt?[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #8847 üzenetére
Nagyon jól használható jQuery plugin ilyen célokra: jQuery ScrollTo.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz trisztan94 #8859 üzenetére
Azért a leírásod egy picit félrevezető, mert ez alapján valaki azt hiheti, hogy csak pötyögi a dolgokat Notepadbe, aztán abból tök jól működő oldala lesz, pedig a Markdownhoz nyilvánvalóan szükség van egy konverterre, ami aztán legenerálja belőle a kész kódot. De a Markdown nem egy nagy újdonság, Stack Overflow-n is ezt használod, amikor megírod a kérdést, és ez az oldal pedig ASP.NET-ben készül(t), és a Markdownsharpot használják ([link]). Igazából sztem az az érdekes, hogy számodra mitől jobb ezt a Jekyllt használni, mint valamelyest a megszokott környezetedhez igazodva használni egy alternatív eszközt.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz trisztan94 #8863 üzenetére
Jaja, eddig is érthető volt. Csak kérdés, a statikusnak kikiáltott oldal hosszú távon is statikus marad-e, nem fog-e a megrendelő még ezt, meg azt kérni, és legyen már admin-felület is, amiből aztán az derül ki, hogy jobb lett volna a megszokott szerveroldali kódolás, annak kiegészítése hasznos toolokkal, de elfogadom, ha teljesen biztos vagy benne, hogy nem változik a dolog, akkor talán hasznos lehet.
A SASS/SCSS-ből történő statikus CSS-generálás is hasonlóan működik egyébként.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz trisztan94 #8865 üzenetére
"Ha esetleg kell neki admin felulet v barmi mas szerveroldal az sem gond, mert a generalt oldal az full sima html ergo ha beleraksz egy php szkriptet ugyanugy mukodik minden."
Itt van egy logikai buktató, mert amint admin-felületet raksz az egész fölé, máris szükséged van szerveroldali kódra, amivel feldolgozod a felhasználó által távolról szerkesztett szöveget, majd azt feltöltöd adatbázisba, és onnan is olvasod ki (nem pedig a lokálisan megszerkesztett fájlokat töltögeted fel FTP-n, és aztán olvasod be azokat (most ugye nem VPN-ről beszélünk, hanem egy osztott tárhelyes megoldásról)), így a szóbanforgó Jekyll máris teljesen kiesik a képből. Így jutottunk el oda, hogy jobb lett volna eleve szerveroldali kóddal (most mindegy, mi az), a megszokott környezetedben összehozni az oldalt (ha olcsó osztott tárhely kell, akkor nyilván PHP, hiszen melyik olcsó osztott tárhelynél nincs manapság PHP telepítve? PHP-ben is van ugyebár Markdown-feldolgozásra támogatás), aminek a tartalma akár Markdownnal, akár hagyományos WYSIWYG-felületen szerkeszthető, az már a másodlagos rész (bár a Markdown sokkal tisztább kódot eredményez).Persze nem elvenni akarom a kedvedet, mert tök jó lelkesedni, csak nehogy aztán legörbült szájjal jöjj rá, hogy na basszus, ha már elkezdenek igényei is lenni a megrendelőnek (mert ő is tanul ám a fejlesztés során, és rájön, hogy amire az elején nagy hévvel mondta, hogy "ááá, ugyaaan, csak egy-két statikus oldalról lenne szóóó", az minden, csak nem statikus a végére), akkor bizony nem elég erre támaszkodni.
Amúgy is, miért jó eleve tényleg totál statikus, külön szerkesztendő HTML-oldalakkal szívatnia magát az embernek, ha már megvan egy bejáratott környezete a neki megfelelő szerveroldali nyelvvel? Ha 2013-ban az egyébként jól megírt szerveroldali kód feltűnően lassú a statikus HTML-oldalakhoz képest a nem túl komoly elemeket tartalmazó oldalon, akkor a tárhellyel van gond, nem magával a szerveroldali kód iránti igénnyel.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Huh, ez így elég csúnyán hangzik, miért nem használsz eleve valami Bootstrap-alapú theme-et, és aztán csiszolgatod annak a megjelenését? Rákerestem, rengeteg van.
OK, semmi, ezek szerint azért, mert már széjjel van formázva az alapoldal, de a beillesztendő tartalomban a Bootstrapet milyen módon kívánod felhasználni? Valami a formázásban el fog csesződni, hacsak a konkrét részeket ki nem ollózod a Bootstrapből, elég sok szívás érződik ki a dologból.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Kicsit több, mint fél éve a STARTárhely.hu-nál nyertem egy ingyen domaint, azóta ez eForce.hu lett (szerintem a Newhostingból nőttek ki egyébként, de annál sokkal jobb), próbálgattam Drupallal, meg egyebekkel, igaz, nem túl intenzíven, de nekem egész jónak tűnik, nem volt gond a sebességével és elérhetőségével, na meg 1 GB tárhely.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz trisztan94 #8949 üzenetére
Az utolsó bekezdésre: van egy olyan érzésem, hogy tapasztalatból beszélsz. De sajnos ezeken mindenki átesik, aki vállal ilyesmit.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz trisztan94 #9002 üzenetére
"ja hogy CMS Nem nagyon néztem utána, azt hittem ez is egy framework."
Még mindig félreérted.
A Symfony, amiről a többiek beszélnek, az egy elég komplex PHP-s keretrendszer:
http://symfony.com/
Tele von Zsinór pont azt írta, hogy f-fel kell írni, nem ph-val, mert a Symphony az tök más, az valóban egy CMS: http://www.getsymphony.com/ (XSLT-alapokon).Ha érdekel, a Drupal 8 alapmotorja épp a Symfony keretrendszer lesz ([link]).
Elég nagy váltás a korábbiakról, bár amit kicsit sajnálok, hogy a visszafelé kompatibilitás miatt benne maradnak a procedurális örökségek, keveredve az új, full objektumorientált kóddal (igaz, már korábban is elég sok objektumorientált kód volt, szép lassan terjedt el az OOP a Drupalban a PHP 4-es időszaktól, cikk), pedig valamikor ki kellene herélni ezeket is, hogy ne legyen katyvasz a forráskódban.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #9004 üzenetére
Meglátjuk, milyen lesz. Ha az új szemléletben fejleszted a modulokat, akkor nem fog zavarni.
Azért nagy érvágás lenne a sok éve több változatra migrálgatott, igen komplex moduloknál a teljes törés, így egyszerűbbé teszik a váltást.
De egyelőre én sem tudok sokat róla, mostanság nem nagyon olvasgattam a kapcsolódó híreket, de az biztos, hogy egyelőre sokkal több a biztató jel, mint a "mínusz pont"... (Ennyi alapján ne ítélkezz. ) Pl. a Views modul már bekerült a 8-as core-ba (bár ez már szinte kötelező volt, annyira elengedhetetlen modullá érett), a többnyelvűséget még kifinomultabbá tették (tudtommal CMS-ek között ebben is a legerősebb), az entitások kapcsolatait, adatbázis-felépítését jóval logikusabbá és egységesebbé tették (lásd taxonómiánál és annak többnyelvűségénél voltak azért kavarodások), és még sok pozitív változás történt.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Tele von Zsinór #9005 üzenetére
Teljesen igazad van, így a pontos, köszi a korrekciót!
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz trisztan94 #9000 üzenetére
"Amúgy jó a sublime, html-re én is azt használom, de mégis visszatérek mindig a np++-hoz. Igaz,az auto zárójeleket szeressük, de npphez is vannak ugyanezek pluginek formájában, meg az valahogy "mature"-ebb, több mögötte a háttér, csak hát csúnyácska egy picit "
Szerintem semmivel sem szebb a Sublime Text.
A hosszabb távú kódolás során egyébként a Sublime Text jóval praktikusabb, mint a Notepad++. Lásd kódkiegészítések, szénné konfigurálható billentyűparancsok (legalábbis emlékeim szerint ebben is jóval többre képes, mint a NP++), apró feature-ök, amiket felfedezni nem két perc, de vannak róla oktató videók, sok hasznos kis dolog. Mondom ezt úgy, hogy még nem szoktam meg a Sublime-ot (ritkán használom, komolyabb kódolásra inkább tényleg NetBeans), és szeretem a Notepad++-t, de látom a másik előnyeit.Sk8erPeter
-
Sk8erPeter
nagyúr
Hát azt ne csináld, hogy kitörlöd a .htaccess-t, mert akkor az alapvető működését rontod el. Sőt, én azt javasolnám, másold le egy szűz WordPress .htaccess-fájlját, amibe még nem szerkesztgettél bele (gondolom így fordulhatott elő az IfModule blokk lezáratlansága), és használd fel azt. Csekkold, hogy biztosan feltöltődik-e, FTP-n átmegy-e egyáltalán, vannak degenerált szolgáltatók, akik tiltják a fájl használatát.
Tudsz mutatni egy sima phpinfo()-t a szolgáltató oldalán? Hátha abból kiderül valami.
Most hirtelen más nem ugrik be, hátha majd később, vagy másnak eszébe jut valami.Sk8erPeter
-
Sk8erPeter
nagyúr
php_value post_max_size 10M
php_value upload_max_filesize 20M
php_value max_execution_time 6000000
php_value memory_limit 128MEzeket a sorokat Te írtad be?
Lehetséges, hogy ennek átállítása nem engedélyezett a szerveren, és emiatt dob hibát. Most letöltöttem egy WordPress-t, és abban nem látom, hogy ilyeneket beleírna (igaz, legfrissebb WordPress, nem tudom, Te hányast használsz).
Szóval továbbra is azt javasolom, hogy rakd vissza az eredetit, és a fentihez hasonló sorokat kommentezd ki, ami azt jelenti, hogy eléteszel egy hashmarkot (#).Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz Speeedfire #9026 üzenetére
Pedig ez így működik, és a főverzió-váltások során történő nagyobb váltás sokkal előnyösebb az innovációk érdekében, mivel így nem kell minden téren ragaszkodni elavult szerkezetekhez, csak azért, hogy szegény modulfejlesztőknek ne legyen belőle problémája - épp erről szól lényegében a cikk, csak diplomatikusabban -, miközben ezek a lépések sokszor nagyon is indokoltak, szükségesek. (Pl. adatbázis-kezelés, entitások (ez fontos újítás volt annak idején a 7-esben, hogy konzisztenssé tegyék a szerkezeteket, és ezt még tovább fejlesztik a 8-asban), taxonomy, node-ok, és így tovább).
Amúgy az érvelésedet nem teljesen értem, nemrég még azért adtál nagy mínuszpontot a Drupalnak, mert nem történik radikális váltás a kódban, most pedig épp az ellenkezője verte ki a biztosítékot - most akkor melyik is zavar?
De egyébként sincs ebben semmi újdonság (tulajdonképpen nem tudom, miért lep meg, pedig használtál Drupalt ), a Drupal-főverziók eddig is így működtek, valamilyen szinten mindig megtörték a korábbi vonalat (szerencsére; ezekről mindig készül lista is, meg vannak migrálásra eszközök), erről beszélt Tele von Zsinór is.
Valamilyen szintű backward compatibility így is van, amiről meg én beszéltem korábban, mert a kódolási módszertant nem alakítják át radikálisan OOP-sre, az API-ban sok függvényhívás változatlan (vagy "csak" paramétersorrend változott, csökkent az átadandó paraméterek száma egyetlen $options asszociatív tömbbé, és hasonlók), és ezért maga a core forráskódja nem kicsit kutyulmány-feeling, és ez mondjuk zavaró is. Nekem a teljesen objektumorientált szemléletű modulfejlesztés személy szerint sokkal jobban tetszene, mint az, hogy egyszer procedurális kódot alkalmazok, egyszer pedig OOP-s kóddal játszom. Már a Views is ugye a core része, és annak a forráskódja korábban is elég jól megtestesítette az össze-vissza kódot, egyik helyen full OOP-s kód, másik helyen teljesen procedurális kód, aztán harmadik helyen a kettő furcsa keveréke... szeretem a Drupalt, de az ilyenek meglehetősen bénává teszik a kódot.Az adatok migrálására egyébként többnyire biztosítanak eszközöket, így túlélhető a váltás, csak utána kell olvasni, és megtanulni, mit kell az új verzióban másként csinálni. Még ha nehézkes is az átállás, az esetek többségében akkor is megéri, és idővel belátja az ember, mennyire jó, hogy éles váltások történtek a kódban (a 6-os ocsmány dolgai után nekem a 7-es Drupal például felüdülés volt, még ha így is tartalmaz csúnyaságokat - persze összességében messze felülmúlja például a Joomlát a kódja, már amennyit eddig a Joomlából láttam).
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #9028 üzenetére
Itt a kompatibilitási témára írtad, hogy "Viszont, akkor a drupalnak egy nagy mínusz pont.", meg itt, hogy "a visszafelé kompatibilitás így elég gáz szerintem. ", utána viszont már ezt írtad:
"Halad a technológia, de ha már valaki megírt egy plugint, akkor ne kelljen már átírnia. A legtöbb framework is kompatibilis visszafelé. Nem lenne szerencsés egy egész oldalt újraírni, mert frissebb lett a framework."
Szóval ebből nehéz eldönteni, most akkor tetszik-e neked a visszafelé kompatibilitás, vagy sem..."Ezt a tömbös módszert használják a frameworkök is, ami igaz valamivel lassabb lehet, mint direktve átadni a paramétereket viszont nem kell a sorrenddel bajlódni."
Igen, a lassúság meg kétlem, hogy problémás lenne, legalábbis rég jó, ha valakinek az a legnagyobb gondja, hogy ilyenekkel foglalkozzon, tipikusan ez cseppet sem jelent szűk keresztmetszetet, mert a különbség észrevehetetlen."A migrálás az egy dolog a felhasználók részére és szerintem alap, ha már ekkora ugrások vannak a kiadott rilízek között. Ellenben a fejlesztők lehet egy idő után ráunnak arra, hogy változnak a paraméterek és "alapjairól" kell átírni egy modult. Mondom ezt úgy, hogy nem fejlesztettem még drupal modult."
Sokszor megtörtént már egy-egy nagyobb mértékű változtatás, és eddig a népszerűség ezek után sem csökkent (vagy átalakult).
Mérlegelni kell, hogy melyik előnyösebb hosszú távon, ha éveken keresztül hurcolhatod a modulodat, vagy pedig ha kiküszöbölik a régóta idegesítő hiányosságokat, javítják a következetlenségeket, és egyértelműen az utóbbi jön ki győztesen. Például ha előbbit választották volna a fejlesztők, akkor még mindig nem léteznének a sokkal egységesebb, általánosabb és testreszabhatóbb fejlesztést lehetővé tévő entitások (amiknek így például a többnyelvűsítése is jóval egyszerűbbé és konzisztensebbé válik, amiben például vannak eltérések node-ok és taxonómiaelemek között még a 7-esben is).Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #9030 üzenetére
"Akkor én olvastam félre. Sry. Én a kompatibilitásra gondoltam. Nem tom mi van velem mostanában kezdek meggajdulni. "
Hát ez vagy a nyár, vagy a kor.
Amúgy őszintén szólva most még mindig nem tudom, végül is melyik is a gázos a szempontodból."Én lehet, hogy kaparnám a falat."
Attól függ. Ha jóval egyszerűbbé vagy logikusabbá tesznek bizonyos dolgokat, akkor az lehet, hogy ellensúlyozza az idegeskedésedet. De mondom, szokott lenni migrálási útmutató, hogy mire kell odafigyelni, meg a Drupalnak speciel szerintem a dokumentáció is az erőssége (nyilván egy-két kivételtől eltekintve).Sk8erPeter
Új hozzászólás Aktív témák
- A fociról könnyedén, egy baráti társaságban
- EAFC 24
- Kíváncsi az EU, milyen online védelmet adnak a pornóplatformok a kiskorúaknak
- Politika
- Kerékpárosok, bringások ide!
- Bemutatkozott a Galaxy Watch FE
- World of Tanks - MMO
- Autós topik
- Székesfehérvár és környéke adok-veszek-beszélgetek
- iPhone topik
- További aktív témák...