Projekti-tiedostot

Projektikohtaisesti on mahdollista tallennella mukaan tiedostoja, joilla ei välttämättä ole mitään erityisempää käyttöä, vaan ne ovat vain olleet jonkinlaisena aineistona tai ehkä ne ovat tiedostoformaatissa, joita julkaisusovellus ei voi sijoittaa esim. kuvakatalogeihin. Kaikenlaiset tiedostot voi drag'n'dropata taulun "Files" päälle, jolloin ne tallentuvat osaksi projektin tiedostoja, jotka päätyvät mukaan myös varmuuskopioihin ja jotka myös luodaan uusiksi, jos projekti importoidaan mukaan project listing -näkymässä. Tablet-laitteilla tiedostojen lähettämiseen voi hyödyntää ruudun jakamista "split viewiä" käyttäen, jolloin oletettavasti on mahdollista raahata tiedostoja tiedostonhallinta-sovelluksesta.

Tiedostojen vierellä on Download-painike, jolla tiedoston saa tarvittaessa ladattua erikseen käyttöön. Jossain vaiheessa käyttöön tulee myös file preview -toiminto, jolla voi esim. vilkaista mitä zip-paketti sisältää. Muutamien tiedostotyyppien osalta on jo katseltavissa sen sisältöä File preview -paneelissa (mm. zip-pakatut tiedostot, kuvatiedostot ja tekstitiedostot).

CDN-tiedostot

Jos tarkoitus tiedoston säilömisen lisäksi on voida jakaa niitä muiden kanssa julkisesti, voi tiedostoja siirtää (jo käytössä olevaan) CDN-palveluun, joka tässä tapauksessa on Bunnyn CDN Storage. Sen verran erillistä vaivaa täytyy nähdä, että luo Bunnyn asetuksissa Storage Zonen ja sille apikeyn (laitetaan julkaisusovelluksen käyttäjäasetuksissa ulkoisten palveluiden asetuksiin). Kyseistä apikeytä on kahdenlaista, joista toinen on read-only ja toinen readwrite. Jälkimmäistä tarvitaan tiedostojen siirtoon erikseen asennettavaa FTP-sovellusta käyttäen.

Jotta CDN:n kautta saavutettavat tiedostot näkyisivät CDN Files -taulussa, on niiden sijaittava hakemistossa, joka alkaa "project_" ja jonka jälkeen on sen projektin id-numero, josta on kyse. Loppuosa hakemiston nimestä voi olla mitä vain. CDN Files -taulukossa listattuna niiden kanssa samalla rivillä on url-linkki, joka on kyseisen tiedoston julkinen osoite. Sitä voi käyttää miten haluaakaan huomioiden, että koska kyse on CDN-palvelun kautta jaettavista tiedostoista, tiedostojen lataaminen netin ja täten Bunnyn kautta on maksullista.

Tätä samaista CDN-tiedostosäilöä voi käyttää myös esim. audio- ja videotiedostojen soittamiseen antamalla niihin viittaava julkinen osoite tekstin editointi -näkymässä (Embeddables-välilehti, Attach embeddable ja avautuvasta modaali-ikkunasta "Video file" tai "Audio file"). Tuolloin ei tarvitse käyttää erityisesti nimettyä hakemistoa, mutta Bunnyn ohjeista on luettava, kuinka julkinen osoite muodostetaan.

Projektin importointi SFTP-sovelluksella (SSH File Transfer Protocol)

Koska projektien importointi suoraan selaimen kautta (project listing -näkymässä) on rajoitettu 500 MB:aan, tätä suurempikokoiset varmuuskopio-tiedostot on importointia varten siirrettävä ensin CDN Storagen "importableprojects"-hakemiston alahakemistoon (SFTP-sovelluksella), jonka täytyy olla täsmälleen sama kuin julkaisusovelluksessa käytetty käyttäjätunnus. Tämän siirtämisen jälkeen ne näkyvät "Importable projects"-taulukossa yhdessä varmuuskopiokohtaisten painikkeiden "copy from CDN storage" ja "import" kanssa, joista ensin mainitulla varmuuskopio laitetaan siirtymään palvelimelle ja minkä jälkeen varsinainen importointi voidaan aloittaa. Siirto CDN Storagesta ei vie kuin lyhyen hetken, eikä importoinnissakaan kovin kauan kestä. Tällä tavoin importoinnista aiheutuu myös vähemmän muistin- ja CPU:n käyttöä palvelimella. Riippuen mitä rajoituksia Bunnyn asetuksissa on tehty, näitäkin tiedostoja voi jakaa julkisesti, mutta "importableprojects"-hakemiston sisältöä ei sentään voi listata julkisesti.

File preview -toimintoon lisäillään toisinaan uusia ominaisuuksia, joista erityisen hyödylliseltä vaikuttaa mahdollisuus kerätä PDF-tiedoston kaikilta sivuilta talteen kaikki ne tekstit, joiden vierellä on vapaamuotoisesti, PDF-lukuohjelmaa käyttäessä piirretty viiva. Näiden viivojen tarkoitus on ikään kuin merkitä, missä kohdin on jotain esim. käyttökelpoista. Merkinnän tyylillä ei ole liiaks rajoituksia, vaan se voi olla myös viiva, joka on muodostunut muutaman edestakaisin-liikkeen seurauksena. Se voi olla aivan tekstin vierellä tai sivun laidalla, sillä olennaista ovat sen ylä- ja alareunojen sijainnit. Satasivuinen PDF-tiedosto tulee käsitellyksi alle sekunnissa, minkä jälkeen käyttäjä saa käyttöönsä kerätyt tekstit ja jotka voi sitten ottaa jatkokäsittelyyn toisaalla.

Kirjoituksen muunnos asiakirjatiedostoksi

Niin sanottujen toimisto-ohjelmien käyttö voi jäädä vähämmälle, kun hyödyntää tämän julkaisusovelluksen tarjoamia mahdollisuuksia, sillä asiakirjoja voi luoda muutenkin kuin kyseisillä ohjelmilla. Avoimen lähdekoodin ohjelmistokomponentti Apache POI on se, mitä hyödynnetään Word-tiedoston koneelliseen generoimiseen julkaisusovelluksen kirjoituksessa olevien tietojen perusteella.

Kirjoituksella on optionaalisina teksti-osina Document header ja Document footer, joissa voi niiden placeholder-tiedossa annetun syntaksin mukaan antaa tietoa (osoite, asiakirjan tyypin nimi ja päiväys), jotka sijoitetaan sopiville paikoilleen ylä- ja alatunnisteisiin yhdessä sivunumeroinnin ym. kanssa. Näitä tietoja hyödynnetään ainoastaan writingsending-näkymässä. Asiakirjatiedosto luodaan yhdellä painikkeen painalluksella ja sen saa jatkokäytettäväksi ladattavana tiedostona.

Sähköpostin lähettäminen

Teoksessa olevien kirjoituksien eräänä ainoana käyttötarkoituksena voi olla sekin, että niitä käytetään sähköpostiviestin sisältönä, missä sähköpostin lähettäminen tapahtuu julkaisusovelluksessa itsessään. Tämä toimii sähköpostiviestittelyn alustuksena tai yhdensuuntaisesti viestiessä, sillä vastausviestit eivät päädy julkaisusovelluksen käyttöön.

Käyttäjäasetuksissa on ulkoisten palveluiden osalta kohta SMTP-palvelimen määritystä varten, johon tarvitaan SMTP-palvelin osoite ja sen käyttämän portin numero, sekä käyttäjätunnus ja salasana sille. Tässä ei käytetä viestinnän suojaamista muilta osin kuin SMTP-palvelimen portin mahdollistamalla tavalla. SMTP tulee sanoista Simple Mail Transfer Protocol ja se tarkoittaa lähtevän sähköpostin palvelinta. Tarvittavat tiedot ovat samat kuin erillistä sähköpostisovellusta konfiguroitaessa tarvittavat, mutta eivät välttämättä samat käyttäjätunnuksen ja salasanan osalta, jos haluaa luoda tätä varten erilliset sellaiset. Nämä sähköpostit lähetetään julkaisusovelluksen instanssin palvelimelta eli ei suoraan selaimesta.

Sähköpostien liitteiksi voi valita lisättävän kirjoituksen kuvista ne jotka ovat kirjoituksen tekstiin sijoiteltuja tai sitten kaikki kirjoitukseen liitetyt kuvat, sekä mitä tahansa projektiin liitetyistä tiedostoista. Projektin tiedostojen osalta tiedostokohtainen maksimikoko on 2,5 MB. Kuvista lähetetään isoin saatavilla oleva koko per kuva. Kirjoituksen teksti muunnetaan tyylittelemättömään muotoon, jotta sen voisi lähettää plaintekstinä.

Vastaanottajien listaa voi käyttää lähettämään yksi sähköpostiviesti monelle tai jokaiselle erikseen, missä sähköposti(t) lähtevät yhdellä painikkeen painalluksella. Useille vastaanottajille lähetettäessä, pilkku erottimena. Erillisten sähköpostien välille on asetettu hiukan lähetysviivettä (1 sekunti).

Tuotoksien ja teoksien exportointi

Valmistellessaan kirjoitusta kuvineen julkaistavaksi jossain toisaalla kuten keskustelufoorumilla tai Facebook-ryhmässä, voi kirjoituksen kuvineen exportoida zip-pakettiin, joka sisältää kirjoituksen kolmena eri versiona. Yksi näistä on tyylittelemätön HTML-versio, jossa on mukana tagit p, h1 ja h2 (listat muunnetaan tekstikappaleiksi). Kaksi muuta on plaintext-tyyppisiä sillä erolla toisistaan, että toisessa tekstikappaleiden jälkeen ei ole tyhjää riviä, mikä voi jomman kumman osalta sujuvoittaa työnkulkuja toisaalle copypastettaessa. Pictureshow-kuvien tiedostonimet nimetään siten, että on helpompi tunnistaa, mitkä sellaisista ovat samaan pictureshow'hun kuuluvia.

Asiakasta voi hyvinkin kiinnostaa kokeilla, minkälaisia käyttäjämääriä julkaisusovellus kestää ja tällainen ns. kuormitustestaus on hyväksyttävää, kunhan se ei jatku tuntikausia. Minuuttikin joidenkin teoksen kirjoitusten latailua automatisoidusti esim. jollain verkossa käytettävissä olevalla kuormitustestaus-sovelluksella riittää hyvän tuntuman saamiseen. Yhden palvelimen systeemissä pitäisi yhtä kirjoitusta pystyä latailemaan perusresursseilla esim. 8000 krt minuutissa vasteajalla 70 ms tjs. Ottaen huomioon, että esim. useimmat internetin blogikirjoitukset saavat vaikkapa vain muutama sataa lukukertaa kuukaudessa, pitäisi perusresurssien riittää "ihan hyvin" moniin tarkoituksiin. Julkisten teosten kuvat latautuvat aina CDN-palvelun kautta, jos CDN-palveluun on muistettu ladata käyttöaikaa.

Kirjoitus-sivuilla on käytössä lazy loading -tekniikka mm. kuville ja videoille eli vain ruudulla jo olevan osan ja siitä vielä 1000 pikselin etäisyydellä olevat ladataan näkyville. Myös ladattavien kuvien resoluutionvalinta on optimoitu sellaiseksi, ettei tarpeettomasti ladattaisi liian korkearesoluutioisia kuvia, mikä pätee sekä sivun ensilatauksella, että siinä yhteydessä, kun selainikkunan kokoa muutetaan. Runsaskuvaisilla sivuilla selainikkunan koon muuttaminen voisi herkästi aiheuttaa jopa tuhansia kuvanlatausyrityksiä, jos selainikkunan kokoa muutettaisiin keskeytyksettä esim. minuutin ajan, joten tällaisen varalta vain kuvien asettelu muuntuu selainikkunan koon mukaan ja kuvien resoluutioiden vaihtamisen tarve huomioidaan vain hetkittäin.

Eräs asiakkaan pikaisesti käytettävissä oleva keino vähentää julkaisusovellukseen kohdistuvaa kuormitusta on lisätä teoskohtaisia välimuistitusaikoja, joka on vakiona 5 sekuntia. Tämä välimuistitus tarkoittaa sitä, että esim. yhtä teoksen kirjoitusta ei generoida jokaisella sivulatauksella erikseen, vaan viimeisin generointi tallennetaan palvelimella tiedostoon, jota hyödynnetään esim. seuraavien viiden sekunnin ajan tai sen verran, mitä sen on säädetty olevan. Se voi olla kaksi tuntiakin. Kirjoituksen ja muiden teoksen osien generointi on aina palvelimen prosessoria kohtalaisen paljon kuormittava toimenpide ja ainahan on se mahdollisuus, että sivunlatauspyyntöjä tulee paljon kerralla. Generoidun teoksen osan tiedostosta lukeminen on tähän verrattuna erittäin vähän palvelimen resursseja kuormittavaa.

Palvelinlaitteiden ja ohjelmistojen kuormittumiseen liittyvät säädöt eivät tule täysin hyödynnetyiksi, jos sisääntulevat signaalit ensinnä vastaanottava Linux-palvelin on konfiguroitu outbound-kaistan osalta tiedonsiirtoa runsaasti rajoittavaksi. Tämä tehdään Linuxin tc-käskyllä (sanoista "traffic control") ja syynä sen käytölle voisi olla esim. oletettu uhka sille, että botteja olisi tahallaan ohjelmoitu kuluttamaa kuukausittaisen tiedonsiirron määrää siten, että ne latailevat pitkän ajanjakson aikana erittäin monia kertoja kohtalaisia määriä erilaista sisältöä kuten kuvia ja teosten sivuja. Sitä ei ehkä mielellään maksaisi useita satoja euroja ylimääräistä oletetun esim. kympin sijaan. Käytännössä helpoimmalla pääsee, kun varautuu maksamaan kolme kertaa oletettua enemmän pitämällä kaistaa vain hiukan rajoitettuna ja huomaa toivottavasti toistuvastai, ettei mitään pahaa tapahtunutkaan.

Normaalisti datakeskus-palveluiden tarjoaja Hetzner alkaisi laskuttamaan julkaisusovelluksen palvelimilta ulospäin suuntautuvasta datasta sen jälkeen, kun datan siirtomäärät ylittäisivät 20 TB. Tämä määrä eli 20 000 GB on runsaasti, jos kyse on vähäliikenteisestä julkaisusovelluksen instanssista. Varmuuden vuoksi julkaisusovelluksen palvelimiin tehdään asiakaskohtaisesti sellainen täydentävä rajoitus, mikä estää kuukausittaisten datansiirtomäärien nousemisen yli tuon 20 TB. Tämä tapahtuu rajoittamalla palvelimen virtuaalisen verkkokortin siirtonopeutta tasoon 60 mbps eli 7.5 MB/s (ks. laskelma: https://www.wolframalpha.com/input/?i=60Mbps+in+TB%2Fmonth). Määritetyn datansiirtorajan yli menevää osuutta kustannuksista nimitetään englanniksi "overage costs" ja palvelimelta ulospäin suuntautuvasta datasta käytetään joko nimitystä "egress data" tai "outbound data". Siitä voidaan sopia erikseen, josko tämä keinotekoinen rajoite poistettaisiin, mutta se vaatii samalla sopimaan datansiirtokustannuksista maksamisen käytännöistä. Jos datakeskus-palveluiden tarjoajana on jokin muu kuin Hetzner tai 20 TB ei muuten ole overage costs -maksun rajana, siitä mainitaan erikseen ennen palvelusopimuksen tekemistä.

Jos kävijämäärät lisääntyvät yht'äkkiä voi siitä aiheutua vaikeuksia päästä kirjautumaan käyttäjätunnuksella tai tehdä minkäänlaista esim. editoivaa, koska kuormituksen vuoksi kaikki olisi kovin hidasta. Kirjoituksen "Julkaisusovelluksen verkkotopologian muuttaminen" kuvat antanevat muutaman idean vaihtoehdoista verkkotopologian muuttamiseen sellaiseksi, että saavutettaisiin paremmin ulkoista kuormitusta. Muina palvelunlaatua parantavina keinoina ovat yksinkertaisesti vCPU:n lisääminen virtuaalipalvelimien tapauksessa (lisää prosessin käyttöaikaa yhteiskäytössä olevalle palvelinlaitteen prosessorille) ja vaihtaminen dedikoitujen palvelimien käyttöön. Näistä hiukan lisätietoja ohjeiston kirjoituksessa "Julkaisupalvelua käyttämään".

Palvelu on ositeltavissa hyvinkin monenlaisesti sellaisissa tarkoituksissa, missä käyttöaste merkittävästi lisääntyy tai ihan vaan halutaan erottaa esim. julkaisujen esilläpito ja sisällöntuotanto eri palvelimia kuormittavaksi.

Jos näistä kuvista on jotain luettavissa, niin vaikkapa sellaista, että verkkopalvelu voidaan siis ikään kuin lohkoa tai pilkkoa monella eri tavalla, jotta erilainen toiminnallisuus voidaan laittaa eri palvelinten tehtäväksi, jolloin esim. kuvien palveluun vienti (ja siinä samalla tapahtuva kuvien skaalaaminen useisiin eri kokoihin) ei kuormittaisi samaa palvelinta, jota käytetään valmiiden teosten näyttämiseen. Toimintavarmuutta voidaan lisätä moninkertaistamalla tiettyä toiminnallisuutta suorittavaa palvelinta ja antamalla kuormituksentasaus-komponentin päättää, mitä niistä milläkin ajanhetkellä hetkellisesti käytetään. Tietokantapalvelimet ja tiedostot voivat replikointi-tekniikalla varmistaa siten, että edes laiterikko ei keskeytä palvelun toimintaa, koska kaikki data ja tiedostot olisivat ennen laiterikkoa jatkuvasti vähintään kahdennettuja.

Muuta mainittavaa ovat esim. verkkotietojärjestelmä eli eri palvelimet voivat käyttää yhteisesti tiettyjä tiedostoja kuten käyttäjän kuvia; tietokannasta haetun tiedon välimuistituksen synkronointi palvelinten välillä. Näin siis tietenkin vain siinä tapauksessa, että käytetään enempää kuin yhtä palvelinta. Useamman palvelimen käyttö ei ole ollenkaan välttämätöntä eli kaikki tarvittava kuten tietokannanhallintajärjestelmä, kuvatiedostot ja sovelluspalvelin voivat sijaita sillä yhdellä ainoalla. Siihenhän voi sitten lisäillä resursseja kuten muistia, levytilaa ja aikasäikeitä prosessoriin (vCPU).

Palvelinlaitteiden ja ohjelmistojen kuormittumiseen liittyvät säädöt eivät tule täysin hyödynnetyiksi, jos sisääntulevat signaalit ensinnä vastaanottava Linux-palvelin on konfiguroitu outbound-kaistan osalta tiedonsiirtoa runsaasti rajoittavaksi. Perusteita tälle on mainittuna ohjeiston kirjoituksessa "Sananen datansiirtokustannuksien rajoittamisesta ja kävijäliikenteestä".

Kun kirjoituksia eri projekteissa on paljon, voi niiden sisällön muistaminen käydä haastavaksi esim. tilanteessa, jossa on tarkoitus viitata yhdessä kirjoituksessa moneen muuhun, jossa käsitellään kauttaaltaan jotain tiettyä aihetta, on sanottu jotain erityistä tai joka voisi antaa ideaa uuteen kirjoitukseen.

Kirjoituksien löydettävyyden tällainen helpottaminen ei välttämättä ole aina pelkästään hyväksi, sillä voi myös olla parempi oman ajattelun hallinnan kannalta, että esim. eri aikakausina kirjoitettuja asioita tai eri aikakausiin liittyviä asioita ei tällä tavoin liitä toisiinsa, sillä tällaiset esivalmistelut saattavat jäädä pitkäksi aikaa sellaiseksi, vaikkei niille sitten kenties mitään käyttöä olekaan.

Kuitenkin, johonkin tavoitteeseen nähden hyödyllisten kirjoitusten etsiminen voi olla vaativa tehtävä, ja täten joissakin skenaarioissa on hyödyllistä, että on esivalittuna kirjoituksia, joita saattaa haluta löytää nopeammin myöhemmin.

Kirjoituksien löydettävyys -ryhmissä ryhmien nimet on rajattu muutaman kymmeneen kirjainmerkkiin, ryhmissä itsellään voidessa ollessa useita luonnehdintatekstejä (descriptions), jotka voivat olla paljon pidempiä. Nämä luonnehdintatekstit ovat niitä, joiden on jollain perusteella tarkoitus luonnehtia esim. sitä, mitä niillä merkityistä kirjoituksista löytyy tai mitä mietteitä saattaisi juontua esille.

Haku-näkymä on eräs luontevan oloinen paikka näiden hyödynnettävyydelle, missä ryhmän nimen voi valita valikosta ja mikä sitten listaa siihen sisältyvät linkilliset luonnehdintatekstit, joiden käytön voinee arvata.

Mahdollisesti hyödyllistä käyttöä muodostetuille luonnehdintateksteillä saa aikaan "inspiration arrangements"-näkymässä, jossa toisena esivalmisteltuna ja paikoilleen aseteltavina elementteinä ovat adequates items. Tästä tarkemmin kyseisestä näkymästä kertovassa kirjoituksessa.

Luonnehdintatekstien tilalla voisi kuvitella voivan käyttää esim. yksittäisiä sanoja ja listailla niiden kokonaisien kirjoituksien nimien ohessa, mutta eikö siten jäisi varmuudella jotain merkittävää määrittämättä? Ja jos käyttäjällä on kirjoituksia esim. 600 kpl, olisiko niidenkään silmäily "toimivaa"?

Koko projektin kirjoituksineen, kuvineen ja muineen saa kietaistua zip-pakettiin yhdellä painikkeen painalluksella project managing -näkymässä ja tarvittaessa samaisen zip-paketin voi raahata project list -näkymässä projektilistan päälle, jolloin tuon zip-paketin sisällöstä generoidaan uusi projekti. Huomioitavaa tuolloin on, että siinä samalla generoidaan uusiksi myös kaikki projektin käytössä olevat kuvakatalogit eli uutta projektia ei yritetä yhdistellä palvelussa mahdollisesti jo olevien kuvakatalogien kanssa. Mahdollisuus sisällyttää yhteen varmuuskopioon useita projekteja on myös käytettävissä, jolloin varmuuskopio sisältää näiden projektien käyttämiä kuvakatalogeja vain kerran, mutta tuolloin voi olla syytä ottaa hiukan huomioon myös oletettua tai tiedettyä palvelinkuormitusta.

Tällä tavoin generoidut varmuuskopiot voi drag'n'dropata project list -näkymään kuten muutoinkin (kuvakatalogeja ei moninkertaistettaisi, vaikka useampikin projekti käyttäisi samoja sellaisia). Jos drag'n'drop -vaiheessa painaa Shift-painiketta ja kohdistaa siirron johonkin tiettyyn projektiin, ei tuolloin luoda uutta projektia, vaan varmuuskopiossa olevan projektin teokset sisällytetään kohteena olevan projektin osaksi (myös kuvakatalogit). Tästä on hyötyä esim. silloin, kun haluaa muodostaa yhden ison projektin teoksista, jotka ovat levittäytyneenä useaan muuhun projektiin.

Niitä levytilaresursseja, joita jokaisella asiakkaalla on käytössään, tulee käyttäneeksi myös käyttöjärjestelmä, jonka alaisuuteen kaikki muut oleelliset ohjelmistot ovat asennettuina ja käyttäjien säilömät kuvat ja projektitiedostot. Kuvista skaalataan upload-vaiheessa useita eri kokoja, joista suurinkokoiset vievät kuvaformaatista riippuen megatavun tai ehkä useammankin. Projektitiedostot ovat tiedostoja, joita käyttäjä voi tallentaa projektiin ja jotka päätyvät mukaan myös varmuuskopioihin. Varmuuskopiota tehdessä levytilaa tarvitaan myös zip-tiedoston luomista varten. Käyttöjärjestelmä varaa vakiona käyttöönsä n. 4 prosenttia levytilaa, jotta se voisi toimia myös silloin, kun käyttäjä on tullut käyttäneeksi käytettävissään olevan osuuden esim. 80 GB:n kokoisesta SSD-levyn osiosta. Julkaisusovelluksen käyttöönoton alkuvaiheilla siitä olisi käyttäjän käytettävissä n. 60 GB eli sen verran, ettei ihan heti ole loppumassa pelkästään kuvien säilömisen vuoksi.

Tarvittaessa asiakkaaksi ryhtynyt voi erikseen pyytää suurentamaan levytilan määrää, mihin on kaksi erilaista vaihtoehtoa, joissa molemmissa on yhteistä se, että levytilaa ei voida pienentää takaisin entisenlaiseen. Toisessa vaihtoehdossa levytilan määrää suurenee ottamalla käyttöön hintataulukon (Hetzner) mukaisesta tarjonnasta kalliimpi vaihtoehto, mihin voi sisältyä myös enemmän VCPU:tä ja RAM-muistia (esim. 160 GB levytilaa on alkuvuodesta 2026 ollut 15,67 eur/kk).

Toisessa vaihtoehdossa levytila järjestetään käyttöön sillä tavoin erikseen, että sen käytön voi aloittaa esim. 10 GB:stä ja suurentaa sitä tarvittaessa aina 10 teratavuun asti. Alkuvuodesta 2026 kyseisen "block storage volumen" hinta oli ensimmäisen 10 GB:n osalta 0,55 eur/kk, 100 GB:n maksaisi 5,52 eur/kk ja 10 TB 565,45 eur/kk.

Hinnoittelu "block storage volumella" on tuntipohjainen eli laskutus päättyy periaatteessa levytilan käytön lopettamiseen, mutta koska siinä voisi olla kuvia ym. silloin, kun sen käytön haluaa lopettaa, käyttäjän täytyy itse siirtää käyttäjän käyttöliittymässään kuvat ym. "peruslevylle" tai jos sillä ei ole tarpeeksi tilaa, poistaa ne. Julkaisusovelluksen käyttäjäasetuksista on moodi, joka laittaa eräisiin kohtiin tietoa siitä, millä levyllä kuvat ym. fyysisesti sijaitsevat, sekä toiminnot tiedostojen siirtämiseen levyltä toiselle. Ne on tehty luontevaksi käyttää eli käyttäjän ymmärrys siitä, mitä on tekemässä, pysyy hyvin yllä.

Lisälevyn käyttöön ottamisessa harkittiin sitä, josko käyttäisi Logical Volume Manageria (LVM), joka saa kaksi eri levyä näkymään käyttöjärjetelmää yhtenä, mutta se saattaisi pirstoa tiedostojen eri osat eri levyille, mikä tekisi vaikeaksi ottaa lisälevyä pois käytöstä myöhemmin. Täten, toteutus päätettiin tehdä toisin ja käytännössä lisälevy näkyykin käyttöjärjestelmälle kuin eri hakemistona ja mikä tekee samalla helpommaksi käyttää sitä verkkotopologialtaan sellaisessa ympäristössä, jossa julkaisusovelluksen eri komponentteja käytetään eri palvelimilla ja missä tarvitaan verkkotietojärjestelmän (NFS) käyttöä.

Vaikka kuvia olisi jo kirjoituksiin paikoilleen sijoitellutkin, ei se estä mitenkään sitä, etteikö kuvia voisi siirrellä kuvasäilöstä toiseen tai koko kuvasäilöä johonkin eri kuvakatalogiin, sillä kuviin viitataan id-koodilla, joka ei vaihdu kuvia täten siirrellessä. Näkymä sisältää kytkin-painikkeita kuvien ja kirjoitusten mahdollisten kohteiden vaihtamiseksi siten, että toisessa asennossa siirto mahdollista vain projektin ja projektiin liitettyjen kuvakatalogien rajoissa, mutta koska toisinaan halunnee siirtää muuannekin, on sekin tehty mahdolliseksi. Kirjoituksien osalta siirtämisen lisäksi voi myös kopioida.

Writing particular -kuvan valitseminen aiheuttaa hyödyllisesti sen, että avautuvan kuvasäilön kuvista merkataan siirtovalmiiksi ne kuvat, jotka on käytetty writing particulars -kuvina avatussa kirjoituksessa. Kuvien siirto toiseen kuvakatalogiin vaatii tässä näkymässä käyttämään väliaikaista kuvasäilöä ellei siirrä jo käytössä olevaa sellaisenaan. Vaihtoehtoisesti kuvia voi siirtää myös image assorting -näkymässä, missä ei tarvitse käyttää väliaikaisia kuvasäilöjä.

Jos tarkoitus on siirtää jotain projektiin, johon on vain editoivan käyttäjän oikeudet, tunnistaa nämä projektit niiden nimiin lisätystä "(side project)"-merkinnästä. Jos tavoitteena on siirtää jotain sivuprojektiin, silloin täytyy olla sen projektin moving things -näkymässä tai muuten kohdekatalogia ei ole näkyvillä. Sama pätee myös kirjoitusten kokoelmille. Siirron lähteinä olevien kirjoitusten kokoelmiakin on enemmän näkyvillä vain, jos ollaan sivuprojektin moving thing -näkymässä.

Muina keinoina erityisesti projektin sisällön kopiointiin ovat tekstin editointi -näkymässä käytössä olevat "overwrite writing"- ja copy/paste -toiminnot. Erilaista näppäryyttä kuvien siirtoon on tarjolla näkymässä "image assorting" (kirjoituksessa "Kuvien vapaamuotoista pläräämistä").

Riittämiin kirjoiteltuaan ja/tai oltuaan pitkään kirjoittelematta, voi kirjoituksien löytämiseksi haku-työkalulla tulla käyttöä. Silmäiltävyyden helpottamisen apuna hakusanan esiintymä merkitään korostuneesti sekä otsikoista, että leipäteksteistä. Hakusanan esiintymän ympäriltä näytetään hiukan tekstiä sitä edeltävältä ja seuraavalta osin. Hakutuloksissa näkyvät kirjoitukset linkittyvät ensisijaisesti tekstin editointi -näkymään. Jos kirjoitus on julkaistu, saatavilla on myös linkki siihen. Näitä linkkejä voi hyödyntää myös tehdessä redirectlink-kirjoituksia.

Kirjoituksien tekstistä hakiessa rajoitteena on toistaiseksi se, että haku kohdistuu kirjoituksen HTML-muotoiseen versioon eli esim. sanoissa olevat tyylittelyt voivat aiheuttaa sen, että jotain ei vaikuta löytyvän, vaikka sellainen tekstissä näyttäisikin olevan.

Tässä näkymässä tehtävän haun voi alustaa lisäämällä sivun osoitteeseen parametrin "seachquery" ja antamalla sille jonkin hakukriteerin. Jos hakukriteeri on "author:"-alkuinen, oletetaan, että sitä seuraava teksti viittaa authorid:hen. Näitä luodaan käyttäjäasetuksien kohdassa Authors, joka on kuitenkin vain kokeellinen ominaisuus. Haettavissa olevat writing finding groupsit luodaan ensin erillisessä näkymässä ja minkä jälkeen niitä valitsemalla saadaan listailtua esivalitut kirjoitukset projekti-riippumattomasti (vaatii kokeellisten ominaisuuksien moodin olemisen käytössä).

Kuvasäilöjen nimistä haettavuus saattaa käydä olemaan tarpeen siinä vaiheessa, kun kuvasäilöjä on jo useita kymmeniä. Adequateiden nimistä voi myös hakea, sekä erikseen myös niiden sisältämistä itemseista. Kirjoituksia voi etsiä myös kirjoitusten kokoelman id:llä (esim. writingcollectionid:2555). Writing finding group descriptioneille on kolme lisätoimintoa, joista kaksi mahdollistaa listaamaan liittyvät kirjoitukset joko näkymässä sliced text editing- tai näkymässä lots of text editing. Kolmas toiminto generoi tulostettavan verkkosivun kaikista liittyvistä kirjoituksista ja missä kuvadata on tuohon verkkosivuun upotettuna.

Joitakin toimintoja voi haluta tehtävän useille kirjoituksille kerrallaan kuten piilottaa niistä ei-tarvittavat kirjoituksen osat (esim. ingressi), vaihtaa oudonnäköiset lainausmerkit tavallisempiin tai tyylitellä kymmenittäin kirjoituksia samanlaisiksi. Yksitellen tällaisen tekeminen olisi melkoista kliksuttelua, mutta vähemmälläkin vaivalla siis pääsee. Muina hyötyinä mm. kaikkien teoksen kirjoituksien päiväyksien kerralla silmäiltävyys ja siinä samalla vaihdeltavuus. Kuvasta voisi arvata, että muutokset voivat kohdistua vain kirjoitusten kokoelmaan kerrallaan, mutta mainittakoon tässäkin kohdin, että pitämällä Ctrl-painiketta pohjassa sillä hetkellä, kun valitsee valikosta kirjoitusten kokoelmaa, listattavat kirjoitukset eivät korvaa edellistä listausta, vaan ne lisätään listaan mukaan. Taulukon otsakekentillä voi tehdä arvattavanlaista lajittelua.