Sometimes it's useful to know the exact time a post was made to LJ, especially on your flist. Here's a snippet of code to show the date & time in GMT that the server recorded when the post was made.

( Read more... )

This is code for when you have a lot of tag tiers, with long names, and you want to use a lot of abbreviations in the tags themselves, but have the Tags Page and sidebar tags box show the full tier names. This code also includes internal anchors to the first and second level tiers, and prints above the tiered list some menu links that point to those anchors. All top level tiers are in one group, and then you can customize which second level tiers you would like to have menu links for. Each second level tier you select will have its own group of links.

( Code )

Show the Recent Entries page in more of an index style, with just excerpts of the entry text, not full entries, but only when viewing a tag subset of the entries.

Paste this function into your theme layer, altering the blue configuration variables to suit you.

( Code )

I released a new version of the Flexible Squares Multilevel Tags tutorial, which is quite different from the now obsolete original. Besides the addition of actual instructions, the code itself underwent some changes. They are detailed here in red comments for any interested parties.

( Code )

For wistfuljane!

Adapted from my earlier versions for Flexible Squares (s2flexisquares tutorial) and Component (component_help tutorial).

This is code to display your tags in a sidebar box. By naming your tags using a delimiter, for example animals:cats:tabbies or animals:cats:siamese, where the colon is the delimiter, you can display a heirarchical list of tags.

( Instructions )

Edit 2006-06-28: Posted to suggestions. Let the ridicule begin. (Well, if it makes it past the maintainers.)

I made a post in lj_style the other day to find out whether other people think the current behaviour of entries with disabled comment posting is logically flawed. It was suggested that I take it to suggestions, and since that's rather a public forum, I thought I'd draft it here first so that people can do a little criticizing and I can do a little tweaking, hopefully lessening my chances of being slaughtered when I post over there. So comments much appreciated!

Title

Do not hide pre-existing comments when disabling comment posting

Short, concise description of the idea

Right now, if you disable comment posting on an entry, none of the comments are shown when you view that entry in the bml entry page (aka simple comment page) and in many S2 layout entry pages. The entry looks like it never received any comments, even if prior to the disabling it had received many.

I propose that entries that have had comment posting disabled should still display all the comments that were made prior to the disabling.

Full description of the idea

Entries that have had comment posting disabled should still display all the comments that were made prior to the disabling. Current behaviour is to hide all comments once comment posting is disabled.

This is odd behaviour that has some problems. First, it isn't really logical. The comments still exist, and when you decide to disable comment posting, you don't necessarily want to prevent people from reading existing comments, you may simply not want to receive any more responses. The assumption cannot really be made that everyone who disables comment posting also wants to hide all existing comments. Those are two separate actions. In fact, the second of those actions is generally done through comment screening.

Second, it is misleading. Right now, it is easy for people to assume that disabling comments is like screening comments, since the comments are not visible in most views; however, there are several S2 layouts (Bloggish, Dear Diary, Quite Lickable, Smooth Sailing, s1short) that display comments even on entries that have disabled comment posting. So if you switch your style to one of those, you can view the entry with style=mine and reveal all comments. Additionally, with a little bit of S2 knowledge and a paid account, you can edit any existing layout to make it mimic that same behaviour. This comment hiding is not really screening at all, and as such it is dangerously misleading. Post authors may assume that they've hidden comments from everyone, but there will still be people out there who can read them all.

When you come right down to it, disabling comments on a post is very like freezing a comment thread -- you are preventing the addition of any more replies. It should not have any kind of screening component, since that is a separate action entirely. If you want to hide comments, you should be screening them -- that's what screening is for.

An ordered list of benefits

1. Disabling comment posting will have the more logical result of doing only that one thing, with no additional side effects.

2. There will be more consistent behaviour between bml entry pages and custom S2 entry pages, as well as more consistent behaviour among the various S2 styles.

3. People will no longer be misled into thinking that disabling comments is a secure way of hiding comments from view.

An ordered list of problems/issues involved

1. I have been told that the original reason for this behaviour might be related to S1. In S1 you must show the post and read comments links together or not at all -- you cannot remove the post link without also removing the read link. Since disabling comments required removing the post link, then the read link had to go, too, and accordingly the comments were hidden on the entry page. To me, this seems like we are now catering to a flaw in S1 that really ought to be fixed, but I know very little about the workings of S1, so I'm not sure how feasible it would be to solve that. It may be that the only way to resolve this in S1 is to always show the read and post link whenever there are comments on a post, regardless of whether comment posting has been disabled, and then when someone clicks the post link, they are given an error message that comments have been disabled.

2. The usual issue exists, of course, of having someone go in and make all the necessary code changes.

3. It's possible that some people may be upset by:

a) Whatever is done to solve the S1 problem.
b) The new behaviour, since they are used to having comments be invisible (to *most*) when comment posting is disabled.

An organized list, or a few short paragraphs detailing suggestions for implementation

1. On the entry bml page, show any existing comments even when comment posting has been disabled. Likely will require quite a few modifications to the comment display and reply link logic.

2. In the S2 code, change the logic for setting the show_readlink variable so that it is set to true when public comments exist or when the viewer can see any screened comments -- remove the condition that comments must be enabled.

3. In the S2 system layouts, ensure that all the layouts use the show_readlink and show_postlink variables to determine when to show the read and post comment links, and also ensure that in the code for the custom entry pages the comments get displayed even when commenting has been disabled.

4. Deal with the S1 read and post links in some way.

A tutorial for adding smilie images to entries and comments in Flexible Squares. Posted to s2flexisquares: [paid accounts] Smilies in Posts and Comments.

This code is currently a disaster, but it does seem to sort of work (always a challenge for me when I'm tossing around nested arrays). It's still full of clumsy debugging stuff, even, but I wanted to post it before I accidentally delete the layer. Basically allows you to specify a sort order for any levels of a multi-level tag list. Any levels that aren't specified in the custom sort order fall into alphabetical order after the custom sorted levels. Lord knows who would ever want to do this, but maybe one day someone will ask, and then at least I'll have some code to work with.

( Ugly, ugly code )

Urg. Second attempt. Allows for sorting of second level tags as well, which I think was todeskun's actual s2flexisquares request. See how I miss the obvious. Again, is this code any good? I honestly can't tell anymore. One thing I do know: it's horrendously long.

( Code )

Am I crazy or does trying to declare a function that accepts an argument of type bool{} or bool[] always cause a compilation error?

ETA: No! Not crazy. Ticket #936.