Ik heb een zeer eenvoudige webpagina op mijn eigen domein staan welke je binnen Mijn Freedom kunt aanmaken. Nu wil ik de pagina iets aanpassen met o.a. een foto. Echter enige upload pogingen van de aangepaste webpagina lukken niet. Waarschijnlijk zit ik over een limiet met mijn bestandsgrootte. Weet iemand wat de maximale grootte van de website mag zijn?
Mij lukt het (ook) niet meer om plaatjes - ongeacht afmeting/type - up te loaden (met sleur en pleur), terwijl dat zeg twee maanden geleden nog fluitend ging, getuige mijn meer dan 15 (speel/sub)websites.
Tekst en Html bestanden dropān-drag gaat verder uit de kunst. Wanneer ik nu een jpg/gif/png/ico omhoog stuur, resulteert dat in een onwerkbaar bestand van 0-bytes.
NB: Mijn bestaande plaatjes die ik eerder had geplaatst, kan ik overigens prima bewerken.
Waarschuwing Update 30dec21 23u14: het bewerken veroorzaakt dat het plaatje 0-bytes wordt, dus bewerken lukt maar het bewaren maakt het daarna onwerkbaar. Dit vertelt mij dat er wat mis is in/met de (database) verwerking.
Heeft iig niets te maken met ruimte (dat deel is van het totale pakket van 25Gbyte). Ik kan ook zonder problemen meerdere platte tekstbestanden met extensie txt/html/csv van elk 2Mbyte omhoogsturen.
Ik begin te vermoeden dat het Scribo/CMS - dat de uploaddata inslikt - stuk is en niet (meer) overweg kan met andere inhoud/attributen dan die van platte tekst. Wanneer ik de bestandsextensie wijzig van .txt naar bv .tst ; wordt dat platte databestand ook niet ingeslikt.
Verder benieuwd of anderen het (nog) wel lukt om plaatjes up te loaden op de website (dat hier niet verward moet worden met de extra webhosting)
We zijn er hier naar aan het kijken. Er zijn wel meer dingen die niet helemaal lekker willen met de websites.
Oplostijd heb ik alleen niet.
1 like
Dat snap ik en nofiā¦ en wat moeten we/ik nu, daar verder mee of van verwachten ?
Het probleem is al vanaf de start en ik vermoed dat oliebollen poederen het verschil hier ook niet gaan maken. Wat moet er gebeuren (door/vanuit gebruikers) om dit aanhangig te maken bij Soverin ?
In de eerste versie van mijn pagina had ik ook een klein png bestand als favicon geĆ¼pload. Dat was ergens in april. Toen lukte het dus nog wel. En die png is ook nog steeds beschikbaar. Nieuwe plaatjes zijn bij mij inderdaad ook allemaal 0 byte. Ongeacht het bestandsformaat. Gelukkig ligt het dus niet aan mij 
. Is er op een andere wijze toegang tot de pagina mogelijk? Voor mij is het voldoende om bijvoorbeeld met sftp de bestanden te kunnen uploaden. Ik heb geen fancy web editor nodig. Dus, zoals PtrO zegt, wat kunnen we als gebruikers doen om in ieder geval een workaround te krijgen?
Dat SFTP zal nog best een lastig ding worden, ook omdat Soverin dat niet supporteert. Onze website-code staat bij mijn weten niet in een fysieke user-directory maar is als (meta)data opgeslagen in een (CMS) database. Op basis van de (gewijzigde) inhoud wordt dan (periodiek) bijbehorende website uitgespuugd die het publiek dan ziet. Dit merk ik/je ook op drukke tijden waarbij het soms even kan duren voordat een html-wijziging, daadwerkelijk zichtbaar wordt.
Ons/mijn/jouw werk met de online-webeditor is feitelijk bewerken van die database (website) en is dus niet zozeer een bestand van een filesystem.
NB: los daarvan kent inrichten van sftp tal van beheermatige uitdagingen, vooral omdat hufter/hack proof in te richten.
Wat Soverin hier conceptueel moet doen is zorgen dat de ābrakkeā backend onze data niet verziekt en dat dan als 0-byte opslaat. Van tijd tot tijd werkt het nadat er onderhoud is gedaan en kennelijk (naar wat ik observeer) allerlei (RubyRails plugins) scan-processesn opnieuw worden gestart.
Wat het hier moeilijk maakt dat Freedom (ws) alleen maar een ticket kan inschieten bij Soverin waarbij Freedom dan als (mis)vertalend tussenstation optreedt voor een fout die jij/ik constateren.
Het zou (mij) al schelen als Freedom ( bastiaan 
???) het probleem bij/met Soverin gaat aankaarten.
Zeker nu mij blijkt dat het issue structureel is en niets te maken heeft met het gebruik.
Ik heb ook net Ticket ingeschoten, zodat het ook in de helpdesklijn komt.
Hi PtrO, bedankt voor jouw uitleg over hoe dit (nu niet) werkt. Ik heb zojuist ook een ticket bij de helpdesk ingeschoten. Hopelijk wordt het probleem hierdoor met iets meer prioriteit opgelost. 
1 like
Het lijkt er op dat de boel een schopje heeft gehad van Freedom of Soverin.
Ik kan weer plaatjes draggen en droppen, die online editen en zo mijn websites bewerken.
Nog niets gehoord aan terugkoppeling, benieuwd naar het ticket omtrent reden.
Bedankt voor de trigger. Ik heb nog geen terugkoppeling om mijn ticket gekregen. Maar dankzij jouw trigger heb ik ook gekeken en gelukkig kon ik ook een zipfile met de website uploaden. Inclusief png en jpg bestanden.
Het ānadeelā van zip-website upload voor mij is, dat die een nieuwe CMS allocatie krijgt.
Het vervangt wel het resultaat maar niet fysiek de website die er eventueel al stond. In je website overzicht zie je dan een zoveelste icoon staan,. Welke daarvan actief is (en vanuit het CMS wordt gegenereerd), wordt bepaald door de _yaml file configuratie. Zelf regel ik met het āhost:ā statement op welke (dwz cname.domain.nl) er gereageerd moet worden.
maar oged, het lijkt er op dat binnen de kaders van het CMS,m alles nu prima werk. ik kan ook perfect mijn drop-drag plaatjes bewerken.
Tip: om niet telkens door alle menuās heen springen om de website-inhoud te editen, kan je - eenmaal in de juiste editor - een bookmark zetten. Een volgende keer, kom je zo in Ć©Ć©n keer (evt met inloggen) op/in de editor van de betreffende website. In los document - sterker een website - hou ik bij, welke website aan/op/met welke inhoud is gekoppeld.
Bv: https ://mijn.freedom.nl/sites/a1b2c3d4-1234-abcde-5678-e1f2g3h4j5k6/contents
de āa1b2c3d4-1234-abcde-5678-e1f2g3h4j5k6ā is de interne, geanonimiseerde locatie die dan een website op http ://cname.domein.nl doet.
BTW heel fijn is nu ook, dat onze websites nu ook bruikbaar en bereikbaar zijn met https://ā¦ (middels een geleverd Letās Encrypt) zodat we geen certificaatfouten meer hoeven te krijgen.
@Freedom : goed gedaan.
Bij mij ligt de Jekyll website er weer uit. Geldt dat voor meer gebruikers?
Doet het hier prima en kan ook editen die die (snel) actief worden.
Check even of je wel een werkende cname doorverwijzing gebruikt die uitkomt op ālb1.soverin.net.ā (let -op, voor DNS eindigt de domeinnaam op punt).
Je kunt ook IP adressen gebruiken - A-record voor je site in je DNS - die echter (in mijn ervaring) zomaar kunnen gaan wisselen en het dan niet doet.
Klop dat het SSL/TLS op de website idd nog een irritant dingetje is.
Een paar weken of wat geleden had ik in mijn beleving ineens wel certificaten op het website domein die nu weer foetsie zijn. Naar ik vermoed is men bezig e.e.a. om te zetten.
Ik wil je wel aanraden om iig een ticket in te schieten dat onze websites onveilig zijn ā¦ dat voor een privacy minded Freedom toch wel een beetje een hilarische schandvlek is.