Menu
▾
▴
pyblosxom-users — Mailing list for pyblosxom users and hackers.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(53) |
Feb
(81) |
Mar
(47) |
Apr
(29) |
May
(32) |
Jun
(24) |
Jul
(41) |
Aug
(86) |
Sep
(40) |
Oct
(28) |
Nov
(11) |
Dec
(23) |
| 2004 |
Jan
(32) |
Feb
(54) |
Mar
(30) |
Apr
(28) |
May
(113) |
Jun
(17) |
Jul
(5) |
Aug
(111) |
Sep
(103) |
Oct
(18) |
Nov
(5) |
Dec
(38) |
| 2005 |
Jan
(31) |
Feb
(26) |
Mar
(69) |
Apr
(36) |
May
(45) |
Jun
(35) |
Jul
(11) |
Aug
(25) |
Sep
(9) |
Oct
(27) |
Nov
(4) |
Dec
(11) |
| 2006 |
Jan
(33) |
Feb
(11) |
Mar
(7) |
Apr
(10) |
May
(11) |
Jun
(2) |
Jul
(9) |
Aug
(7) |
Sep
(22) |
Oct
(40) |
Nov
(34) |
Dec
(5) |
| 2007 |
Jan
(21) |
Feb
(23) |
Mar
(28) |
Apr
(1) |
May
(15) |
Jun
(45) |
Jul
(71) |
Aug
(45) |
Sep
(52) |
Oct
(31) |
Nov
(20) |
Dec
(6) |
| 2008 |
Jan
(17) |
Feb
(25) |
Mar
(7) |
Apr
(5) |
May
(9) |
Jun
(3) |
Jul
(2) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
(2) |
Apr
(3) |
May
(1) |
Jun
(1) |
Jul
(15) |
Aug
(9) |
Sep
(10) |
Oct
(1) |
Nov
|
Dec
|
| 2010 |
Jan
(42) |
Feb
(28) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(3) |
Aug
(7) |
Sep
(19) |
Oct
(14) |
Nov
(27) |
Dec
(14) |
| 2011 |
Jan
(8) |
Feb
(9) |
Mar
(9) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(18) |
Sep
|
Oct
|
Nov
|
Dec
(6) |
| 2012 |
Jan
(5) |
Feb
(2) |
Mar
(2) |
Apr
|
May
|
Jun
(13) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(4) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(9) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: will <wi...@bl...> - 2009-09-10 23:01:36
|
Steve Hoelzer wrote: > > Umm, nope. This is wrong. That only applies to the categories and > doesn't check if date archives result in an identical path. > > The real fix is to use sorted(set(...)) on 'renderme' near the end of > runstaticrenderer(). The middle lines are new: > > print "building %s files." % len(renderme) > > # date archives and categories may give identical paths, so remove > duplicates > renderme = sorted(set(renderme)) > > for url, q in renderme: Nice! I tested it out and it looks good to me. Checked in as r1337. Thank you! /will |
|
From: will <wi...@bl...> - 2009-09-10 18:54:59
|
will wrote: > Steve Hoelzer wrote: >> Setting truncate_date to 1 or 0 didn't seem to have any effect for me. >> /2009/09/index.html is rendered with the 2nd and 3rd entries only. I >> expected to see all 3. > > Bah... It's a bug. I fixed it, but I screwed up my repository somehow, > so I have to fix that before I can check it in. I'll try to get to it > today. It's checked in now as r1334. To summarize, there are three truncate_* config variables which will affect how truncation works: truncate_date - whether or not date-based archives are truncated to num_entries. truncate_category - whether or not category-based archives are truncated to num_entries. truncate_frontpage - whether or not the front page is truncated to num_entries. I added the last one figuring someone's going to ask for it some day and I needed to add a check for the situation anyhow. I haven't updated the documentation, yet. /will |
|
From: will <wi...@bl...> - 2009-09-10 15:17:23
|
Steve Hoelzer wrote: > > I didn't know about that. It's not in the example config.py. It's a "new". I thought I wrote an email to pyblosxom-devel to see if the change satisfied the needs, but I can't find it. Regardless, it hasn't been documented yet except in the commit comments. > Setting truncate_date to 1 or 0 didn't seem to have any effect for me. > /2009/09/index.html is rendered with the 2nd and 3rd entries only. I > expected to see all 3. Bah... It's a bug. I fixed it, but I screwed up my repository somehow, so I have to fix that before I can check it in. I'll try to get to it today. /will |
|
From: Steve H. <sho...@gm...> - 2009-09-10 15:08:13
|
On Thu, Sep 10, 2009 at 9:03 AM, Steve Hoelzer <sho...@gm...> wrote:
> On Wed, Sep 9, 2009 at 4:23 PM, will <wi...@bl...> wrote:
>> Steve Hoelzer wrote:
>>> It also seems wasteful to render some pages twice (ex:
>>> /2009/index.html). It would be nice to detect the duplicates and get
>>> rid of them.
>>
>> If you can implement this, feel free to do so and send in a patch.
>
> I'm not sure if you care about the order that pages are rendered. If
> not, here's a simple solution. At the end of the "walk" function,
> instead of this:
>
> return _walk_internal(root, recurse, pattern, ignorere, return_folders)
>
> Use sorted(set(...)) like this:
>
> return sorted(set(_walk_internal(root, recurse, pattern, ignorere,
> return_folders)))
Umm, nope. This is wrong. That only applies to the categories and
doesn't check if date archives result in an identical path.
The real fix is to use sorted(set(...)) on 'renderme' near the end of
runstaticrenderer(). The middle lines are new:
print "building %s files." % len(renderme)
# date archives and categories may give identical paths, so remove
duplicates
renderme = sorted(set(renderme))
for url, q in renderme:
Steve
|
|
From: Steve H. <sho...@gm...> - 2009-09-10 14:11:24
|
On Thu, Sep 10, 2009 at 8:55 AM, will <wi...@bl...> wrote: > Steve Hoelzer wrote: >> >> I had three entries: >> >> /2009/09/firstpost.txt >> /2009/09/secondpost.txt >> /2009/09/thirdpost.txt >> >> And minor changes in config.py: >> >> py["num_entries"] = 2 >> py["static_monthnames"] = 0 >> py["static_monthnumbers"] = 1 >> >> Let me know if you need more info. > > Seems like you don't have truncate_date set. Add this: > > ["truncate_date"] = 1 I didn't know about that. It's not in the example config.py. Setting truncate_date to 1 or 0 didn't seem to have any effect for me. /2009/09/index.html is rendered with the 2nd and 3rd entries only. I expected to see all 3. Steve |
|
From: Steve H. <sho...@gm...> - 2009-09-10 14:03:33
|
On Wed, Sep 9, 2009 at 4:23 PM, will <wi...@bl...> wrote:
> Steve Hoelzer wrote:
>> It also seems wasteful to render some pages twice (ex:
>> /2009/index.html). It would be nice to detect the duplicates and get
>> rid of them.
>
> If you can implement this, feel free to do so and send in a patch.
I'm not sure if you care about the order that pages are rendered. If
not, here's a simple solution. At the end of the "walk" function,
instead of this:
return _walk_internal(root, recurse, pattern, ignorere, return_folders)
Use sorted(set(...)) like this:
return sorted(set(_walk_internal(root, recurse, pattern, ignorere,
return_folders)))
Or make it explicit:
result = _walk_internal(root, recurse, pattern, ignorere, return_folders)
result = sorted(set(result)) # remove duplicates from list
return result
Steve
|
|
From: will <wi...@bl...> - 2009-09-10 13:56:17
|
Steve Hoelzer wrote:
>
> I had three entries:
>
> /2009/09/firstpost.txt
> /2009/09/secondpost.txt
> /2009/09/thirdpost.txt
>
> And minor changes in config.py:
>
> py["num_entries"] = 2
> py["static_monthnames"] = 0
> py["static_monthnumbers"] = 1
>
> Let me know if you need more info.
Seems like you don't have truncate_date set. Add this:
["truncate_date"] = 1
/will
|
|
From: Steve H. <sho...@gm...> - 2009-09-10 04:19:50
|
On Wed, Sep 9, 2009 at 4:23 PM, will<wi...@bl...> wrote: > Steve Hoelzer wrote: >> >> On Fri, Jul 17, 2009 at 4:22 PM, Steve Hoelzer<sho...@gm...> wrote: >>> >>> On Fri, Jul 17, 2009 at 2:42 PM, will<wi...@bl...> wrote: >>>> >>>> Steve Hoelzer wrote: >>>>> >>>>> What I'd really like to do is organize my files in folders like: >>>>> /2009/Jul/17/filename. That would give me true permalinks and prevent >>>>> the duplicate slug problem. But doing this interferes with PyBlosxom's >>>>> date based archives, so it's not possible right now. >>>> >>>> Are you sure about that? I'm pretty sure we solved that issue a few >>>> versions ago. >>> >>> No, I'm not sure. I tried this a long time ago with PyBlosxom 1.4.1 (I >>> think) and it didn't work then. I'm still on 1.4.1 now but I'll >>> upgrade if this issue is fixed. If I get some time I'll experiment and >>> report back. >> >> I finally gave this a try and it does not work for me using the >> current trunk (r1333). I had a very simple test case with three >> entries in /2009/09/, py["num_entries"] = 2, and date archives with >> month numbers turned on. > > Can you show the relevant parts of your config.py file? I don't understand > how you have things set up. Alternatively, tar up your example and send it > to me so that I can reproduce what you're seeing. I had three entries: /2009/09/firstpost.txt /2009/09/secondpost.txt /2009/09/thirdpost.txt And minor changes in config.py: py["num_entries"] = 2 py["static_monthnames"] = 0 py["static_monthnumbers"] = 1 Let me know if you need more info. Steve |
|
From: will <wi...@bl...> - 2009-09-09 21:23:24
|
Steve Hoelzer wrote: > On Fri, Jul 17, 2009 at 4:22 PM, Steve Hoelzer<sho...@gm...> wrote: >> On Fri, Jul 17, 2009 at 2:42 PM, will<wi...@bl...> wrote: >>> Steve Hoelzer wrote: >>>> What I'd really like to do is organize my files in folders like: >>>> /2009/Jul/17/filename. That would give me true permalinks and prevent >>>> the duplicate slug problem. But doing this interferes with PyBlosxom's >>>> date based archives, so it's not possible right now. >>> Are you sure about that? I'm pretty sure we solved that issue a few >>> versions ago. >> No, I'm not sure. I tried this a long time ago with PyBlosxom 1.4.1 (I >> think) and it didn't work then. I'm still on 1.4.1 now but I'll >> upgrade if this issue is fixed. If I get some time I'll experiment and >> report back. > > I finally gave this a try and it does not work for me using the > current trunk (r1333). I had a very simple test case with three > entries in /2009/09/, py["num_entries"] = 2, and date archives with > month numbers turned on. Can you show the relevant parts of your config.py file? I don't understand how you have things set up. Alternatively, tar up your example and send it to me so that I can reproduce what you're seeing. > It also seems wasteful to render some pages twice (ex: > /2009/index.html). It would be nice to detect the duplicates and get > rid of them. If you can implement this, feel free to do so and send in a patch. /will |
|
From: Steve H. <sho...@gm...> - 2009-09-09 21:14:45
|
On Fri, Jul 17, 2009 at 4:22 PM, Steve Hoelzer<sho...@gm...> wrote: > On Fri, Jul 17, 2009 at 2:42 PM, will<wi...@bl...> wrote: >> Steve Hoelzer wrote: >>> >>> What I'd really like to do is organize my files in folders like: >>> /2009/Jul/17/filename. That would give me true permalinks and prevent >>> the duplicate slug problem. But doing this interferes with PyBlosxom's >>> date based archives, so it's not possible right now. >> >> Are you sure about that? I'm pretty sure we solved that issue a few >> versions ago. > > No, I'm not sure. I tried this a long time ago with PyBlosxom 1.4.1 (I > think) and it didn't work then. I'm still on 1.4.1 now but I'll > upgrade if this issue is fixed. If I get some time I'll experiment and > report back. I finally gave this a try and it does not work for me using the current trunk (r1333). I had a very simple test case with three entries in /2009/09/, py["num_entries"] = 2, and date archives with month numbers turned on. $ python pyblosxom-cmd staticrender pyblosxom-cmd version 1.5 dev Trying to import the config module.... Performing static rendering. rendering 3 entries. rendering 3 category indexes. rendering 3 date indexes. rendering 0 arbitrary urls. (before) building 9 files. building 9 files. rendering '/2009/09/firstpost.html' ... rendering '/2009/09/secondpost.html' ... rendering '/2009/09/thirdpost.html' ... rendering '/index.html' ... rendering '/2009/index.html' ... rendering '/2009/09/index.html' ... rendering '/2009/index.html' ... rendering '/2009/09/index.html' ... rendering '/2009/09/09/index.html' ... All of the index.html files contain the 2nd and 3rd post but not the first. Date based archives should not be limited by py["num_entries"]. It also seems wasteful to render some pages twice (ex: /2009/index.html). It would be nice to detect the duplicates and get rid of them. Steve |
|
From: seanh <sea...@gm...> - 2009-08-15 18:32:38
|
Is there a correct procedure for submitting something to the flavours or plugins registry? Just spied this simple Vessel theme and liked it so I translated it to PyBlosxom, just a very quick hack: http://github.com/seanh/PyBlosxom-vessel/ |
|
From: will <wi...@bl...> - 2009-08-11 18:55:17
|
Oh--my bad. I think that's a bug with PyBlosxom 1.4.3. Best to use what's in svn trunk or fix the code in PyBlosxomWSGIApp that's screwing up the blog.ini config variable overrides. /will seanh wrote: > I'm trying to get my blog setup so that I can preview locally with > paste and then publish to a server with either CGI or static > rendering. Most of the config.py settings are the same when previewing > and when published but a few crucial ones (base_url) are different. > The docs show how you can use blog.ini to override config.py settings, > but this doesn't seem to work. Setting the config.py directory in > blog.ini doesn't work either, when you run paste it always reads the > config.py file in the current working directory. |
|
From: seanh <sea...@gm...> - 2009-08-11 13:22:29
|
I'm trying to get my blog setup so that I can preview locally with paste and then publish to a server with either CGI or static rendering. Most of the config.py settings are the same when previewing and when published but a few crucial ones (base_url) are different. The docs show how you can use blog.ini to override config.py settings, but this doesn't seem to work. Setting the config.py directory in blog.ini doesn't work either, when you run paste it always reads the config.py file in the current working directory. |
|
From: seanh <sea...@gm...> - 2009-08-08 21:23:08
|
On Mon, Jul 20, 2009 at 2:51 PM, will<wi...@bl...> wrote: > seanh wrote: > Off the top of my head, I think there are a few ways you could solve the > moving categories problem: > > First is to use a version control system for keeping track of entries in > your blog. I think there are a couple out there already that use the > checkin time for the mtime for a file. If the version control system knows > about file moves, then you could write a plugin that checks the version > control system and provide the redirects. I actually use git to track the files in my blog already, although I don't integrate pyblosxom with git at all. What you suggest wouldn't work though, git doesn't always know when you move a file. If you both edit and move a file in the same commit and forget to use git mv, then often git records it as deleting the file and adding a new one. Ok, you could just not do this, it's bad behaviour, but I've been using VCS's to track my personal notes for years and I always do this sort of thing, so I know I can't rely on myself. I've had a change of heart about this whole issue after reading an article by Cory Doctorow about how he used tags to index a large collection of notes: http://www.locusmag.com/Perspectives/2009/05/cory-doctorow-extreme-geek.html (see 2. Research: Twitter meets notekeeping) I used to prefer pyblosxom categories over the tags plugin because they seemed more core to the pyblosxom way of doing things (use the filesystem). But now I think paths should be used as permalinks only, paths are what make sense as permalinks in pyblosxom and conversely permalinks are really all that paths are good for. As a means of organising and browsing your posts paths are really brittle and inflexible: permalinks break, a post can only be in one category at a time, the category views only show the first n posts in the category anyway (although I think this got fixed for 1.5). I've realised that tags are much better for categorising because they're so lightweight and flexible, the existing tag plugin works well, tag pages show all posts with the tag, they don't break permalinks when you change them, a post can have multiple tags. Tags, if you pay attention to them and use them carefully, let you build up an index of your site that facilitates a directed yet serendipitous browsing (to paraphrase Cory). But the problem with tags in pyblosxom (I've used them in the past) is that they can easily become a mess, you end up with multiple different tags for the same thing, often just slightly different spellings or something, posts with no tags, and lots of tags you barely use. So I think pyblosxom requires an additional utility to let you manage your tags with care. I've already written this script but never really put it to work, I'll have to dust if off to revive the tags for my notes, so I'll try to post the source when I do. It's a nearly trivial command-line program in python that walks your entries dir and can: * Print out a list of all your tags and the no. of posts each tag has, sorted by popularity or alphanumerically. * Print out all the posts that have a particular tag or tags (you could potentially allow AND, OR and NOT etc. but I don't know how useful that would be) * Print out all the tags that a particular post has * Rename a tag * Delete a tag * Split one tag into two * Join two tags into one All of these operations require reading all of the files in your entries dir, and the last few require modifying the #tags lines of lots of files (e.g. when I say rename a tag, I mean rename that tag in every entry file that it occurs in). This script is a standalone module not technically a pyblosxom plugin, and it's independent of the tags plugin, but it occurs to me that the two could probably share much of their code. |
|
From: Terry B. <ter...@ya...> - 2009-08-03 19:34:35
|
On Mon, 3 Aug 2009 14:05:32 -0500 Terry Brown <ter...@ya...> wrote: > Should the rst plugin work in 1.5? I'm wondering if the preformatter > setup has changed. I'm not even seeing it get a .pyc file. Doh, never mind, my mistake. (a) py["load_plugins"] = [] was preventing plugins loading (b) I didn't realize when rst did start working because <pre/> wasn't styled differently from plain text, at least not very differently. |
|
From: Terry B. <ter...@ya...> - 2009-08-03 19:06:30
|
Hi, Should the rst plugin work in 1.5? I'm wondering if the preformatter setup has changed. I'm not even seeing it get a .pyc file. Thanks, Terry |
|
From: will <wi...@bl...> - 2009-08-03 17:50:40
|
With PyBlosxom 1.5 (I really should just release what I have as a
release candidate or something--my apologies), starting a new blog is a
one-liner:
% pyblosxom-cmd create ./blog
That generates a basic folder structure, a config.py file, a
pyblosxom.cgi file and a blog.ini file. The blog.ini file is used by
Paste. So after doing the above line, you can do:
% cd ./blog
% paster serve blog.ini
and your blog is running locally with Paste. Previous versions of
PyBlosxom have bits of this, but it's much easier with 1.5.
Under the hood, Paste is using the PyBlosxomWSGIApp class in
Pyblosxom/pyblosxom.py . Writing a basic local server should be pretty
easy. If you're interested, send in a patch based on trunk. I know
Python 2.6 has a wsgiref module that has a make_server function that
should make it really easy.
In regards to adding draft-based functionality, I'm resistant to adding
more functionality to PyBlosxom. I'm sure there are great reasons for
adding feature x to PyBlosxom, but at a bare minimum, it should be
tested out with plugins first.
I'm a +1 on people sending in documents on "my blog does xyz and this is
how I set it up". I'd love to add these "setup recipes" to the
documentation. If anyone is interested in writing a "setup recipe", let
me know.
/will
seanh wrote:
>> Oh, don't set up a local Apache server--that's pretty intense. Using Paste
>> will allow you to run PyBlosxom locally. That's what I use.
>
> Thanks. I got paste working. So with this I can preview my drafts
> locally before pushing them to my server, and on the server I can use
> either static rendering or CGI.
>
> It might be cool if pyblosxom shipped with paste integrated, so that
> instead of having to configure and install everything I could just run
> a simple command like pyblosxom --server and it would run my blog in
> paste.
>
> So here are some use-cases related to drafting, there are loads of
> ways you could do this:
>
> 1. Write drafts locally, preview them with paste, run static
> rendering and publish the static HTML to a server.
>
> 2. As 1 but push the raw text files to the server and let the server
> do the static rendering (e.g. run static rendering as a post-commit or
> post-sync hook on the server).
>
> 3. As 2 but run pyblosxom on the server in CGI mode, no server-side
> hook needed.
>
> 4. Don't have pyblosxom installed locally, run it in CGI mode on the
> server, use the accidental drafts category behaviour to preview
> drafts.
>
> 5. Don't have pyblosxom installed locally. Run it in static rendering
> mode on the server. Have a separate config.py for drafts that uses the
> drafts dir as the datadir and statically renders to an htaccess
> protected drafts dir.
>
> All in all, I think it can be done one way or another in almost any
> situation, but I think it would be nice if drafting were more
> integrated into pyblosxom to make it less awkward.
|
|
From: seanh <sea...@gm...> - 2009-08-03 16:31:13
|
> Oh, don't set up a local Apache server--that's pretty intense. Using Paste > will allow you to run PyBlosxom locally. That's what I use. Thanks. I got paste working. So with this I can preview my drafts locally before pushing them to my server, and on the server I can use either static rendering or CGI. It might be cool if pyblosxom shipped with paste integrated, so that instead of having to configure and install everything I could just run a simple command like pyblosxom --server and it would run my blog in paste. So here are some use-cases related to drafting, there are loads of ways you could do this: 1. Write drafts locally, preview them with paste, run static rendering and publish the static HTML to a server. 2. As 1 but push the raw text files to the server and let the server do the static rendering (e.g. run static rendering as a post-commit or post-sync hook on the server). 3. As 2 but run pyblosxom on the server in CGI mode, no server-side hook needed. 4. Don't have pyblosxom installed locally, run it in CGI mode on the server, use the accidental drafts category behaviour to preview drafts. 5. Don't have pyblosxom installed locally. Run it in static rendering mode on the server. Have a separate config.py for drafts that uses the drafts dir as the datadir and statically renders to an htaccess protected drafts dir. All in all, I think it can be done one way or another in almost any situation, but I think it would be nice if drafting were more integrated into pyblosxom to make it less awkward. |
|
From: seanh <sea...@gm...> - 2009-08-01 15:14:56
|
Hmm. Actually I have a script that reads the current X selection, transforms it with python-markdown, writes the HTML to a temporary file and then opens the file in a web browser. If you bind it to a keyboard shortcut or something like that it's very quick, in any editor just do ctrl-a to select all text and then run this preview script. Limitations are that it doesn't use the same layout and CSS as your pyblosxom blog, and the title and metadata lines at the top get rendered wrong. I could hack around these I suppose. It seems like something more integrated with pyblosxom itself would be better. On Fri, Jul 31, 2009 at 9:02 PM, Edgar Luna<edg...@gm...> wrote: > Hi > > On Fri, Jul 31, 2009 at 2:43 PM, will<wi...@bl...> wrote: >> seanh wrote: >>> Is there a better workflow when you want to preview a post before >>> publishing it, or is pushing it to your web server and using this >>> drafts thing in CGI mode the best approach? >> >> I don't preview my posts. >> >> Does anyone preview their posts that have a workflow they'd like to share? >> >> > > I use markdown for formatting and emacs for editing so markdown mode > does that for me. Of course that is a partial preview of the content. > But works for me. > > -- > Edgar Luna > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > pyblosxom-users mailing list > pyb...@li... > https://lists.sourceforge.net/lists/listinfo/pyblosxom-users > |
|
From: Edgar L. <edg...@gm...> - 2009-07-31 20:02:38
|
Hi On Fri, Jul 31, 2009 at 2:43 PM, will<wi...@bl...> wrote: > seanh wrote: >> Is there a better workflow when you want to preview a post before >> publishing it, or is pushing it to your web server and using this >> drafts thing in CGI mode the best approach? > > I don't preview my posts. > > Does anyone preview their posts that have a workflow they'd like to share? > > I use markdown for formatting and emacs for editing so markdown mode does that for me. Of course that is a partial preview of the content. But works for me. -- Edgar Luna |
|
From: will <wi...@bl...> - 2009-07-31 19:43:49
|
seanh wrote: > Is there a better workflow when you want to preview a post before > publishing it, or is pushing it to your web server and using this > drafts thing in CGI mode the best approach? I don't preview my posts. Does anyone preview their posts that have a workflow they'd like to share? > The only other way I can think to do it is to run a local apache > server with pyblosxom installed for previewing and push the content to > your remote server when it's done. Oh, don't set up a local Apache server--that's pretty intense. Using Paste will allow you to run PyBlosxom locally. That's what I use. /will |
|
From: seanh <sea...@gm...> - 2009-07-31 19:31:34
|
Is there a better workflow when you want to preview a post before publishing it, or is pushing it to your web server and using this drafts thing in CGI mode the best approach? The only other way I can think to do it is to run a local apache server with pyblosxom installed for previewing and push the content to your remote server when it's done. On Fri, Jul 31, 2009 at 2:02 PM, will<wi...@bl...> wrote: > I think the answer here is that I didn't intend this behavior explicitly, > but it sounds ok to me. Static rendering shouldn't behave like web > rendering does. Amongst other things, it builds a static, final, public > site--it's not designed for allowing you to preview and such locally. > Writing a plugin to allow that is probably possible, but I think the > workflow is messy. > > As a side note, I don't think ignore_directories was implemented for the > purpose of drafts, but I don't remember what the primary use case was. It's > probably somewhere in the mailing list archives, I would imagine. > > /will > > > seanh wrote: >> >> I was just messing around and noticed that if I put: >> >> py["ignore_directories"] = ['drafts'] >> >> and then visit the drafts category manually (by hacking the URL), and >> I'm using pyblosxom in CGI mode, it will show me all my drafts. >> They're missing from all the indexes (front page, date-based views) >> but they show up if you visit the category directly. I don't know if >> the category would show up in the list of categories because I don't >> use that plugin. Is this the intended behaviour of ignore_directories? >> >> In static rendering mode it's different, the drafts category doesn't >> get rendered at all and you can't visit it. I got it to render an >> index view of the drafts category by adding: >> >> py["static_urls"] = ["/drafts/"] >> >> but this just renders the category index page, it doesn't render the >> pages for the posts themselves. >> >> I sort of liked that the drafts category was browsable because it >> meant I could preview my drafts, and if I wanted to keep them private >> I could always put an htaccess file. >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day trial. Simplify your report design, integration and deployment - and >> focus on what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> pyblosxom-users mailing list >> pyb...@li... >> https://lists.sourceforge.net/lists/listinfo/pyblosxom-users >> > |
|
From: will <wi...@bl...> - 2009-07-31 13:22:25
|
I think the answer here is that I didn't intend this behavior explicitly, but it sounds ok to me. Static rendering shouldn't behave like web rendering does. Amongst other things, it builds a static, final, public site--it's not designed for allowing you to preview and such locally. Writing a plugin to allow that is probably possible, but I think the workflow is messy. As a side note, I don't think ignore_directories was implemented for the purpose of drafts, but I don't remember what the primary use case was. It's probably somewhere in the mailing list archives, I would imagine. /will seanh wrote: > I was just messing around and noticed that if I put: > > py["ignore_directories"] = ['drafts'] > > and then visit the drafts category manually (by hacking the URL), and > I'm using pyblosxom in CGI mode, it will show me all my drafts. > They're missing from all the indexes (front page, date-based views) > but they show up if you visit the category directly. I don't know if > the category would show up in the list of categories because I don't > use that plugin. Is this the intended behaviour of ignore_directories? > > In static rendering mode it's different, the drafts category doesn't > get rendered at all and you can't visit it. I got it to render an > index view of the drafts category by adding: > > py["static_urls"] = ["/drafts/"] > > but this just renders the category index page, it doesn't render the > pages for the posts themselves. > > I sort of liked that the drafts category was browsable because it > meant I could preview my drafts, and if I wanted to keep them private > I could always put an htaccess file. > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > pyblosxom-users mailing list > pyb...@li... > https://lists.sourceforge.net/lists/listinfo/pyblosxom-users > |
|
From: seanh <sea...@gm...> - 2009-07-31 03:14:06
|
I was just messing around and noticed that if I put:
py["ignore_directories"] = ['drafts']
and then visit the drafts category manually (by hacking the URL), and
I'm using pyblosxom in CGI mode, it will show me all my drafts.
They're missing from all the indexes (front page, date-based views)
but they show up if you visit the category directly. I don't know if
the category would show up in the list of categories because I don't
use that plugin. Is this the intended behaviour of ignore_directories?
In static rendering mode it's different, the drafts category doesn't
get rendered at all and you can't visit it. I got it to render an
index view of the drafts category by adding:
py["static_urls"] = ["/drafts/"]
but this just renders the category index page, it doesn't render the
pages for the posts themselves.
I sort of liked that the drafts category was browsable because it
meant I could preview my drafts, and if I wanted to keep them private
I could always put an htaccess file.
|
|
From: will <wi...@bl...> - 2009-07-20 13:51:19
|
seanh wrote: > On Mon, Jul 20, 2009 at 2:11 PM, seanh<sea...@gm...> wrote: >> I dunno, feels inelegant. Perhaps keeping categories fixed is better. > > I noticed that in wordpress if you change the unique slug of a post > and then visit the old slug you get re-directed to the new one. I > wonder if you could do something like that in pyblosxom? Use > categories+filename as permalinks but if you move a post leave a file > behind with an HTML redirect in it. Off the top of my head, I think there are a few ways you could solve the moving categories problem: First is to use a version control system for keeping track of entries in your blog. I think there are a couple out there already that use the checkin time for the mtime for a file. If the version control system knows about file moves, then you could write a plugin that checks the version control system and provide the redirects. Second is to write a shell script that moves a post from one category to another and make sure you only use that shell script for moving posts. It'd move the post but also add an entry to some redirect-index file. Then write a plugin to check that file for redirects and provide as needed. You mentioned the problem where moving a file a few times provides multiple redirects, but I think you could squash multiple moves into one move in the plugin without having to do multiple redirects. Alternatively, I think it's probably easier in the long run to give each entry a unique identifier and use the unique identifiers as the permalink. Then you have a cron job that compiles all the unique identifiers into an index file that's read by a plugin whenever a permalink slug is requested. Maybe hashing the original category/filename/title is a good unique identifier? So long as you store it in the metadata of the entry and it stays the same, it probably doesn't matter what the original composing criteria is. /will |
38 messages has been excluded from this view by a project administrator.
