2020 October
-
Leaving Hugo It's been a bit under two years since I migrated the site from Wordpress to Hugo. As discussed in this post one year ago, I was very happy with the general workflow of managing posts through markdown files in git, but had big problems with the Hugo build time, largely a consequence of my social media archiving. At that time, I didn't want to invest effort into migrating to a different backend, but the problem has only gotten incrementally worse since then, so I decided to take the jump and started working on it last month. Migration goals
2020 January
-
In a bid to reduce the number of webapps actually running on my server (for resource consumption reasons), I decided to migrate a small Flask app I had and merge into this larger Django app where I have a lot of my personal data tracking stuff. The Flask app was small enough, mostly containing backend support for this blog (like search and comment submissions) and some Twitter things. The migration was straightforward, taking around half a day, most of that was wrangling with Twitter API rate limits. It got me thinking, why did I build this using Flask in the
2018 October
-
Ten years ago this month, I started studying Django by trying to build my own blog application. I found the code lying around while I was going through some backups lately. It's way out of date, it uses an early version of django. I thought of bringing it up to speed, but that didn't seem practical. Instead, for archival purposes, I cleaned it up a bit and uploaded the code to a github repo. (Helpful github immediately warned me that having a very old version of Django was a security risk lol). There's a lot more information in the README.md
2009 February
-
You may have noticed the new color scheme and new "Theme Switcher" widget in the sidebar. I had done some CSS work during the past month in the office and it made me want to tweak the stylesheets on this site a bit. I figured I might as well make it easy to switch stylesheets, so I wrote a small Theme Switcher django app. (Well, it's more of a stylesheet switcher I guess) The model is simple: class Theme(models.Model): slug = models.SlugField() title = models.CharField(max_length=250) css_path = models.CharField(max_length=500) def __str__(self): return self.title I only needed one view -- to switch
2009 January
-
I actually had some trouble using django-pingback on my custom blog engine; the django-pingback documentation is mostly fine, but there were some caveats that I had to discover myself through a bit of debugging: The URL specified for the XML-RPC endpoint in the HTML head needs to be a full absolute url including domain, i.e. http://roytang.net/xmlrpc/, which gave me trouble when I was trying to test using localhost pinging to an online server. I eventually just decided to set it up, deploy on webfaction and test it online before I redirected the domain name. The documentation mentioned that the pingback
2008 December
-
Frontend: All page templates are valid (X)HTML. However, I choose not to claim valid XHTML (and no doc type declaration) since I can't guarantee that blog posts I write are compliant! The site uses standard CSS and uses the Blueprint CSS Framework for the grid layout of the page. The site design is entirely original (if not simple and bland -- I'm not very good with website design yet!). The site has minor usage of JQuery Javascript library in some parts. Backend: The server side uses Python and Django behind mod_python on Apache, with a MySQL database. The following Django
-
I played around with the built-in comments app today, trying to clean it up. Some findings: Some of the moderation views, such as flagging a post or deleting a post, accept a next parameter that determines where the view will redirect to after the operation. However, the way the url's are set up, there's no easy way to pass this parameter normally, even through query strings. This lovely bug is documented in http://code.djangoproject.com/ticket/8968. I wasn't confident enough to try patching it, so as a temporary workaround, I overrode the flag and delete templates and placed the following inside the form:
2008 November
-
I've been busy at work so fell a bit behind with Django. Last night I worked on a WordPress importer, so that I could migrate posts from my current blog(s) into the Django-powered blog that I'm coding. I'm using BeautifulSoup to parse the WordPress export file and insert them as Django objects. Since I was running the script repeatedly, I had to figure out how to easily run it from the command line, without having to run it from inside manage.py shell. After some searching, I found that what I needed to do was set an environment variable DJANGO_SETTINGS_FILE to
2008 October
-
I wanted to add some basic tagging to my blog app so I tried out django-tagging. Unfortunately, the featured downloads on the Google Code site are quite out-of-date and would not work with Django 1.0, so I did a subversion checkout instead. If you're getting an error like "ImportError: cannot import name parse_lookup", then you need to get the source code from SVN. Adding the tagging to the blog was pretty easy: Add the tagging app to settings.py Add a tagging.fields.TagField to the Post model Add a "tags" text field to the post form used. Modify templates to display the
-
... and now it works! http://www.randomencounters.bells-n-whistles.net/blog/ I think the apache service needed to restart mod_python or something... (I don't have SSH access so... )
-
So I got a basic blog app up and running. Posting, paged archives, etc. Comments implemented using the django.contrib.comments. No problems here, the only caveat being most of the current documentation found by Google searches refer to the pre-1.0 version. Need to peruse the official docs for 1.0 stuff. RSS feeds implemented using django.contrib.syndication, this one seems fine. I tested it and it's running fine on localhost. I also have a free django hosting account at http://bells-n-whistles.net, so I try to upload it there. However, when I access the website there (http://www.randomencounters.bells-n-whistles.net/blog/), I get the following error: 'comments' is not
-
"when redirecting, how can I make the redirect URL decoupled from the urls.py of the parent app?" -> It turns out that HttpResponseRedirect supports relative paths, so this was fine. return HttpResponseRedirect("../" + str(post.id) + "/") I got the basic posting structure up. /post/new/ -> To make new posts /post// -> To view a single post /post/all/ -> To view all posts I should probably start thinking of a better url scheme. Ideally, I'd want the @login_required views to be indicated as such in the urls. Something like "/admin/post/" for new posts "/admin/manage/" for a screen to manage posts to
-
The quintessential app to learn from is of course a blog. Started using a simple Post model. Added the new post form and view. Can now successfully insert posts into the DB. Next: -- create the detail page that will show the post after saving Figure out: -- when redirecting, how can I make the redirect URL decoupled from the urls.py of the parent app? i.e. if the parent app has the following mapping: ‘^blog/' -> pass to blog.urls.urlpatterns the blog app has mappings for ‘^post/new/' -> new post ‘^post/([A-Za-z-])/' -> post detail inside the view, I want to redirect