WordPress vs generatoare statice

  1. Folosesc maxim două, nu e problemă de env. Nu scriu de pe mobil, tabletă sau rabla bunicii, deci nu contează chestii dinastea de accesibilitate extremă.
    1. Nu este lucru mai fain :smiley:
  2. Știu, e groaznic. La mine durează mult: 4,3 minute (prea multe post-procesări - feed-urile au inline styles) cu vreo 60 de articole. Se poate mult mai bine (11 secunde cu toate cache-urile și fără treaba cu feed-urile) dar nu-mi pasă, scriu doar un articol pe lună și prefer build “curat”. Contează mai mult detalii dinastea de prezentare, gen: dacă pun niște cod, sa fie colorat frumos, corect și fără javascript, dacă editez un articol să nu se strice tot după ce am schimbat o listă (editoarele de html în browser ori îs pline de buguri, ori îs prea limitate), dacă fac o editare greșită sa am toată istoria etc etc
  3. GitHub pages care e moka? La ăla nu trebe ftp. Poți folosi orice vrei tu, îs doar niște fișiere html până la urmă.

Eu cred că aicea conținutul are o greutate mai mare. Să vezi cum sare lumea la comentat dacă scriu că ceva e o „mizerie” :stuck_out_tongue:

Iar offtopic :slight_smile:

@Sapioit

https://github.com/voxspace/tinambo

Mersi de ideea pentru criptarea fisierelor statice, am implementat-o adineauri si a fost mai usor decat mi-as fi inchipuit, folosind un cifru AES-256-CBC cu cheie pe 32biti. Ramane de implementat migrarea din no-encryption catre encryption, fisierele vechi trebuie encryptate si … no room for errors. Daca mai ai ceva sugestii, sunt all ears :slight_smile:

Tinambo e un sistem semi-static de blogging, single-file PHP OOP care salveaza posturi/pagini in fisiere JSON externe.

1 Like

N-ai pentru ce. Si eu am luat-o de-aici:


Si o am salvata pe CodePen, pentru orice eventualitate… si pentru a o avea gata de folosire, oricand am nevoie de ea.

Edit: @voxspace Poate ar merge un drag-and-drop pentru incarcarea imaginilor in posturi… prin metoda asta… eventual, poti salva imaginile intr-un vector, in json

Deasemenea, poate reusesti sa faci sa poti descarca atasamente (gen un .zip, sau .txt), folosindu-te de fisiere base64-encoded.

Bine, in acel caz ar fi, cred eu, mai eficient sa salvezi fisierele in propriul json. Poti, spre exemplu, salva fisiereul json al fiecarui fisier ca json1, json2, etc., iar acel numar de ordine sa fie folosit pentru a stii unde sunt fisierele folosite, in articol.

Spre exemplu, un {{{{download:1}}} ar afisa link de download pentru primul fisier, in timp ce {{{show:1}}} ar afisa primul fisier, fie el text, imagine, sau ce-o fi.

@sapioit m-am gandit si eu la fisiere media (in principal pentru downloaduri) si shortcodes (fara markdown/textile, necesita librarii separate), dar na, e un one man show :slight_smile: Incetul cu incetul.

Partea cu criptarea e nitel mai complexa decat un base64, care e user de “reversat”, dar zic eu ca a iesit ok.

@iamntz pot sa te rog sa splitui ultimele posturi intr-un topic separat? ceva WP versus the world, static versus dynamic websites, etc :slight_smile:

Sarumana!

Deasemenea, poti folosi markdown pentru text formating, in care sa adaugi propriul shortcode pentru fisier, gen $[numefisie](data:text/plain;base64,dGVzdA==) sa fie markdown-ul pentru download fisier, sau, pentru a include fisierele de downloadat, asa ceva:

Cuvinte, cuvinte;
$[](1)
Bla, bla, bla...
[1]:data:text/plain;base64,dGVzdA==

Iar scriptul tau ar salva acele [1] in .json1, [2] in .json2, etc. si le va incarca dupa ce se termina de incarcat site-ul, inainte de </body>, folosing

document.addEventListener("DOMContentLoaded",
   function(event) { /* Link to the files */ });

Iar pentru download ai folosi

document.getElementsByClassName("download").addEventListener("click",
   function(){ /* download the file */ });

Spre exemplu, imaginile de mai jos nu au link-uri, ci folosesc codul base64 pentru a le adauga in pagina. Poti face lafel cu logo-ul, iconitele si ce mai foloseste blogul, ca imagini.
Chrome Icon Firefox Icon

Markdown e un nono, din cauza ca necesita librarie externa pentru parsing ( nu are rost sa scriu propriul parser, urasc sa reinventez focul) si incerc sa mentin totul cat mai basic si mai streamlined.

Am notat sugestiile tale :slight_smile:

Eh, daca nu vrei sa scrii propriul parser si nici nu vrei sa folosesti o librarie externa, al carui cod il poti include in fisierul tau, n-ai decat sa renunti…
Poti, eventual, sa adaugi ca un modul, markdown. 2-3 fisiere, zic eu, nu este prea mult.

Daca viteza unui generator static este un factor esential, atunci va recomand sa incercati Hugo. Este, de departe, cel mai rapid static site generator pe care l-am incercat. L-am rulat acum pe unul din site-urile mele si un build a durat 1.6 secunde pentru 375 de posturi, 6 pagini de categorii si 618 pagini de tag.

Si mai e si al naibii de usor de instalat, pentru ca e doar un executabil. Ca si downside este scris in go, deci daca vrei sa faci o tema custom sau ceva mai serios, trebuie sa inveti putin template engine-ul din go si sa citesti destul de serios documentatia. Hugo are aproape 10k stars pe github si o comunitate destul de activa.

disclaimer: folosesc hugo si am facut o tema pentru el acu ceva timp.

5 Likes

:slight_smile: “If you want to have source code highlighting using the highlight shortcode, you need to install the Python-based Pygments program. The procedure is outlined on the Pygments home page”.

Îs curios ce viteză are cu aia.

Dap, asa e, dar doar daca vrei code highlighting server side, din punctul meu de vedere se poate foarte bine face asta client side. Practic, ca sa folosesti unul din shortcode-urile incluse ai nevoie de pygments, nu e necesar altfel. Mi se pare o problema minora, sincer. But to each his own.

1 Like

Pe mine mă cam seacă paginile cu cod și fără colorare corectă (nici pygments nu e perfect, dar e departe cel mai bun). Sigur, există și cealaltă extremă, gen Rob Pike: „Syntax highlighting is juvenile.” link

Ca sa nu deschid alt topic, voi ce credeti ca ar trebui sa aiba un generator stati pentru a putea fi la acelasi nivel cu un CMS gen Wordpress si Joomla.

Ma gandeam sa imi fac un blog… de la 0… care sa poata fi comparat cu Wordpress… #side-projects

Baga mare, nici nu e multa munca (vb serios), ia-o pe bucati, ia o foaie si trece functiile de baza, apoi imparte-l structural si ocupa-te de catre un bloc, chiar daca nu are sens per total (de ex, intai faci partea de administrare a paginilor, dar nu ai inca un front-end de vizualizare al paginilor). Cat ma tot agit eu sa fac lumea sa treaca dincolo de “as vrea sa fac cutare” si sa intre direct si cu capul inainte.

In ceea ce priveste intrebarea ta, nu te pot ajuta pentru ca ce am considerat eu necesar, am adaugat in Tinambo, deci … poti sa citesti README-ul eventual.

  • pagini
  • postari (eventual unificate)
  • media
  • comentarii
  • social media (lumea e moarta dupa asa ceva)
  • SECURITATE

Eventual Open Source sau mai mult (Public Domain). Daca ai intrebari, shoot, am extrem de mult timp liber in ultimul timp (cred ca se vede asta in modul meu de postare aici) :slight_smile:

LE: n-ai zis la ce limbaj te gandesti.

Din ce îmi dau seama, cred că faceti o confuzie într-un generator static și un sistem de caching.

Cerințele serverului unui site static înseamnă cam așa:

  1. servirea fișierelor statice (html, css, js, fonturi și imagini).

Atât.

Dacă sistemul tău nu face asta și are nevoie de mai mult de atât, sistemul tău NU e static.


Un site static are probleme specifice:

  • nu poți adăuga interactivitate decât cu un serviciu extern (injectat ori cu un iframe ori cu js);
  • nu poți adăuga o funcție de căutare (decât dacă te indexează google)

Securitatea unui site static nu reprezintă o problemă foarte mare; singurul lucru la care trebuie să fii atent este să nu dai acces altora la server și să nu incluzi js de pe alte site-uri…


Acestea fiind spuse, Tinambo nu este generator, este un mini-CMS (dar îmi place numele. Înseamnă ceva?)


Dacă tot ești aici, poate faci și un ciocan să fie comparat cu o minge sau o tastatură cu un monitor.

1 Like

Tinambo nu e inca static (nici nu scrie nicaieri asta) dar asta e scopul final. Long way to go there. Un sistem static 100% se comporta exact asa cum ai descris tu, si are mult mai multe dezavantaje, eu am optat pentru un sistem care va genera fisiere statice intr-un oarecare format, si le va regenera in functie de necesitati (implementarea unui sistem de comentarii statice ar fi intr-adevar un achievement) :slight_smile:

Un alt plan ar fi ca site-ul sa fie generat din fisierele json (maybe txt, poate doc, whatever) deja existente intr-un director Dropbox/OneDrive/GoogleDrive, de ex. Caz in care nu ar fi un sistem deloc static si ar ramane in stadiul actual.

Numele nu inseamna nimic, e ceva ales intr-un moment de inspiratie (sau era transpiratie, nu mai tin minte bine) maxima :slight_smile:

Nu-i turna omului plumb in cizme inca, lasa-l sa inceapa, e mult mai usor daca te opresti pe parcurs (dar vei invata lucruri noi) decat daca te opresti inainte sa incepi.

Nothing lasts forever (Hi5, Netscape, Nokia, Altavista, IBM, SUN!!!), daramite un CMS scris cu picioarele.

Ok, nu static, semi-static. Practic, un mini-CMS cu caching built-in

PHP. Si o sa incerc sa folosesc cat mai putin JS client-side.

Ideea e ca problema ar fi la adaugarea modulelor… fiinca nu am suficienta experienta cu MVC.

Asta vroiam eu sa fac. nu complet static, ci cu un pic de dinamicitate, dar partea cu acces restrans sa contina template-urile, json-urile cu articolele, comentariile, etc. iar la fiecare adaugare de articol sa se genereze un nou fisier din json si template, iar la schimbarea template-ului sa se re-genereze toate paginile (cu un cronjob, ori cu un process php care sa salveze progresul si sa (re)genereze fisierele statice).

Functia de cautare ar fi dinamica si paginarea ar fi regenerata la adaugarea fiecarui articol. Ori printr-un cronjob, ori prin fortarea userului sa stea pana se regenereaza paginile. Partea usoara ar fi la faptul ca trebuie sa generez un numar de pagini egal cu numarul elementelor/articolelor dintr-o pagina, fiindca pe restul doar le redenumesc.

Asta mi-a amintit ca se apropie examenele… :rolling_eyes: :frowning:

Attica!! Attica!!!

Tehnic … nu chiar. Sphinx are sistem de search, cu javascript. Indexurile sunt niște fișiere JSON. Exemplu: Search — Sphinx documentation

Sigur, Sphinx e sistem de documentație, nu e chiar pentru bloguri (deși unii îl folosesc ca și blog engine), dar se poate folosi aceeași tehnică.

Please activate JavaScript to enable the search functionality.

Nop. :slight_smile:

LE: Si nu te gandi ca sunt eu irational, daca trebuie sa activez javascript ca sa accesez o baza de date pentru donare sange, sau o chestie cu adevarat importanta, da, dar “activeaza javascript ca sa facem faceswap intre aceasta pisica minunata si Donald Tump” … o sa cam spun pass :slight_smile:

1 Like

Nu uita că vorbim despre bloguri aici :slight_smile: