Kívánalom: Rewired 2.0

de az elképzelés jól hangzik, hajrá! :)

koszi! Mint latod az RW media beagyazason dolgoztam most a legtobbet es egesz kozel van a hasznalhatohoz es implementalhatohoz. Egyreszt ezert is kezdtem bejelenteni a projektet.

Velemenyem szerint a beagyazas fogja le az RW1.0-ban a legtobbet a rendszert es az miatt volt a legtobb gubanc. Miatta kellett kikapcsolni az automatizaciokat a hatterben, mivel kialakitasanal fogva a cache-ba generalta a tartalmakat, igy minden alkalommal ahogy idorol idore atnezte az oldalakat a Drupal es ujra generalta a cache-t, ujra is agyazta az osszes anyagot, ami miatt le is halt par eve teljesen a rendszer.

Akkor kapcsoltam ki minden hatter automatizaciot "ideiglenes" ragtapaszkent.

Most nincs cache ujrageneralas, de igy nincs kereses indexing sem, nincs idozitett hirkiteves, barmilyen tovabbi hatterfolyamat, es raadasul minden komment ugyanugy fog kinezni ahogy eloszor beagyaztak, hiaba cserelek valami frisset a kodban (ha csak nem szerkesztik ujra oket).

Viszont a friss beagyazas motorral ezeket a gubancokat mind helyre fogjuk hozni.

Sajna se a Vue nem kenyerem

A Vue nem olyan csavaros amugy. Pont en is azert foglalkozok vele, illetve valasztottam szerszamul. A lenyege hogy custom HTML elemeket nevezel ki, aminek sajat viselkedest tudsz szanni. Pl vannak ugye a DIV, IMG, SPAN es hasonlo klasszikusan ismertek. Viszont kinevezhetsz RWMEDIA, RWMEDIA_IMAGE es hasonlo custom html elemeket, es a vue ezeket megtalalja es custom javascript kodot futtat bennunk a kedvedre.

Plusz ezek a custom elemek pofonegyszeruen reaktivak is lesznek, azaz ahogy valtoznak az javascriptes valtozok ertekei, ugy fognak a kimutatott elemek is, mint mondtam hasonloan React es Angular tesokhoz.

A pontos mukodese nyilvan 2 mondatnal tobbet igenyel megerteni, de mondom az egesz elkepzesel nem tul ordongos. En vagy 1-2 nap alatt levagtam hogyan muxik es hasznalhato tipikus helyzetekben.

se a PHP

A PHP-ben amugy minden "associative array" alapu tipikusan. Azaz van egy valtozod, es azokban tarolod az adataidat, majd kuldozgeted azokat a funkciokon keresztul:

$var = [
'key1' => 'value1',
'key2' => 'value2,
];

Bazi jo elonyuk hogy pofonegyszeruen konvertalhatoak JSON-ba, es JSON-bol associative array-ba, mivel gyakorlatilag megegyezik a strukturajuk.

Azonfelul tipikusan funkciokat fogsz hasznalni objektumok helyett, mert eredetileg a nyelv nem tamogatja az objektumokat, csak joval kesobb adtak hozza, igy a legtobb helyzetben C alapu funciokat fogsz hivni benne a klasszikusan felmerulo szituknal, pl:

if (someString.length > 0) {
}

vagy

if (someArray.length > 0) {
}

helyett ezt kell tenned:

if (strlen(someString) > 0) {
}

vagy

if (count(someArray) > 0) {
}

Amugy mivel allandoan csomo nyelv kozott mozgolodok fullstack programozo letemre, probalok egyseges es konnyen ertheto modszereket hasznalni hogy konnyen at tudjak libbenni ide oda (meg ha honapokat is toltok egy adottban), es nem vadulni agyon minent nyelv-specifikus cuccokkal. Ha meg lehet valamit egyszeruen es atlathatoan oldani, de tobb koddal, akkor azt fogom valasztani, minthogy sporoljak a kodsorokkal es "frappans" nyelv-specifikus megoldasokkal farasszam az embereket, es a jovo onmagamat, amikor visszaterek ujra fejleszteni az adottat.

De én egyébként elégedett vagyok a mostani állapottal is.

fair enough, de a mostani allapotot vizualisan igy kepzeld el:
rwurl=https://i.imgflip.com/37si7j.png

Stabilnak stabil, csak epp az isten (rakat osszehackeles) tartja benne a lelket hogy ne omoljon ossze. :D Nem tudom azt se mi fog tortenni vele ha pl egyszer kenyszerulunk ujrageneralni a cache-t, mert megtelik a maximalis kapacitasa, nem e doglik be. :D

Ezeket kell kivesezni hogy sokkal konnyebb lehessen a kulonbozo reszeivel foglalkozni ha javitani vagy fejleszteni kell. Kulon kulon sajat modulokkal lefejlesztve a funkciohalmazokra, viszont ki-be tudjuk pofonegyszeruen majd a kulonbozo reszeit kapcsolni, ugyanugy tesztelni is egymastol fuggetlenul. Annelkul hogy stresszelnenk azon hogy mit fog betorni epp a lepes.

Masik fo ok, hogy a Drupal 7 end of life a kovetkezo evben lejar, es akkor meg leszunk szivatva ha friss security flaw-ot talal valaki kesobb. Az elokeszuletekkel (es a third party modulok lefaragasaval, kivesezesevel) nem feltetlen leszunk kotve azokhoz, se azokon keresztul egy adott Drupal verziohoz, igy jovore 8-as ra, vagy mindjart a friss 9-re is tudnank ugrani.

Fejlesztokent nem ugy kell gondolkodnom hogy "most perpillanat" minden okes, hanem jovobetekintoen, hogy a kozeljovoben is igy lesz e minden, ugye.

2. Cikkírásnál egyszerűbb képfeltöltési módot. Valami belső tárhely legyen, vagy nem tudom, mintha imgur linkeket használnánk, csak jó lenne persze valami rw-s, mert ki tudja mikor törli az imgur. Mondjuk már én is rég írtam cikket :(

van kepekre szerveres hozzaferes cikkiroknak ket modszerrel is:
1) a WYSIWYG szovegszerkeszobe, automatikusan gyart lemeretezett belyegkepeket is, stb. es tetszolegesen szurhatoak kesobb be ahova az ember akarja.
2) maguknal a cikkeknel csak "képek->Új fájl hozzáadása" reszeknel pofonegyszeruen hozzadhat egyszerre tobb kepet is az ember lokalis geprol, es tavoli linkeket megadva is attolti lokalis szerora, majd be is agyazza automatikusan a cikkek ala. Ez az egyszerubb es ujabb modszer, ami mar megvan par eve.

1. Idézetnél illetve úgy zusammen lehessen enterezni. Azaz: ha szeretném szeparálni a bekezdéseket térközzel, akkor ezt megtehessem. Jelenleg idézetnél hiába ütök entert, minden össze van torlódva.
Az jó, hogy a motor nem engedi floodolni, csillió entert leütve giganagy trollkommentet létrehozni, de mondjuk engedhetne 1-3 enterig, úgymond térköz gyanánt.

reszletkerdes mar. Overall a felhasznaloknak bbcode-ozas helyett jo lenne WYSIWYG szovegszerkesztot adni, persze csak a kello limitalt funkciokkal. De ha marad is egyelore a bbcode, nekem a legidegesitobb problema vele hogy ha hosszabb szoveget irok, akkor nem latom a gombokat es fel-le kell allandoam scrollozgatnom. Mobilon ez kulonosen idegesito, mivel PC-n meg kivaltom a problemat keyboard shortcutokkal ugye.

- Atirtam az osszes modult objekt orientalt Class es Namespace alapura, a regi PHPs modszeres "globalis funkciok" hasznalata helyett, amikor meg nem leteztek ezek. Rigolyasabb kompatibilitas-ra torekves helyett (jelenleg az RW1.0 php 5.4.x-en fut) ugy dontottem inkabb izombol tortetunk elore a legfrissebb PHP verziokat hasznalni, valahol 7.3.x vagy megjobb 7.4.x megcelzottal. Csakis az a jovobemutato celszeru megoldas.

Igy eleve sokkal embersegesebbek es konnyen erthetoek a funkcio nevek, es nem kell vadulni veluk hosszusagban sem. Plusz sokkal konnyebb kezben tartani es figyelni a kodban, hogy mi mit hiv vagy hogy honnan. Szerintem nagyobb atirasokat nem nagyon fogok mar ezeknel a jovoben csinalni, egeszen egyben vannak es zsirul hasznalhatoak mar tapasztalataim szerint.

- Hozzatettem a tovabbi szukseges modulokat amelyek meg szuksegesek voltak a jelenleg osszes megirt RW2.0 kodjanak az RW1.0-ra valo hozzaragasztashoz. Es az elozoleg elkezdett monolitikusabbnak bizonyulo modulukbol kitoredeztem par kisebbeket (pl RWMediaBackend-bol az RWData, RWHttp, es RWThumbs kismodult), amelyek logiknak bizonyultak friss kulon modulkent fejleszteni mert altalanos funkcionalitasuak es mas is hasznukra valik a jovoben, mintsem specifikusak lennenek.

- A friss rewired kod valahol 7.2.x+ PHP verziot kovetel, de a jelenlegi szeronk osregi 5.4.x PHP alatt fut. A webreames rendszergazdaval mar emaileztem, es a napokba felhuzza a leheto legfrissebbre a DEV rewired csatornat tesztelni (fel)elesben. Ahogy olvasgatom az 5.x verziokhoz kepest a 7.x sebessege egysegekkel gyorsabb, plusz eleve a friss RW2.0 kodom sokkal atgondoltabb es ezerszer profibb mint a regi RW1.0-as, igy egyre jobb sebessegbeli ugrasokat kell tapasztaljunk majd a vegso beelezes utan.

- Legtobb kapcsolatos funkcionalitas ami gatolta a friss RWMedia beelesiteset, le van igy mar programozva, igy DEV csatornan teszteles utan hamarosan az igazi eles csatornara is felhuzhato lesz majd szerintem.