Tag: blogging

Posted on

WordPress-blogi ja HTTPS

Periaatteessa WordPressin hallinnan voi sujauttaa SSL:n alle suhteellisen yksinkertaisesti. Ongelmalliseksi se muodostuu siinä tapauksessa, että maailmalle näkyvään osoitteeseen ei liity varmennetta. Esimerkiksi mummila.netillä ei ole omaa varmennetta, koska sellaisen hankkiminen on melko kallista.

Www-hotellina käyttämäni Kapsin palvelimella on varmenne, ja niinpä https-yhteydet mummila.kapsi.fi-osoitteeseen (jonka http-sisältöä mummila.net tosiasiassa vain heijastelee) ovat mahdollisia. Valitettavasti WordPressin hallinta ei kuitenkaan taivu kovin sujuvasti SSL:n alle siten, että blogi näkyisi ulkomaailmalle yhden palvelimen (omassa tapauksessani mummila.net) alla, ja hallintayhteyksiin taas käytettäisiin toista palvelinta (mummila.kapsi.fi).

Kaikkein ongelmallisin kohta on kommentointi. Tuollainen kaksisuuntainen viritelmäkin olisi vielä kohtalaisen helppo toteuttaa, jos kommentointia ei olisi: kaiken hallintoliikenteen voi .htaccessin ja WordPressin URL-asetuksen avulla pakottaa https:n alle, ja kaikki muu näkyy maailmalle edelleen oman domainin eli blogin URL:n alla tavallisessa http-yhteydessä. Mutta jos tuon WordPressin URL:n asettaa osoittamaan https-yhteyden sallivalle palvelimelle, joka on eri kuin millä blogin sisältö näytetään, kommenttien yhteydessä käytetyt evästeet eivät tietenkään toimi, koska niitä ei pysty asettamaan palvelinten kesken ristiin.

Kun evästeiden asettaminen ei toimi, kommentoijalle normaalisti näkyviä ilmoituksia kommentin päätymisestä moderointiin ei näytetä. Niinpä kommentoijasta vaikuttaa siltä kuin onnistuneesti jätetyt kommentit katoaisivat mustaan aukkoon, vaikka tosiasiassa ne ovatkin vain moderoinnissa. Lisäksi sisäänkirjautuneena oleminen ei näy kommenttilomakkeessa, vaan se kysyy myös ylläpitäjältä osoitetietoja. Jälkimmäisen ongelman takia minun täytyy pitää turvatonkin kirjautumismahdollisuus käytössä, koska muutoin en pystyisi kommentoimaan omaa blogiani virallisella blogi-isännän identiteetilläni.

Käytännössä siis salattua yhteyttä voi sujuvasti käyttää vain täällä blogin konehuoneen puolella touhutessaan, esimerkiksi uusien merkintöjen luomisessa ja julkaisussa. Onhan sekin nyt tietysti tyhjää parempi, koska julkaiseminen on se kaikkein useimmin sisäänkirjautuneena harrastettu toiminta. Eivätkä ruotsalaiset tietenkään salasanojani saa, kun Kapsin palvelimet ovat kotimaassa. Kotimaisia nuuskijoita tällä lähinnä torjutaan.

Posted on

WordPress URL parameter for getting the comments feed

The parameter you need to apply to WordPress’ index.php in order to get the feed for comments seems bizarrely eluding, so I’ll make a note of it here for future reference: it’s feed=comments-rss2. So when a WP blog at http://domain.com/blog/ doesn’t have pretty permalinks (which renders the comments feed URL to http://domain.com/blog/comments/rss2), you’ll find the comments feed at http://domain.com/blog/?feed=comments-rss2.

Posted on

Mirroring a WordPress blog for offline viewing

I’m making a note of this for my own future reference.

As a premise, you need the blog to have pretty permalinks. There might be a way to make wget handle those http://site.com/blog/?p=123 -type URLs so that they can be viewed offline, but for me the easiest way around this was to simply switch to the Day and name option in Settings → Permalinks. That way individual posts will have URLs ending in slashes, resulting in the content being saved to a good old index.html inside a subdirectory, in the local copy.

So obviously, if you’re mirroring someone else’s blog, whose settings you don’t have access to, and which doesn’t use pretty permalinks, you’ll have to find another way to make the downloaded filenames work.

Otherwise, you’re good to go: fire up wget like this:
wget --convert-links --mirror --no-parent --no-host-directories http://site.com/blog/

Posted on

[Solved] WordPress: Cannot update permalink structure

I ran into this strange problem, where the changes I made on the Customize Permalink Structure page of a WordPress 2.5.1 installation wouldn’t get saved, no matter how many times I pressed the Save changes button.

Well, it turns out, for some reason you need to have JavaScript enabled for it to work.

Posted on

WordPress and a problem with URLs containing UTF-8 characters

Looks like WordPress does rather poorly with internationalized domain names. I just tried adding such a bookmark, and WordPress ate all the non-ascii characters. I can change the URI directly from phpMyAdmin, but WP still refuses to display or link it correctly both in the Blogroll management and on the site.

(Sorry about the somewhat misleading title, but that’s how I went googling for the problem, so maybe someone else will, and can find a confirmation for their suspicions here.)

Posted on

Solved: svn: Working copy 'wp-content/themes/default' is missing or not locked

I ran into this problem when trying to upgrade several of my WordPress-powered blogs through Subversion. The cause was that I had replaced the default theme directory with a copy of my working theme, due to the ‘reverts to default’ bug which, by the look of things at WP’s support forum as well as my own experience, is still alive and well.

The default theme is part of the svn repository and svn expects to find its own data on the current status of the files, but a copy of my own theme doesn’t have the data, so it complains about the missing or not locked working copy. The solution is to delete the default theme directory based on my own, then do a svn up to fetch a copy of the original default, then do a copying-over: cp -r my-working-theme/* default/

Now the working copy of the default looks like my own, yet is seen by svn so that a svn sw http://svn.automattic.com/wordpress/tags/2.3.3/ (or whatever the new version is) is possible. Note that editing style.css is required to tell the default apart from the actual working theme. I also like to use the screenshot of the original default to make it stand out when the working theme once again gets replaced by the default.

Posted on

WordPress 2.3.3 Released

WordPress 2.3.3 is an urgent security release. A flaw was found in our XML-RPC implementation such that a specially crafted request would allow any valid user to edit posts of any other user on that blog. In addition to fixing this security flaw, 2.3.3 fixes a few minor bugs.

WP Dev Blog