# content
Olin aikoinaan kokeillut CDN:ää WordPresseissä. Tein sen CloudFrontin kautta AWS:n S3-buckettiin. Luovuin siitä, koska suomalaiselle sivustolle Suomessa Amazonin(kaan) CDN:stä ei ole yhtään mitään hyötyä. Mutta purku jäi pelkästään CDN:n mahdollistaman pluginin poistamiseen WordPressistä. Pelkästään siksi, että minulla oli podcastejä CDN-linkillä, enkä halunnut rikkoa niitä. Minun piti korjata ne, joskus.

Linkkien kuolema

Aikaa kului ja tyypilliseen tapaan unohdin mitä olin tehnyt ja miksi. Sitten siirryin DigitalOceanilta Hetznerin asiakkaaksi ja samalla kun siirsin DNS-tiedot, niin siivoin turhat merkinnät. Yksi niistä oli cdn.katiska.info. Samalla katkesi linkitys.

Meni aikansa, ennen kuin eräs käyttäjistä vinkkasi, että osa podcasteista ei toimi. Aika äkkiä löysin vian, palautin puuttuvan DNS:n — CloudFrontin asetuksiin en ollut puuttunut — ja olin hivenen ylpeä kätevyydestäni. Paitsi että linkit eivät lähteneetkään toimimaan.

Aikojen saatossa välillä silloin ja nykyään AWS oli muuttanut bucketien toimintaa ja minulla oli myös vaihtunut domain. Joten CORS esti osoitteen www.katiska.eu sivuilla käytettävän cdn.katiska.info audion toiminnan. Tuon selvittäminen kesti hieman pidempään, koska shellistä curlilla CDN-linkki tietenkin toimi.

Ahkeraa googlettelua ja nyt tiedän miten aws cli:llä muutetaan bucketin CORS ja mikä sen JSON-rakenne täytyy olla.

Aina haukutaan tekoälyjä, ja ihan syystäkin. Mutta minulla meni kolmisen tuntia selättää CORS-ongelma. Korjattuani ongelman testasin uteliaisuudesta Chat GPT:tä ja se antoi oikean vastauksen valmiilla cli-komennolla sekunnissa. Tuollaisissa asioissa AI on paikallaan. Siis että opin paremmin, kun etsin itse? Tulkintakysymys. En minä enää muista komentoa enkä JSON muotoa. Joten se siitä oppimisesta.

WordPressin linkkien löytäminen

Minulla oli selvät kuviot. Laitetaan aina näppärän WP CLI:n tekemään search&replace, etsi ja korvaa, väärille linkeille. Se miten saisin siirrettyä mp3-tiedostot Amazonilta Hetznerillä jäisi myöhemmäksi.

Ongelma oli siinä, että käyttämäni podcast-plugin Seriously Simple Podcast ei tallennakaan audioiden sijaintia tietokantaan omanaan. En löytänyt ensimmäistäkään audiolinkkiä WP CLI:llä enkä suoraan tietokannasta etsimällä. Osa ongelmaa oli varmaan sekin, että en käyttänyt podcasteille omaa kustom-artikkelityyppiä, vaan halusin niiden näkyvän artikkeleina muiden artikkelien kanssa samassa hakemistorakenteessa.

Penkomisen ja ihmettelyn jälkeen alkoi avautumaan, että linkkitieto varmaan laitetaankin muiden meta-tietojen joukkoon. Löytääkseni oikean avaimen tein tämän olemassa olevalle artikkeli-ID:lle:

❯ Näytä koodi

wp post meta list 149595 | grep -iE 'ss_|ssp_|castos|podcast|url'

Käytin grepissä useampaa, koska en tiennyt kirjoitusmuotoa.

Nyt audiot löytyivät. Ne olivat meta-tiedoissa avaimella audio_file

Tuon selvittämisessä meni oma aikansa ja samalla toinen aivopuolisko pohti tiedostojen siirtoa. Aloin muuttamaan suunnitelmaa. Ehkä kannattaisikin ensin siirtää tiedostot Hetzneriin ja sitten vaihtaa urlit. Enkä keksinyt siihen muuta tapaa kuin hyödyntää CSV:ksi tehtävää listaa.

Ehkä tässä välissä on syytä alleviivata, että minä en ole koodari enkä osaa ajatella kuin koodari.

Nyt jälkeenpäin ajatellen ehkä tekisin koko proseduurin toisella tavalla, mutta minä hypin ongelmasta toiseen eikä minulla ole osaamista miettiä asiaa kokonaisuutena. Varsinkin kun en useimmiten edes hahmota kokonaisuutta, vaan lähden ongelmasta A, enkä tiedä mihin kohtaan aakkosia päädyn, tai edes missä kirjaimistossa. Ja joka kerta, jopa ihan simppelien bash-komentojen kanssa, Google saa tehdä töitä. Ja sitten copy&pastetan ja ihmettelen miksi ei tapahdu sitä mitä haluan.

Siirto Hetznerille

Alkuperäinen suunnitelma oli simppelisti vaihtaa urlit muotoon cdn.katiska.eu ja pitää edelleen CloudFront mukana. Koska halusin irti Amazonista, useistakin syistä, niin suunnitelma muutti muotoaan. Siirränkin ensin tiedostot AWS:n S3:sta Hetznerin S3:een ja mietin linkkien korjaamista myöhemmin. Olin vakuuttunut siitä, että tuon saavuttamiseksi tarvitsen CSV-listauksen. Sen tein tällä:

❯ Näytä koodi

echo "id,title,audio_url" > podcast_audio_links.csvfor id in $(wp post list --post_type=post --post_status=publish --format=ids); do  url=$(wp post meta get "$id" audio_file 2>/dev/null)  if [ -n "$url" ] && echo "$url" | grep -qE 'cdn\.katiska\.info/kb/'; then    title=$(wp post get "$id" --field=post_title | sed 's/"/""/g')    echo "\"$id\",\"$title\",\"$url\"" | tee -a podcast_audio_links.csv  fidone

Jos joku yrittää adoptoida tekemäni asiat, niin yksi vinkki: tiedostojen otsikoista kannattaa editoida pilkut pois. Jatkon suhteen ylimääräiset pilkut tekevät hassuja asioita, kun CSV:tä käsitellään lisää. Eikä niitä otsikoita edes käytetä mihinkään. Ne ovat mukana vain ihmistä varten, että näkee mihin julkaisuun mikäkin tiedosto kuuluu.

Tuon prosessointi vienee aikaa. WP CLI on hidas ja luupeissa vielä hitaampi. Kärsivällisyys ja varsinkin tmux tai screen ovat ystäviäsi.

Hetznerin S3 on AWS:n klooni, joten aws cli toimii. Jos sinulla ei ole sitä, niin googleta asennus. Älä käytä aptia tai snapia. Molemmat antavat liian vanhan version.

Kun aws cli on asennettu, niin sille täytyy kertoa pari perustietoa, kuten region ja vaadittavat API-tiedot. Asetuksille on jokin config-komentokin, mutta koska mukaan tarvitaan myös Hetznerin API, niin käsin pääsee helpommalla.

Tee hakemisto ~/.aws. Sinne tulee kaksi tiedostoa, config ja credentials.

config

❯ Näytä koodi

[default]region = eu-west-1

Vaihda tilalle käyttämäsi. Jos tarvitset useamman regionin, niin googleta miten niitä käytetään. Minulla ei ole hajuakaan.

credentials

❯ Näytä koodi

[default]aws_access_key_id = <lyhyempi>aws_secret_access_key = <pidempi>[hetzner]aws_access_key_id = <lyhyempi>aws_secret_access_key = <pidempi>

Sitten on aika tehdä siirto. Allaoleva scripti on live-esimerkki, joten muuta tarvittavat.

CSV-FILE on edellä käytetyn CSV-tiedoston polku ja nimi; jos teet töita samassa hakemistossa, kuten WordPressin kotihakemistossa edellä käytettyjen WP CLI komentojen takia, niin polkua ei tarvita

HETZER_BUCKET taisi mennä väärin nimetyksi, näin jälkeenpäin ajatellen, tai en tunne termejä. Se on se hakemisto, joka on tehty bucketiin, jonka nimi näkyy endpointissa. Jos on tarve siirtää juureen, niin en tiedä miten se tehdään. Tai onko se edes mahdollista.

HETZNER_ENDPOINT löytyy bucketin tiedoista. Jostain oudosta UX-töpistä johtuen Hetzner antaa endpointin ilman bucketin nimeä. Joten sen, minulla podcastit, joutuu lisäämään itse. Kuten myös https://

HETZNER_PROFILE on se nimi, jonka annoit tiedostoon ~/.aws/credentials

❯ Näytä koodi

#!/bin/bash# AsetuksetCSV_FILE="podcast_audio_links.csv"TMPDIR="/tmp/podcast_tmp"HETZNER_BUCKET="s3://kaffepaussi"HETZNER_ENDPOINT="https://podcastit.hel1.your-objectstorage.com"HETZNER_PROFILE="hetzner"# Luo väliaikainen hakemisto jos puuttuumkdir -p "$TMPDIR"# Ohita CSV:n otsikkorivi ja käsittele rivittail -n +2 "$CSV_FILE" | while IFS=, read -r id title url; do    # Poista mahdolliset lainausmerkit    id=$(echo "$id" | tr -d '"')    title=$(echo "$title" | tr -d '"')    url=$(echo "$url" | tr -d '"')    filename=$(basename "$url")    echo "🔽 Ladataan: $filename"    curl -s -L -o "$TMPDIR/$filename" "$url"    if [[ -s "$TMPDIR/$filename" ]]; then        echo "🟢 Siirretään Hetzneriin: $filename"        aws s3 cp "$TMPDIR/$filename" "$HETZNER_BUCKET/$filename" \            --endpoint-url "$HETZNER_ENDPOINT" \            --profile "$HETZNER_PROFILE"    else        echo "❌ Lataus epäonnistui: $filename ($url)"    fidoneecho "✅ Kaikki valmista. Tiedostot löytyvät bucketista: $HETZNER_BUCKET"

WordPressin urlien korjaaminen

Viimeiseksi pääsin siihen, joka oli alussa työlistan ykkönen: WordPressin urlien korjaaminen ja korvaaminen.

Koska tiedostonimet pysyivät samana ja vain lähde muuttui, niin käytetään samaa CSV:tä ja korvataan vanha Hetznerin endpointilla.

❯ Näytä koodi

#!/bin/bash# AsetuksetCSV="podcast_audio_links.csv"ENDPOINT="https://podcastit.hel1.your-objectstorage.com/kaffepaussi"# Tarkista että CSV on olemassaif [[ ! -f "$CSV" ]]; then    echo "❌ CSV-tiedostoa '$CSV' ei löydy."    exit 1fi# Otsikon kauttatail -n +2 "$CSV" | while IFS=, read -r id oldurl; do    id=$(echo "$id" | tr -d '"')    oldurl=$(echo "$oldurl" | tr -d '"')        filename=$(basename "$oldurl")    newurl="$ENDPOINT/$filename"    echo "🔄 Päivitetään ID $id: $filename"    wp post meta update "$id" audio_file "$newurl"doneecho "✅ Kaikki meta-päivitykset tehty."

Se oli siinä. Nyt audioni on siirretty Amazonilta Hetznerin hoiviin ja podcast-julkaisuissa on uudet linkit.

Jos käytät Varnishia, niin tee ban() kaikille podcast-julkaisuille.

Tässä vaiheessa join kupin kahvia. Ja katsellessani linkkien ulkomuotoa tulin siihen tulokseen, että ne ovat suunnattoman rumia. Joten vaihdoin Nginxissä proxyn avulla Hetznerin endpointin muotoon podcast.katiska.eu ja päivitin vielä kerran urlit WordPressissä. Olisihan tuonkin voinut hoitaa kerralla kuntoon, mutta kuten sanottua — ei minulla ole suunnitelmaa, vaan etenen katastrofi kerrallaan.

Joten jos teet jotain samanlaista, niin laita ensin Nginxin proxy-ohjaukset kuntoon, siirrä sitten tiedostot Hetznerin endpointiin ja vaihda viimeiseksi WordPressin linkit osoittamaan proxyn käyttämään domainiin.

# contentMap.fi
Olin aikoinaan kokeillut CDN:ää WordPresseissä. Tein sen CloudFrontin kautta AWS:n S3-buckettiin. Luovuin siitä, koska suomalaiselle sivustolle Suomessa Amazonin(kaan) CDN:stä ei ole yhtään mitään hyötyä. Mutta purku jäi pelkästään CDN:n mahdollistaman pluginin poistamiseen WordPressistä. Pelkästään siksi, että minulla oli podcastejä CDN-linkillä, enkä halunnut rikkoa niitä. Minun piti korjata ne, joskus.

Linkkien kuolema

Aikaa kului ja tyypilliseen tapaan unohdin mitä olin tehnyt ja miksi. Sitten siirryin DigitalOceanilta Hetznerin asiakkaaksi ja samalla kun siirsin DNS-tiedot, niin siivoin turhat merkinnät. Yksi niistä oli cdn.katiska.info. Samalla katkesi linkitys.

Meni aikansa, ennen kuin eräs käyttäjistä vinkkasi, että osa podcasteista ei toimi. Aika äkkiä löysin vian, palautin puuttuvan DNS:n — CloudFrontin asetuksiin en ollut puuttunut — ja olin hivenen ylpeä kätevyydestäni. Paitsi että linkit eivät lähteneetkään toimimaan.

Aikojen saatossa välillä silloin ja nykyään AWS oli muuttanut bucketien toimintaa ja minulla oli myös vaihtunut domain. Joten CORS esti osoitteen www.katiska.eu sivuilla käytettävän cdn.katiska.info audion toiminnan. Tuon selvittäminen kesti hieman pidempään, koska shellistä curlilla CDN-linkki tietenkin toimi.

Ahkeraa googlettelua ja nyt tiedän miten aws cli:llä muutetaan bucketin CORS ja mikä sen JSON-rakenne täytyy olla.

Aina haukutaan tekoälyjä, ja ihan syystäkin. Mutta minulla meni kolmisen tuntia selättää CORS-ongelma. Korjattuani ongelman testasin uteliaisuudesta Chat GPT:tä ja se antoi oikean vastauksen valmiilla cli-komennolla sekunnissa. Tuollaisissa asioissa AI on paikallaan. Siis että opin paremmin, kun etsin itse? Tulkintakysymys. En minä enää muista komentoa enkä JSON muotoa. Joten se siitä oppimisesta.

WordPressin linkkien löytäminen

Minulla oli selvät kuviot. Laitetaan aina näppärän WP CLI:n tekemään search&replace, etsi ja korvaa, väärille linkeille. Se miten saisin siirrettyä mp3-tiedostot Amazonilta Hetznerillä jäisi myöhemmäksi.

Ongelma oli siinä, että käyttämäni podcast-plugin Seriously Simple Podcast ei tallennakaan audioiden sijaintia tietokantaan omanaan. En löytänyt ensimmäistäkään audiolinkkiä WP CLI:llä enkä suoraan tietokannasta etsimällä. Osa ongelmaa oli varmaan sekin, että en käyttänyt podcasteille omaa kustom-artikkelityyppiä, vaan halusin niiden näkyvän artikkeleina muiden artikkelien kanssa samassa hakemistorakenteessa.

Penkomisen ja ihmettelyn jälkeen alkoi avautumaan, että linkkitieto varmaan laitetaankin muiden meta-tietojen joukkoon. Löytääkseni oikean avaimen tein tämän olemassa olevalle artikkeli-ID:lle:

❯ Näytä koodi

wp post meta list 149595 | grep -iE 'ss_|ssp_|castos|podcast|url'

Käytin grepissä useampaa, koska en tiennyt kirjoitusmuotoa.

Nyt audiot löytyivät. Ne olivat meta-tiedoissa avaimella audio_file

Tuon selvittämisessä meni oma aikansa ja samalla toinen aivopuolisko pohti tiedostojen siirtoa. Aloin muuttamaan suunnitelmaa. Ehkä kannattaisikin ensin siirtää tiedostot Hetzneriin ja sitten vaihtaa urlit. Enkä keksinyt siihen muuta tapaa kuin hyödyntää CSV:ksi tehtävää listaa.

Ehkä tässä välissä on syytä alleviivata, että minä en ole koodari enkä osaa ajatella kuin koodari.

Nyt jälkeenpäin ajatellen ehkä tekisin koko proseduurin toisella tavalla, mutta minä hypin ongelmasta toiseen eikä minulla ole osaamista miettiä asiaa kokonaisuutena. Varsinkin kun en useimmiten edes hahmota kokonaisuutta, vaan lähden ongelmasta A, enkä tiedä mihin kohtaan aakkosia päädyn, tai edes missä kirjaimistossa. Ja joka kerta, jopa ihan simppelien bash-komentojen kanssa, Google saa tehdä töitä. Ja sitten copy&pastetan ja ihmettelen miksi ei tapahdu sitä mitä haluan.

Siirto Hetznerille

Alkuperäinen suunnitelma oli simppelisti vaihtaa urlit muotoon cdn.katiska.eu ja pitää edelleen CloudFront mukana. Koska halusin irti Amazonista, useistakin syistä, niin suunnitelma muutti muotoaan. Siirränkin ensin tiedostot AWS:n S3:sta Hetznerin S3:een ja mietin linkkien korjaamista myöhemmin. Olin vakuuttunut siitä, että tuon saavuttamiseksi tarvitsen CSV-listauksen. Sen tein tällä:

❯ Näytä koodi

echo "id,title,audio_url" > podcast_audio_links.csvfor id in $(wp post list --post_type=post --post_status=publish --format=ids); do  url=$(wp post meta get "$id" audio_file 2>/dev/null)  if [ -n "$url" ] && echo "$url" | grep -qE 'cdn\.katiska\.info/kb/'; then    title=$(wp post get "$id" --field=post_title | sed 's/"/""/g')    echo "\"$id\",\"$title\",\"$url\"" | tee -a podcast_audio_links.csv  fidone

Jos joku yrittää adoptoida tekemäni asiat, niin yksi vinkki: tiedostojen otsikoista kannattaa editoida pilkut pois. Jatkon suhteen ylimääräiset pilkut tekevät hassuja asioita, kun CSV:tä käsitellään lisää. Eikä niitä otsikoita edes käytetä mihinkään. Ne ovat mukana vain ihmistä varten, että näkee mihin julkaisuun mikäkin tiedosto kuuluu.

Tuon prosessointi vienee aikaa. WP CLI on hidas ja luupeissa vielä hitaampi. Kärsivällisyys ja varsinkin tmux tai screen ovat ystäviäsi.

Hetznerin S3 on AWS:n klooni, joten aws cli toimii. Jos sinulla ei ole sitä, niin googleta asennus. Älä käytä aptia tai snapia. Molemmat antavat liian vanhan version.

Kun aws cli on asennettu, niin sille täytyy kertoa pari perustietoa, kuten region ja vaadittavat API-tiedot. Asetuksille on jokin config-komentokin, mutta koska mukaan tarvitaan myös Hetznerin API, niin käsin pääsee helpommalla.

Tee hakemisto ~/.aws. Sinne tulee kaksi tiedostoa, config ja credentials.

config

❯ Näytä koodi

[default]region = eu-west-1

Vaihda tilalle käyttämäsi. Jos tarvitset useamman regionin, niin googleta miten niitä käytetään. Minulla ei ole hajuakaan.

credentials

❯ Näytä koodi

[default]aws_access_key_id = <lyhyempi>aws_secret_access_key = <pidempi>[hetzner]aws_access_key_id = <lyhyempi>aws_secret_access_key = <pidempi>

Sitten on aika tehdä siirto. Allaoleva scripti on live-esimerkki, joten muuta tarvittavat.

CSV-FILE on edellä käytetyn CSV-tiedoston polku ja nimi; jos teet töita samassa hakemistossa, kuten WordPressin kotihakemistossa edellä käytettyjen WP CLI komentojen takia, niin polkua ei tarvita

HETZER_BUCKET taisi mennä väärin nimetyksi, näin jälkeenpäin ajatellen, tai en tunne termejä. Se on se hakemisto, joka on tehty bucketiin, jonka nimi näkyy endpointissa. Jos on tarve siirtää juureen, niin en tiedä miten se tehdään. Tai onko se edes mahdollista.

HETZNER_ENDPOINT löytyy bucketin tiedoista. Jostain oudosta UX-töpistä johtuen Hetzner antaa endpointin ilman bucketin nimeä. Joten sen, minulla podcastit, joutuu lisäämään itse. Kuten myös https://

HETZNER_PROFILE on se nimi, jonka annoit tiedostoon ~/.aws/credentials

❯ Näytä koodi

#!/bin/bash# AsetuksetCSV_FILE="podcast_audio_links.csv"TMPDIR="/tmp/podcast_tmp"HETZNER_BUCKET="s3://kaffepaussi"HETZNER_ENDPOINT="https://podcastit.hel1.your-objectstorage.com"HETZNER_PROFILE="hetzner"# Luo väliaikainen hakemisto jos puuttuumkdir -p "$TMPDIR"# Ohita CSV:n otsikkorivi ja käsittele rivittail -n +2 "$CSV_FILE" | while IFS=, read -r id title url; do    # Poista mahdolliset lainausmerkit    id=$(echo "$id" | tr -d '"')    title=$(echo "$title" | tr -d '"')    url=$(echo "$url" | tr -d '"')    filename=$(basename "$url")    echo "🔽 Ladataan: $filename"    curl -s -L -o "$TMPDIR/$filename" "$url"    if [[ -s "$TMPDIR/$filename" ]]; then        echo "🟢 Siirretään Hetzneriin: $filename"        aws s3 cp "$TMPDIR/$filename" "$HETZNER_BUCKET/$filename" \            --endpoint-url "$HETZNER_ENDPOINT" \            --profile "$HETZNER_PROFILE"    else        echo "❌ Lataus epäonnistui: $filename ($url)"    fidoneecho "✅ Kaikki valmista. Tiedostot löytyvät bucketista: $HETZNER_BUCKET"

WordPressin urlien korjaaminen

Viimeiseksi pääsin siihen, joka oli alussa työlistan ykkönen: WordPressin urlien korjaaminen ja korvaaminen.

Koska tiedostonimet pysyivät samana ja vain lähde muuttui, niin käytetään samaa CSV:tä ja korvataan vanha Hetznerin endpointilla.

❯ Näytä koodi

#!/bin/bash# AsetuksetCSV="podcast_audio_links.csv"ENDPOINT="https://podcastit.hel1.your-objectstorage.com/kaffepaussi"# Tarkista että CSV on olemassaif [[ ! -f "$CSV" ]]; then    echo "❌ CSV-tiedostoa '$CSV' ei löydy."    exit 1fi# Otsikon kauttatail -n +2 "$CSV" | while IFS=, read -r id oldurl; do    id=$(echo "$id" | tr -d '"')    oldurl=$(echo "$oldurl" | tr -d '"')        filename=$(basename "$oldurl")    newurl="$ENDPOINT/$filename"    echo "🔄 Päivitetään ID $id: $filename"    wp post meta update "$id" audio_file "$newurl"doneecho "✅ Kaikki meta-päivitykset tehty."

Se oli siinä. Nyt audioni on siirretty Amazonilta Hetznerin hoiviin ja podcast-julkaisuissa on uudet linkit.

Jos käytät Varnishia, niin tee ban() kaikille podcast-julkaisuille.

Tässä vaiheessa join kupin kahvia. Ja katsellessani linkkien ulkomuotoa tulin siihen tulokseen, että ne ovat suunnattoman rumia. Joten vaihdoin Nginxissä proxyn avulla Hetznerin endpointin muotoon podcast.katiska.eu ja päivitin vielä kerran urlit WordPressissä. Olisihan tuonkin voinut hoitaa kerralla kuntoon, mutta kuten sanottua — ei minulla ole suunnitelmaa, vaan etenen katastrofi kerrallaan.

Joten jos teet jotain samanlaista, niin laita ensin Nginxin proxy-ohjaukset kuntoon, siirrä sitten tiedostot Hetznerin endpointiin ja vaihda viimeiseksi WordPressin linkit osoittamaan proxyn käyttämään domainiin.

# preview.content
Olin aikoinaan kokeillut CDN:ää WordPresseissä. Tein sen CloudFrontin kautta AWS:n S3-buckettiin. Luovuin siitä, koska suomalaiselle sivustolle Suomessa Amazonin(kaan) CDN:stä ei ole yhtään mitään hyötyä. Mutta purku jäi pelkästään CDN:n mahdollistaman pluginin poistamiseen WordPressistä. Pelkästään siksi, että minulla oli podcastejä CDN-linkillä, enkä halunnut rikkoa niitä. Minun piti korjata ne, joskus. […]

# summary
Olin aikoinaan kokeillut CDN:ää WordPresseissä. Tein sen CloudFrontin kautta AWS:n S3-buckettiin. Luovuin siitä, koska suomalaiselle sivustolle Suomessa Amazonin(kaan) CDN:stä ei ole yhtään mitään hyötyä. Mutta purku jäi pelkästään CDN:n mahdollistaman pluginin poistamiseen WordPressistä. Pelkästään siksi, että minulla oli podcastejä CDN-linkillä, enkä halunnut rikkoa niitä. Minun piti korjata ne, joskus. […]

# summaryMap.fi
Olin aikoinaan kokeillut CDN:ää WordPresseissä. Tein sen CloudFrontin kautta AWS:n S3-buckettiin. Luovuin siitä, koska suomalaiselle sivustolle Suomessa Amazonin(kaan) CDN:stä ei ole yhtään mitään hyötyä. Mutta purku jäi pelkästään CDN:n mahdollistaman pluginin poistamiseen WordPressistä. Pelkästään siksi, että minulla oli podcastejä CDN-linkillä, enkä halunnut rikkoa niitä. Minun piti korjata ne, joskus. […]