Jekyll site down- en uploaden lukt allebei niet

Ik heb eens een Jekyll sitje gebakken en wil dat uploaden met Drop a zip. Er komt dan netjes een zip-tegeltje bij maar op mijn domein zie ik niets veranderen.

Dus probeer ik maar eens wat er al stond te downloaden om te zien wat de opbouw van de zip moet zijn, maar dat leidt tot Er is iets fout gegaan, probeer nog eens neem contact op met de helpdesk en refereer aan 9027f87d als het probleem zich blijft voordoen.

Het is allemaal niet zo duidelijk, maar dat kan natuurlijk aan mij liggen. Weet iemand of ergens een fatsoenlijke beschrijving staat hoe je een verzipte Jekyll site kunt plaatsen? Of gewoon tips kan uiteraard ook :slight_smile:

TIA!

Ik heb het ook opgegeven met de zip.

Heb een bestaand profiel gebruikt en een default.html in _layouts map gezet.
De rest van de bestanden in de root.

Van Jekyll snap ik geen sikkepit.
Ik vind dit system knudde.

Op zich heb ik geen moeite met Jekyll, dat wijst zich wel uit. Maar hoe krijg je het goed op de homepage van je DN? Zijn er conventies (bv. de zip moet DN.zip heten)?

Als ik een zip wil downloaden of uploaden gebeurt er weinig.
Er komt langzaam een blauwe streep bovenaan de pagina.

Er staan 2 pictogrammen met een wereldbol waarvan er 1 blijkbaar actief is.(de linker)
Daarin heb ik de bestanden per stuk geüpload.
Na een tijdje had ik een zeer simpele website.
Ook downloaden van mijn werkstukje als zip lukt niet.

Als ik de help lees, moet je een profiel downloaden en aanpassen en weer uploaden.
Maar dat werkt niet.

Ook de traagheid van mijn.freedom werkt me op de zenuwen.
Waarom heeft de website alleen een A record en geen AAAA record?

Precies wat ik heb. Heeft iemand dit wel aan het lopen?

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. :yum:

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):

  1. Mastering Jekyll
  2. kramdown syntax
  3. color schemes
  4. blockstructures
  5. site_portfolio
  6. jekyll-Jumpstart
  7. 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.

1 like

@PtrO Dank je voor de uitgebreide toelichting, die gaat zeker nog van pas komen :slight_smile:

Wat ik voor mezelf voor me zie is iets als

  1. download de bestaande site (die met “Welcome to your site”)
  2. even kijken hoe de structuur eruit ziet. Bv. moet de de Jekyll source uploaden of alleen wat Jekyll genereert (_site/)
  3. mijn eigen content erin zetten, zippen en uploaden

Op het moment gaat zelfs de eerste stap al mis. Misschien staat de oplossing in een link die je postte, ik moet het snel eens allemaal doornemen.

Het is een (ik weet, te) lang verhaal :yum:, waar het meeste wel indirect (cryptisch ter memory) in is af te leiden.

Bedenk vooraf dat “onze"websites (functioneel) vooraleerst uitgaat van een CMS concept waar een tekstschrijver dan “content” als inhoud plaatst waarvoor via de (jekyll) techniek van Soverin dan automatisch een html website zal worden gegenereerd.
Veel mensen - html-n00bs - vinden dan Markdown (zie hier ons forum, wat ook markdown is) of een blog-raamwerk of één van de twee “create from” templates” (op het menu) makkelijker om mee te starten.

Voor mij (ons?) techneuten is dat in beginsel juist ingewikkelder omdat ik (wij?) gewend ben niet alleen de inhoud maar vooral ook de opmaak te willen beheersen.

Je vragen :dancingmarionana::

  1. Download site is het icoon klikken dan dan de hele editor/structuur structuur in een zip zet. Echter bij het uploaden, om te voorkomen dat je een duplicaat datasetfile krijgt, moet je dan de EERST de reeds bestaande file/titelnaam verwijderen.

    NB: wanneer de upload niet lijkt te lukken “lukt” zal die ergens inhoudelijk, een fout hebben gegeven. Het is dan raden wat dat kan zijn.)
  2. Je hoeft alleen jouw gewenste inhoud via de web-editor te typen/plaatsen waarbij dan je “content werkwijze” bepaalt of en in welke mate je het configuratie bestand daarvoor verder moet toespitsen.
    Je kan al een volledige inhoud maken door alleen het “index.md” bestand te hoeven vullen bv met je gewenste (markdown) tekst zoals een regel ‘hello, welcome to my first Freedom website’ .
    Daarin kan je trouwens ook naast markdown, ook html-tags gebruiken.
    Je kan ook ipv een index.html bestand toevoegen die dan operationeel wordt met daarin subdirectory verwijzingen naar bv een folder waar dan plaatjes komen te staan e.d.
  3. Maak een website aan, download die, verwijder die zekerheidshalve voordat je de veranderde versie gaat uploaden, bewerk de inhoud van de zip op je PC en upload die weer. Die upload veroorzaakt een nieuwe “editor-filereferentie” (andere uuid).
    Zorg er wel voor dat
    a) de yaml config de juiste FQDN bevat waarop die moet reageren en
    b) een herkenbare bestand/titelnaam geeft aan je website.
    Inhoud _config.yml
    
title: ww3.jouw.leesbare.filenaam
baseurl: /
host: hostnaam.jouwdomein.nl

NB: “baseurl: /” zorgt dat alles begint in de root van je editor folder.

Ik zou 'beginners' w.o. mijzelf aanraden (nog) NIET te werken met down- en (verleidelijk) upload dat vaak mij alleen maar voor problemen stelde. Hooguit te gebruiken wanneer je heel veel data/wijzingen hebt dat offline makkelijker is te doen. Het is ook imo handiger voor de (jouw webdatalink) web-editor een vaste browser-bookmark te maken om je website qua inhoud te veranderen. Die linkt je dan voortaan in één keer door wanneer je wat wil veranderen. (ipv langdradig via het Freedom_menu te komen op de plek waaronder jouw webdata in de database staat opgeslagen).

Suc6 en voor vragen, leuk om van gedachten te wisselen.

Deze regel ontbreekt bij mij.
hostnaam… wat moet ik daarvoor invullen?

tldr; Letterlijk die regel waarbij “hostnaam” iets is dat je voor/met DNS configuratie als CNAME-‘naam’-veld van jouwdomein.nl hebt ingesteld. Dus bv: “host: www.jouwdomein.nl”
PS: wel zorgen dat wanneer je meerdere webeditors hebt, daar overal fdqn yaml “host:” config is ingesteld.


Het is/wordt de fqdn naam waarmee jouw website extern wordt aangeroepen.
bv www.jouwdomein.nl of test123.jouwdomein of abc.def.jouwdomein.nl

Niet moeilijker denken dan het is en kan mij voorstellen dat mijn terminologie voor verbetering vatbaar is. Gelukkig zit ik niet in de RFC commissie.

Voor de ‘www’ , ‘test123’ en ‘abc.def’ heb je dan eerder in je DNS configuratie, een DNS/CNAME verwijzing gemaakt naar ‘@’ (als TLD verwijzend naar het IP adres van de freedom/soverin loadbalancer).
Zover ik weet mij lang geleden kan herinneren, is/was die voor ‘www’ met CNAME al standaard actief op ‘@’ of in te stellen met een A-record op bv 116.202.65.212
De werking naar dat loadbalancer IP adres kan je vooraf checken met ‘~$ ping hostnaam.jouwdomein.nl’

De yaml “host: hostnaam.jouwdomein.nl” configuratie zorgt onder water dat Soverin/Freedom op die naam dan een virtuele website in HTML gaat afleveren zoals was opgemaakt door jouw webeditor. Zit in die zooi ergens een fout, zal er niets te zien zijn en dus zg niets werken. Bij moeilijke sites zal je dan weer een stapje terug moeten doen, net zolang tot je ontdekt waarom er een fout zou zijn.
Moraal: begin eenvoudig (hello world) en bouw je website dan stap voor stap op totdat je ervaring krijgt om het groter (of offline) aan te pakken.

NB: standaard, zonder "host: ", kan de website-editor alleen actief worden op/voor het tld-fqdn: “http://jouwdomein.nl” . Wanneer je dan meerdere webeditors hebt (gemaakt), zonder die host:scheiding, gaan die elkaar conflicten geven met als resultaat dat er (n)iets werkt of lijt te werken.

Simpel gezegd hostnaam=subdomein ?

1 like

Naar mijn idee wel. Bij mij werkt het met de volgende _config.yml instelling:

# Site settings
title: mijndomein.nl
email: mail@mijndomein.nl
description: > # this means to ignore newlines until "baseurl:"
baseurl: / # the subpath of your site, e.g. /blog/
url: mijndomein.nl # the base hostname & protocol for your site

Zodra ik
host: www.mijndomein.nl
erbij zet, werkt alleen nog maar deze URL met www en alle andere *.mijndomein.nl geven dan een error 404.

Zowel met host: als met url: krijg ik een 404. Ik heb het nog niet werkend gekregen.

Mijn _config.yaml:

# Site settings
title: sunday.p45.nl
baseurl: /
url: sunday.p45.nl

# Build settings
markdown: kramdown

Mijn DNS-settings:

@ A 116.202.65.212
sunday.p45.nl CNAME @

Probeer eens:

# Site settings
title: sunday.p45.nl
baseurl: /
url: p45.nl
host: sunday.p45.nl

# Build settings
markdown: kramdown

_layouts/default.html
Is mijn start html pagina.

index.md Verwijst hierheen.

1 like

Haal dat (url) is maar weg en als gezegd, zet bij je andere websites de juiste host: waarop die site moet opereren. Is ook wat zinloos omdat functioneel gezien, Freedom/Soverin bepaalt of -en op welk hoofddomein jouw site werkt en waar zij fysiek de html bestanden dwz in welke root/subfolder van het filesystem gaat plaatsen.
Jij en ik hebben geen controle over de url/baseurl die je zelfs helemaal kunt weglaten.

Nee, nog steeds 404. En met de opmerking van PtrO weet ik ook nog steeds niet of die url: nou nodig is.

Ik heb een site op basis van een template gemaakt, mogelijk dat daar een faut in zit (daar zit dus al een index.html met een paar verwijzingen in). Als ik meer tijd heb eens van nul opbouwen.

Met een redirect werkt het op een nieuwe site (monday.p45.nl) wel, die redirect netjes naar soverin.

mijn langere verhaal van een paar minuten geleden, heb ik wat gekortwiekt en base/url lijkt - net getest - niet nodig.

Probleem is dat er vast wel ergens iets fout zal gaan maar dat wij als gebruikers dat zonder toegang tot errors/logs/systeem niet (kunnen) vaststellen. Ik zou zeggen delete en begin stapje voor stapje opnieuw.
Onthou ook dat na een save, er soms wat tijd kan zitten tussen dat wat actief zou moeten worden. De server respons voor genereren van websites, is tegewoordig trouwens wel beter geworden.

Heldere uitleg (nogmaals dank) en een hoop trial-and-error te gaan :slight_smile: maar helaas gaat het bij mij nog steeds bij stap 0 mis. Downloaden van de bestaande site mislukt, met een compleet blote browser (chromium, geen ublock, noscript of wat dan ook). Het request gaat netjes de deur uit maar blijft steken, pas na 5 minuten komt een 504 Gateway Time-out van de server terug.

De IDE werkt wel maar vind ik geen serieuze optie.

2 likes

Ik heb het maar eens bij de helpdesk ingeschoten, hier gaat volgens mij echt iets serverside mis.

1 like