Blog engine

13 views
Skip to first unread message

Eratothene

unread,
Jul 17, 2007, 5:15:52 AM7/17/07
to Django users
Please, recommend me some full featured blog engines developed in
django.

Though, I have found some posts in this user group about available
blog engines, I still want to ask this question, as all posts are
dated summer 2006.

David Reynolds

unread,
Jul 17, 2007, 5:27:08 AM7/17/07
to django...@googlegroups.com
Hi,

I don't see why you would want to use someone else's blog app, when
blogs are quite personal to each person and so (relatively) trivial
to write.

Write a simple model for Entry with whatever fields you want (make
sure it has publish date field), add something like django-tagging
[0], use Django's generic date views [1] and you're pretty much there.

Seems like such a good first project to write in Django as well....


0 - http://code.google.com/p/django-tagging/
1 - http://www.djangoproject.com/documentation/generic_views/#date-
based-generic-views
--
David Reynolds
da...@reynoldsfamily.org.uk


Eratothene

unread,
Jul 17, 2007, 6:37:39 AM7/17/07
to Django users
There a lot of other features missing in such solution: comments, spam
protection, rss feeds and a lot more. I am searching for full featured
blog engine.

David Reynolds

unread,
Jul 17, 2007, 6:45:01 AM7/17/07
to django...@googlegroups.com

Django has it's own comment feature in contrib which with James
Bennett's comment-utils [0]
has spam protection and moderation. RSS feeds are easily done within
Django [1]

Next?

0 - http://www.b-list.org/weblog/2007/06/25/hacking-comments-without-
hacking-comments
1 - http://www.djangoproject.com/documentation/syndication_feeds/

--
David Reynolds
da...@reynoldsfamily.org.uk


Chris Moffitt

unread,
Jul 17, 2007, 10:36:06 AM7/17/07
to django...@googlegroups.com
It's definitely a good idea to roll your own but it is helpful to see other code to help you out.  I'm in the process of adding a blog to satchmo and have uploaded the code to svn but have not put it into production.

As it stands now, the code works but does not have comments enabled yet.  If nothing else, it's a good reference to help you out.

http://www.satchmoproject.com/trac/browser/satchmoproject.com/satchmo_website/apps/blog

-Chris


Paulo

unread,
Jul 18, 2007, 1:13:16 AM7/18/07
to django...@googlegroups.com
No to mention a good blog app that people can standardize on would be
a nice alternative to Wordpress[1] and Simplelog[2]. Having one would
definitely be helpful in the "spreading the word about Django"
department.

We made the switch to Django/Python over a year ago for our client
work and it was the best effin' decision we ever made. It kills me
Rails gets so much press... it has its uses but, from a small
design/development agency perspective, Django runs circles around
Rails. Using Django we're more efficient, more profitable, and server
admin/site maintenance is much more streamlined than in the old PHP
days.

Do we really have to wait for 1.0 to start the marketing push? ;-)

[1] < http://wordpress.org/ >
[2] < http://simplelog.net/ >
--
- - - --------- ----- -------- - - - -
http://www.linkedin.com/in/pauloelias

James Bennett

unread,
Jul 18, 2007, 2:01:24 AM7/18/07
to django...@googlegroups.com
On 7/18/07, Paulo <pau...@gmail.com> wrote:
> No to mention a good blog app that people can standardize on would be
> a nice alternative to Wordpress[1] and Simplelog[2]. Having one would
> definitely be helpful in the "spreading the word about Django"
> department.

I'm not entirely disinterested since I've been working on rewriting my
own blogging application to be released open source, but...

I think part of the reason that there isn't a "standard" blog
application built on Django is simply the fact that it's so easy --
it's quite literally a couple dozen lines of code to get a simple blog
application. A model for entries and a URLConf which routes to generic
views are all the Python you need to write, and then the generic views
and bundled applications in django.conrtrib -- admin, auth and
comments -- will do the rest. And if you want something more, it's
generally easier to be writing your own custom code from the start so
you can tailor things exactly how you want them.

Rails doesn't offer those sorts of components (from what I know of the
development team's choices, it's largely a philosophical matter, much
as we don't offer tight integration of a JavaScript toolkit), which
means that it's easier and more efficient for Rails users to
standardize on and contribute code to a single application which can
implement all the necessary bits.

So I'm not necessarily convinced that there's a great need for a
"standard" Django blog application; it would appease some folks, but I
have a feeling that in the Django world a lot of people really would
be happier, in the long run, writing their own app that does what they
need (trying to encourage that is one reason why I keep spinning off
bits of code from my blog into standalone applications -- when I do
eventually finish my rewrite and release everything, I'd like people
to be able to pick and choose the bits they want).


--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

karma...@gmail.com

unread,
Jul 18, 2007, 2:45:54 AM7/18/07
to Django users
I wrote a blogging system for myself that can be had through
subversion at this url: http://svn.karmazilla.net/hobby_projects/Djogg

I'm still looking for a good place to deploy my own instance, though.
I've kinda given up getting it to work in dreamhost.


On Jul 18, 8:01 am, "James Bennett" <ubernost...@gmail.com> wrote:

Kenneth Gonsalves

unread,
Jul 18, 2007, 2:29:36 AM7/18/07
to django...@googlegroups.com

On 18-Jul-07, at 11:31 AM, James Bennett wrote:

> So I'm not necessarily convinced that there's a great need for a
> "standard" Django blog application; it would appease some folks, but I
> have a feeling that in the Django world a lot of people really would
> be happier, in the long run, writing their own app that does what they
> need

except for nesh's thumbnails, i have always found it quicker to roll
my own things rather than spend time bolting on someone else's app to
my app.

--

regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/


Kyle Fox

unread,
Jul 18, 2007, 11:46:43 AM7/18/07
to Django users
It's easy to write a "basic" blog in Django. If that's all people
want, then great. Something like that will work perfectly for the
majority of bloggers (who probably won't get that much readership
anyway)...

But all this talk about making a "full-featured" blog app in Django --
one that will really get noticed (and thus get django noticed): what
we need is a blog with *more features* that could actually begin to
compete with something like Wordpress**.

I mean stuff like Akismet, Flickr integration, delicious/magnolia
bookmarks, multi-author (with per-object permissions), importing from
Wordpress, statistics, easy web-based installation (NOT easy_install
but a wizard someone could follow, like the Wordpress install, lots of
customization, integration with pingback services, etc.....

If that sounds like a lot, that's because it is. To even be a blip on
the screen it will need this kind of stuff. I also doubt the django-
admin will be sufficient for an application like this.

I know a lot of the stuff I've mentioned above has already been
hammered out by djangonauts -- I'm sure a snippet for almost every
feature has been posted on djangosnippets.org. It's a matter of
bringing all those together into something that works out of the box,
rather than everyone patching together their own frankenstein.

** By the way, I know "competing with Wordpress" is nearly
impossible. I'm just saying that to accomplish what it sounds like
people here are talking about, we need close to the same level of
functionality.

Kai Kuehne

unread,
Jul 18, 2007, 3:28:14 PM7/18/07
to django...@googlegroups.com
We don't need such an app (well, I don't need it).
If I want it, I write it in 20 minutes. :-)

Kai

Stefan Matthias Aust

unread,
Jul 19, 2007, 12:00:35 PM7/19/07
to django...@googlegroups.com
If it is so easy to create a blogging application with Django, then
this should be an argument for a standard application, not against it
IMHO.

At minimum, it could become a nice example application, either as part
of the django distribution or as a separate download. And if it is
still easy enough, make it a Wordpress killer. Make it as easy to
install and to use as Wordpress, being an example for the power of
elegance of Django (and Python) - something like Typo or Mephisto for
Rails.

Another important argument for one de-facto standard are plug-ins and
templates. There are zillions of templates (even nice ones) for
Wordpress. And you can add dozens if not hundreds of plugins to
further customize or extend the software.

If everybody is creating his or her own solution, there will not be no
synergy, no community, no attention. Rails became so popular,
because people *saw* how easy it was to create something. Just telling
them isn't enough :)

Stefan

Rob Hudson

unread,
Jul 19, 2007, 12:11:50 PM7/19/07
to Django users
Why not start a Google code repository and see how many people want to
chip in and help. This comes up often enough that it sounds like
there's enough interest.

Chris Hoeppner

unread,
Jul 19, 2007, 12:12:06 PM7/19/07
to django...@googlegroups.com
Stefan Matthias Aust escribió:
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com
> To unsubscribe from this group, send email to django-users...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en
> -~----------~----~----~----~------~----~------~--~---
>

Actually... It took me 30 minutes to get my blog engine running, without
the design. And, there's no need to "make" for plugins. A Django app
*is* a plugin to the django framework itself, if you'd like to see it
that way. I have a common repository on the python path with things I
tend to use often, like typogrify, markdown, and feedparser. You can
just load them from any other app.

There would still be the problem of people wanting to
"one-click-install" plugins and themes. But why would such a person even
think about using a framework instead of wordpress?

And I still think that there's absolutely no need to make a de-facto
standard blog app in django. You gotta use what works best for you, man.

signature.asc

Stefan Matthias Aust

unread,
Jul 19, 2007, 12:35:45 PM7/19/07
to django...@googlegroups.com
Chris,

2007/7/19, Chris Hoeppner <ch...@pixware.org>:

> There would still be the problem of people wanting to
> "one-click-install" plugins and themes. But why would such a person even
> think about using a framework instead of wordpress?

My point was that - assuming the Django community wants to spread the
word that Django is the best answer to whatever question - that you
have to target people who just want to use an application and
demonstrate the greatness. This requires a momentum, a community.

If you just not want to bother those people and do not want to be
bothered, then, well, let them use Wordpress :)

All I tried to say is perhaps that people who are looking for a simple
to use blogging solution might want to get there with the least amount
of work. Installing Wordpress is damn easy. Everybody with "computer
knowledge" therefore typically recommends Wordpress (let's not dive
into the discussion here that PHP is nearly always preinstalled and
Python not).

Would you recommend your non-technical friends to go and install
Python and Django, then to compile a common repository of stuff
grabbed from all over the web and then to write their own custom
blogging solution because it's so easy? I guess not :)

--
Stefan Matthias Aust

Chris Hoeppner

unread,
Jul 19, 2007, 12:40:07 PM7/19/07
to django...@googlegroups.com
Stefan Matthias Aust escribió:

Depends. If they're non-technical but willing to learn, yes. And I'd
assist them. If they're just stupid and want it to "just plain work"
then I'd tell them to go and buy a book about "windows for dummies".

And I don't mean that I *would*, but more that I *have done many times*.
Some of them come back after a while, knowing a bit more, and wanting to
learn. Others just don't bother me ever again. I like both of them :-)

signature.asc

Rob Hudson

unread,
Jul 20, 2007, 3:30:26 PM7/20/07
to Django users
A lot of the same arguments against making a standard blog project
could probably be applied to Rails, but here's a blog app in Rails...
http://simplelog.net/

I think an open-source Django blog project would be good because
1) It would be Usable to many (as evidenced by this thread and others
before)
2) Useful to many as a reference and resource

#2 is particularly interesting to me because I've written a simple
blog in Django and there are some non-obvious things that having a
reference implementation to look at would be nice. Things like:

* Feeds (Atom, RSS, both)
* Comments (with spam filters)
* Open-ID enabled comments?
* Grouping blogs and links and whatever other objects by date using
generic relations (possibly?)
* Previewing links that aren't "published" yet, possibly using the
ADMINS option, while returning a 404 for anyone else?
* Writing a script executed by cron to pull content from other sources
and save them to your models. (I did this for Magnolia recently.)
* etc.

If anyone wants to start one I'd be interesting in joining in and
playing.

-Rob

James Bennett

unread,
Jul 20, 2007, 3:49:08 PM7/20/07
to django...@googlegroups.com
On 7/20/07, Rob Hudson <trebor...@gmail.com> wrote:
> #2 is particularly interesting to me because I've written a simple
> blog in Django and there are some non-obvious things that having a
> reference implementation to look at would be nice. Things like:

To be fair, though, a lot of these things are already implemented, as
part of Django itself, as contrib applications or as freely-available
third-party applications.

> * Feeds (Atom, RSS, both)

django.contrib.syndication

> * Comments (with spam filters)

django.conrtib.comments + comment_utils

> * Open-ID enabled comments?

There are a couple good OpenID implementations around; Simon
Willison's already doing OpenID for comments and has written up how he
did it.

> * Writing a script executed by cron to pull content from other sources
> and save them to your models. (I did this for Magnolia recently.)

http://code.google.com/p/jellyroll/

etc.

Kai Kuehne

unread,
Jul 20, 2007, 4:08:09 PM7/20/07
to django...@googlegroups.com
Hi Kyle,

On 7/18/07, Kyle Fox <kyle...@gmail.com> wrote:
>
> It's easy to write a "basic" blog in Django. If that's all people
> want, then great. Something like that will work perfectly for the
> majority of bloggers (who probably won't get that much readership
> anyway)...
>
> But all this talk about making a "full-featured" blog app in Django --
> one that will really get noticed (and thus get django noticed): what
> we need is a blog with *more features* that could actually begin to
> compete with something like Wordpress**.

Ok, not 20 minutes but 10 hours. Just start it.
No one stops you from doing it.

Kai

David Reynolds

unread,
Jul 23, 2007, 4:49:17 AM7/23/07
to django...@googlegroups.com

Pretty sure I mentioned most of these earlier in the thread...

--
David Reynolds
da...@reynoldsfamily.org.uk


Henrik Lied

unread,
Jul 24, 2007, 5:51:41 PM7/24/07
to Django users
This sounds great. I created a project on Google Code:
http://code.google.com/p/django-blog-engine/

Chris Moffitt

unread,
Jul 24, 2007, 6:06:09 PM7/24/07
to django...@googlegroups.com
I think I mentioned earlier in this thread, that I do have my take on creating a blog here -
http://www.satchmoproject.com/trac/browser/satchmoproject.com/satchmo_website/apps

It's pretty full featured right now and makes use of the tagging and comment_utils libraries.  It still needs the feeds but that should be pretty simple.  It's BSD licensed so hopefully it will be useful to folks.

-Chris

Henrik Lied

unread,
Jul 27, 2007, 5:14:22 PM7/27/07
to Django users
This is great, Chris, but the fact of the matter is that it won't
appeal to the "Wordpress crowd".
That group wants in-browser setup, easy plugin architecture etc.
contrib.admin wouldn't do the trick. The admin-panel would have to be
hand made.

For the plugin architecture: I have no idea how we'd do this well. Any
input here?
It *could* be done in a Facebook Apps-manner (the actual code is
remotely hosted, the admin-panel would show a list of available
plugins), but I don't know how ideal this would be in a real world
scenario. It sure would be great, though!


On Jul 25, 12:06 am, "Chris Moffitt" <ch...@moffitts.net> wrote:
> I think I mentioned earlier in this thread, that I do have my take on

> creating a blog here -http://www.satchmoproject.com/trac/browser/satchmoproject.com/satchmo...

Chris Hoeppner

unread,
Jul 28, 2007, 6:45:14 AM7/28/07
to django...@googlegroups.com
Henrik Lied escribió:
What about the symphony way of plugins? You have a page in the admin
with the latest plugins available (rss?) and you just click one and the
app downloads and istalls it.

Henrik Lied

unread,
Jul 28, 2007, 10:54:43 AM7/28/07
to Django users
When you say "installs", do you mean that the plugin is retrieved from
the external site, and placed somewhere on the users host, or is it
constantly querying the plugin on a remote computer?

The first of those two options would definitely be the best. But I'm
having some problems working it out IRL:
Let's say you've just installed the Akismet-plugin. How are we
supposed to notify the comment framework that a new plugin has been
installed - and better yet - how it should use it? This is a valid
problem for almost every plugin. If we manage to resolve a good answer
to that question, I'm done being a critic. :-)

Henrik Lied

unread,
Jul 28, 2007, 11:28:31 AM7/28/07
to Django users
Ok, so I've been thinking some more.

The model could be something like this:
class Plugin(models.Model):
"""(Plugin description)"""
pointer = models.FilePathField() ## Could work, right?
name = models.CharField(maxlength=200)
description = models.TextField(blank=True, null=True)
url = models.URLField()
apply_to = models.ForeignKey(ContentType)
active = models.BooleanField(default=False)

We then would have to make a standard on how the plugin-packages would
be designed.
A zip-file would probably work out OK. We would then have to get this
zip-file, run through it and copy its files into a plugins-
subdirectory. The package should have a info.txt-document, where the
plugin title would be on the first line and description on the second.

But - I'm still not sure how we'd easily hook this into other
applications - at least not without the user having to modify the
source code...

Christian Hoeppner

unread,
Jul 28, 2007, 3:40:15 PM7/28/07
to django...@googlegroups.com
Henrik Lied escribió:

The first version should do ;)

As for your question about "letting the comment app know", it would be a
nice idea to keep looking at django for answers. Does this situations
sound familiar?

I was thinking of middleware. You might "register" a plugin to work
agains some app (or apps) and therefor, make the app(s) call certain
methods within the plugin. The plugin would only have to implement those
methods.

If we do the "registering" stuff at database level, it would be a snap
to automate the installation.

Only, the apps need to know that they must call something. Definately,
the current django apps (like comments) do not behave that way, and
hacking them is not the answer.

What about a plugin middleware? It could check incoming requests for
certain data in the request (perhaps a post key?) and do something
accordingly.

If there's a way to make this approach work with a single middleware
(BlogPluginMiddleware?) this would be a pretty nice beginning :-)

Chris

signature.asc

Forest Bond

unread,
Jul 29, 2007, 9:15:38 AM7/29/07
to django...@googlegroups.com

See twisted.plugin. Define your interfaces, and let twisted handle the rest.

Don't pull a PHP-ism like forcing users to modify code. That is, by definition,
not a plugin architecture.

-Forest
--
Forest Bond
http://www.alittletooquiet.net

signature.asc

Henrik Lied

unread,
Jul 29, 2007, 1:49:54 PM7/29/07
to Django users
@Forest: I agree, it should be that simple. But let's say you've got a
comment reply plugin. How would we - through a middleware - manage to
intercept our usual comment system, and modify the HTML template
source to fit the plugin? It's cases like these I see the potential
pitfalls of our way of thought. Please, enlighten me if the answer is
simple. :-)

Forest Bond

unread,
Jul 29, 2007, 9:16:51 PM7/29/07
to django...@googlegroups.com

Well, extensibility is tough for exactly that reason. You have to anticipate
the ways in which your application might be extended. This is an extremely
difficult task, for that simple reason that it is impossible to predict the
future.

You really don't want to be modifying templates (or any other source files) when
a new plugin is installed. What you do want is to have placeholders in your
templates where plugins may contribute additional markup that will appear on the
page.

signature.asc

Chris Hoeppner

unread,
Jul 30, 2007, 5:13:28 AM7/30/07
to django...@googlegroups.com
Forest Bond escribió:

What most of you take as prototype is wordpress. And there are quite
some plugins requiring you to modify your templates. If a plugin is to
actually *output* anything into a template, it might have a few template
files that define an outcome. Then, you must only {% include %} that
file in an appropiate place. Seems flexible enough to me, while newbies
do only have to copy-paste the include tag into their template.

Of course, if the templating engine is solid, themes are to be released,
and, as with wordpress, there can be many themes like K2, that are
already aware of many most-used plugins.

Just to make it clear. It's still the template's job to take care of
display. The plugin must not *modify* a single source file, as stated above.

And, Forest, if you provide enough hooks where plugins can join the
app's flow (like the plugin middleware, and the template imports),
you're done predicting the future. We just have to think about the right
places where to place hooks.

Actually, is there anyone *really* able to contribute some code to this
endeavour?

Chris

Reply all
Reply to author
Forward
0 new messages