Every repository with this icon (
) is private.
Every repository with this icon (
) is public.
| Description: | A Django blog. Formerly Oebfare by brosner. edit |
-
There needs to be a way for users to easily get and install additional apps such as a widgets.
Comments
-
A single installation of Mighty Lemon should be able to support multiple blogs and logging in to separate blogs all hosted on the same code base.
Comments
-
Design a way to associate a URL (leahculver.com) with a blog. Or maybe several URLs with a blog (leahculver.com and blog.leahculver.com). The actual urls will be done by DNS but I'm assuming we might want to reference this in the code sometimes.
Comments
justinlilly
Tue Apr 28 04:02:02 -0700 2009
| link
It seems to me that this could possibly be tied to django sites framework?
-
A Blog should be able to have multiple authors and possibly one main owner. I'm not sure that we need to support roles yet, but it's something to think about.
Comments
-
Part of the graphics should contain some sort of logo.
Comments
gregnewman
Mon Apr 06 17:25:51 -0700 2009
| link
I'm already on this one.
-
Part of the identity should be a 16 x 16 favicon. Maybe a lemon?
Comments
-
Design and code a main website for the project. Could include the following:
- logo
- tagline or short description
- project goals (see wiki for ideas)
- link to repository
- link to any downloads (though we don't have any yet)
- link to mailing list
- link to wiki
- link to issues
- whatever else is helpful for a project page!
Comments
-
Not sure about everyone else, but I'm not a super big fan of distributing my blog design with the project. It implies that I'm okay with other people using my design, which isn't the case. Perhaps we need our own Kubric?
Comments
I contacted a dude about helping design a generic looking template but haven't heard much back for a week or so. I'll keep working on this. Feel free to remove your templates from the main repo though.
When I wrote my original blog engine I adapted a wordpress theme(a good one!) to be the default. Perhaps we could do something similar if we find a good one with a sufficiently permissible license.
justinlilly
Fri Apr 17 23:50:23 -0700 2009
| link
Spent some time this evening messing about with html goodness. Don't know if its worth a damn, but here's what came of it. http://bit.ly/AOS7c
Oooh. I like that design a lot. I'd use something like that for my blog.
justinlilly
Mon Apr 20 04:56:37 -0700 2009
| link
I've pushed what I've done so far to a new_theme branch of ML.
-
Fully PIP installable - this needs to be verified and a little better documented.
Comments
-
The installation instructions could be clearer and neater and possibly documented in easy steps on the website. There also needs to be a better way to create a default blog.
Comments
-
Currently Mighty Lemon requires that you use Akismet for spam and requires you to have a Wordpress account. You should be able to have no spam filtering if you like or be able to use any other spam service (or multiple) such as TypePad Anti-spam... or... I can't think of any more.
Comments
-
This would be an alternative to the basic Django admin. Design TBD
Comments
this can bring some sort of database backed settings (maybe djblets.siteconfig from reviewboard can be useful)
-
A good blogging system will have a way to push updates (or encourage users to update) with minimal disruption to their blog. This feature should allow for both feature and security updates. Design TBD.
Comments
justinlilly
Mon Apr 06 19:55:38 -0700 2009
| link
Realistically, let's think about how this can play out.
A) User installed via pip
pip --upgrade mightylemon
B) User installed via archive
cd /path/to/mightylemon
wget http://mightylemon.com/ml.zip
unzip ml.zipC) User installed via VCS
cd /path/to/mightylemon
(vcs update command)--
What these don't take into account: schema changes, local changes to the project (templates, etc), etc. I think we need to set expectations on what an update really entails. Is it clicking a button and its updated? Is it running a script? If we know what our ideal solution is, we can perhaps work towards it a bit better.
-
Verify that all text entry fields support UTF-8 and make necessary fixes.
Comments
-
Allow for translation of site text. Any language is welcome as the first translated language! The sooner this is in place and tested, the easier it will be later.
Comments
I'm Italian but I haven't any experience in translating software, but I can try to do something (translating seems quite boring in relation to programming!!)
I heard about something like django-rosetta... any advice (tools, practices...) on the matter is welcome. Just don't take this words as a promise at the moment :DOK I've done some initial translation one for every single app that needed it using django-rosetta.
Now some question comes to my mind:
What should I write in line 2 and 3 (copyright owner and license [BSD?]) of headers for translation files?
At the same link, on line 7 I set "Project-Id-Version" as "projectname-appname" (in django it's simply "django"). What do you think?I've put my changes in http://github.com/scotu/mightylemon/tree/locale-it but I haven't requested a pull via github because I don't know if you have some policy (ok it's not code but maybe you want to review it or something or maybe you prefer patches...) and who to ping for this (the mightylemon user?)
Please note that commit scotu/mightylemon@4428c32 also adds a __unicode__ method to the AuthorProfile model... sorry about not mentioning it in the commit message...
Talking about themes/template translation (that's where the interface really gets translated) I find it quite messy: the problem is that I need to create the translation catalogs in the main project directory; doing so the translations end up being mixed in one file: all the themes/templates you have and also the apps contained into the project dir go in a single file using
djamgo-admin.py makemessages -l=itany advice?
-
Create a simple WSYWYG editor for creating new posts. This really only needs to be in the user-facing admin but could also go in the Django admin if desired.
Comments
-
This includes a nice way to upload images, music, and various other files. We could possibly also offer nice permalinks for these assets. Multiple file backends (such as AWS S3) would be nice.
Comments
-
Comments
gregnewman
Tue Apr 07 04:39:29 -0700 2009
| link
I have a twitter pluggable (multi-account) i'm wrapping up which sends statuses when the admin updates a post. I could extend this a little to go bidirectionally if anyone is interested.
That sounds pretty cool! We don't really have a great way to do plugins yet, but feel free to explore this a bit. I'm mostly interested in displaying my (one) most recent status somewhere on my blog... but I'm sure everyone is interested in something different.
-
Display recent Flickr photos as a widget.
Comments
-
mightylemon is listed as a javascript project on github, obviously it should be listed as python. Makes searching and finding the project easier :)
Comments
-
0 votes
[Bug] related_name in blog.models.Post made translatable
4 comments Created 5 months ago by restlessRelated_name set for "blog" field in "Post" in blog.models shouldn't be translatable.
The code is:
class Post(models.Model):
blog = models.ForeignKey(Blog, related_name=_("posts"))This breaks things as soon as i18n is enabled and "posts" is translated to other language. You get an attribute error when blog.posts is called (for example in blog.views.py in privileged_post_queryset.
The solution is to change the above code to:
class Post(models.Model):
blog = models.ForeignKey(Blog, related_name="posts")Comments
this should be fixed in scotu/mightylemon@37a087f
Other (little) work has been done in my locale-it branch on translatable strings apart from italian translations if you are interested
Thanks for the answer. I've got one more question to you. How do you deal with locale settings? After I set LANGUAGE_CODE='pl' I have to do some hacks to have archive working. Here is what happens:
template filter some_date|date:"b" returns for example "czerw" as month name (it is "jun" in Polish) and it is no longer compatibile with urls resolver expecting (?P[a-z]{3})
Post model's get_absolute_url is not affected by locale and it always returns 'jun'. The method get_absolute_url uses strftime and not django.utils.format. The latter returns 'czerw'. Strange but this is how it works for me.
I can't just add month_format to generic view because the format is also hardcoded in get_absolute_url, so I also have to modify this method.
I wonder what is your solution for the above issues.
I've noticed that too, but I haven't dugg into the problem right now... I'm glad you've done so :) thanks
The best long term solution I see is avoid using the three-letters formatting for the month but go with the number. Doing so the url does not need to be translated and we can have one url for one resource instead of lots of urls for one resource (web crawlers...)
I'm looking forward other proposals...
-
0 votes
[Bug] Invalid translation string in blog.models.PostModerator
1 comment Created 5 months ago by restlessThere is an invalid translation string in PostModerator class defined in blog.models.
The code is:
subject = _('[%s] Comment: "%s"') % ( Site.objects.get_current().name, content_object, )and it should be something like:
subject = _('[%(site_name)s] Comment: "%(content)s"') % { 'site_name':Site.objects.get_current().name, 'content':content_object, }Otherwise makemessages raises an exception.
Comments
fixed that too :D scotu/mightylemon@37a087f
-
Markdown highlighting doesn't work for me. There is a whole Markdown object passed to template from code_hilite.markdown_to_html function.
Current code in blog.utils.code_hilite is:
def markdown_to_html(text): """ Convert markdown to HTML with code hiliting """ md = MARKDOWN md.source = text return unicode(md)it works for me only when I replace function's body with:
return markdown.markdown(text)To have syntax highlighting working I have to use:
return markdown.markdown(text, extensions=('codehilite',))Comments
- bug▾
- feature▾
- gregnewman▾
- idea▾
- justinlilly▾
- leah▾
- task▾
- Apply to Selection
-
Change Color…
Preview:preview
- Rename…
- Delete
What does this look like? settings.py munging? or is there an interface for this?
Perhaps something like the architecture from django-plugins(on my github) would be good.
Let's say that at this time I'm not sure to be able to implement this sort of idea, so take it just as a mind dump, also I haven't looked at django-plugins project by now (edit: after reading the docs in django-plugins it seems quite similar to what I wrote in this comment :) .
I think that maybe a normal django app could be extended to implement some sort of Mightylemon-plugin interface that permits the use of the app in a django project in the usual way (hook up in urls.py) and alternatively the reuse of the same codebase as a mightylemon plugin. The administration panel can have a "plugins" page that autodiscovers apps that implement that interface from the python path (too heavy?) and let you activate/deactivate the plugin;
Also installing from a trusted repo via web interface is quite cool but file system permission can bring huge pain.
I haven't looked into how to handle the syncdb step in this case (but probably also other mightylemon-specific plugins would require that step)
I also think that some "optional features" already built-in (like elsewhere or gravatar) should be pluginified (but included in the standard distribution of mightylemon).
The great downside I see to this plugins all the way down idea is that trying to generalize too much could imply a shift of focus from the real problem (building a great blog app)
thanks for your work, I hope to contribute in the future :)