Mr Jekyll (en Hide) is idd even wennen. TLDR; Yaml configuratie icm DNS instelling bepalen de operationaliteit. Lees voor een eerste start: de soverin documentatie websites.
Hieronder een wat lang opgepend/losse-pols verhaal met hoe ik tegen de uiteindelijk werking aankijk en het bij mij inmiddels prima (doenbaar) werkt.
Ik heb ondertussen iets van 20 of 30 sites met daarin subsites die operationeel zijn. Om dat aantal web-iconen in mijn website-menu te kunnen aanklikken - die anders onbruikbaar buiten beeld gaan vallen - heb ik nog wat 'trucjes" uit moeten halen door de dynamisch opgebouwde html-streamcontent (css) daarvan te verbouwen zodat mijn webbrowser de âwebsiteâ iconen verticaal (ipv horizontaal) op mijn scherm zet en zo dan full-size kunnen worden aangeklikt.
Onderaan lijst ik een aantal links die handig kunnen zijn om meer te begrijpen van Jekyll en hoe Soverin het mij lijkt te doen e.d.
Voor vragen en overleg lijkt het mij handigste dit dan maar via dit topic te doen.
Ik ga even op een lange praatstoel zitten. Het âJe en jij en ikâ gebruik is willekeurig en niet om een ander te beleren maar met hoe ik tegen mijzelf aanpraat.
Je moet vooral bedenken hoe het in de achtergrond lijkt te werken zoals ik het ondertussen - na heel veel experimenten inmiddels begrijp en heb afgeleid. Afgezien dat er geen CGI (noch serversite) script mogelijk is, is en kun je veel meer dan ooit denkbaar was bij/met het platte xs4all.
Onze websites zelf, lijken uiteindelijk worden gegenereerd vanuit een dataset opgenomen in een database (dat dus geen server directory of folder) die op een zeker moment door een gebruiker wordt geplaatst of aangemaakt. Bv door vanuit het menu een nieuwe skeleton-website aan te maken of die als zip up te loaden.
Elke ânieuweâ dataset krijgt een obscure maar vaste uuid record naam zodat inhoud en editing van âwebsitesâ (ongeacht naam en toepassing) keurig, veilig en volstrekt anoniem van elkaar gescheiden blijtf.
Alleen jouw userid heeft editor-link naar jouw uuid-dataset naam. Erg veilig want puur vanuit database-data kan geen 1:1 link worden gelegd naar de gebruiker. Er is bv dus geen direct fysieke link tussen databaserecord en externe website, wat dan het cracken sws erg ingewikkeld maakt. Een oppervlakkig gehackte website wordt simpel as-is opnieuw aangemaakt vanuit de database.
De naam van een te genereren website voor een bepaalde (full) âhostnaamâ wordt ingesteld met een zg inhoudelijk Yaml configuratie bestand. Wanneer je dus meerdere databestanden hebt (ge-upload) met daarin dezelfde Yaml-configuratie of bv zonder of foute hostaanduiding, zal er maar ééntje van - als die al het doet - kunnen/gaan werken. Welke van die al dubbelingen en conflicten; is voor mij tot op heden een gok. Dus wat doe ik: iig geen fouten maken in yaml bestanden en een website stapje voor (terug)stapje opbouwen.
Jekyll website lijken van origine gebaseerd op scribo bedoeld om eenvoudige âclose-inâ BLOGâs mee te maken waarbij je wel html kunt gebruiken maar geen kennis hoeft te hebben om een prahctige website te maken. Jekyll kent tal van plugins waar Soverin er enkele w.o. MarkDown en Liquid van heeft geactiveerd om te kunnen gebruiken. Erg handig zodat iemand 1:1 bv de Github markdown coding kan blijven gebruiken.
Wat een groot gebrek is dat wij als gebruikers GEEN zicht hebben op de âfoutenâ in de achtergrond en of wat er op welk moment wanneer wordt uitgevoerd. Dit komt omdat het Jekyll mechanisme een centraal serverproces is (bij Soverin) die âgewoonâ periodiek scant of er nog ergens een website (dwz database record) is veranderd waarvoor dan een virtuele html-website - met een fqdn naam - moet worden aangemaakt in haar (Soverin) Caddy webserver. directory.
Ik vermoed overigens dat waneer je je website in web editor bewaard (of upload) er dan ergens een vinkje gaat lopen die op dat moment je website in de verwerking-queue zet om als html aangemaakt te laten worden.
NB: het is imo denkbaar dat dit de ene keer sneller gaat dan op drukkere server momenten, als er al geen time-out plaatsvindt.
Vervolgens lijkt het DNS gebeuren - met wat ik destilleer - als volgt te functioneren: voor elke DNS record dat verwijst naar het IP van de caddy server (van/op het Soverin datacenter 185.233.34.11 dus) wordt bij opvragen; kennelijk periodiek een scan gedaan of de website bestaat (dwz dus als HTML is aangemaakt via het Jekyll/Caddy service-proces).
De persoonlijke (fqdn) hostnaam die je dan instelt lijkt net als bij een Apache server met rewrites , dan verwijzen naar een virtuele folder waar de website (compleet en in structuur) staat opgeslagen.
Dan komen we op gebruiken van plaatjes waarbij je moet bedenken dat Jekyll maar een paar formaten lijkt toe te staan zoals GIF, JPG en PNG. Het uploaden van die plaatjes doe je dmv drag-ging vanuit je verkenner/file-explorer. Helaas gaat dat niert altijd gelijk goed, ook omdat je je muiscursor goed moet neerploppen op de gewenste "directory"in je scribo-webeditor. Het editen van een plaat gaat weer online en bestaat onderwater uit de painterro (?? (scribo plugin ??) .
Het gebruik van (CSV) tekstdatasets - er is geen MySQL o.i.d. - en referentie tabellen gaat op een vergelijkbare manier.
Waar ik nog niet helemaal uit ben, is of en op welk moment er voor een nieuwe website, een LetsEncrypt certificaat wordt aangevraagd. Met wat ik nu zie en kan vaststellen lijkt de hostnaam zelf (voorafgaand aan je domeinnaam) te bepalen (moet beginnen met wwâŠ) of Soverin/Freedom dan voor jouw FQDN een - aan te vragen LetsEncrypt - certificaat in je reuslterende webdirectory gaat plaatsen.
Lukt of is of kan dat niet, dan verwijst je website naar het default Soverin/Freedom certificaat dat (omdat het niet matcht met jouw eigen domein) dan âonveiligâ is.
Ik hoop dat dit verhaal iets meer duidelijk maakt, ook om er zo samen meer van te gaan begrijpen. Vanaf dag één hoop ik op een echte handleiding maar heb van/bij Soverin niet meer gevonden deze Help
Hier een aantal site refs die handig kunnen zijn om wat meer te weten over structuren (as-is):
- Mastering Jekyll
- kramdown syntax
- color schemes
- blockstructures
- site_portfolio
- jekyll-Jumpstart
- Jekyll-Yaml
NB: met al het boven staande niet primair denken als eindgebruiker maar meer als totale (Soverin) site beheerder die veel sites moet maken/hebben/beheren voor eindgebruikers. Eindgebruikers die - geen toegang hebben tot error-logs e.d. - dan maar zelf moeten ondervinden wat wel en niet lukt.
Hier laat ik het maar even bij want het is best een complex verhaal geworden. Ik hoop dat anderen er wat bloemkool-saus van kunnen maken. Ik sta wel open voor verdere inhoudelijke discussie omdat de website mogelijkheden een soort undiscovered (free) territory is waar onverwacht echt heel veel in -en mee mogelijk is.
Grtz en groentesap.