dw_suggestions | Entries tagged with site: documentation

Title:
Create Entries beta : help button for HTML and Markdown

Area:
entries

Summary:
I suggest adding a help button (i) or link to help us with editing. If you have forgotten which HTML tags are allowed or how to write something in Markdown, you're currently out of luck on the beta page. There is not 'help with editing' link anywhere. I think it would be nice to have one (or two; one for HTML and one for Markdown).

Description:
A help panel we could switch to and from from without leaving the page would be awesome but links to the following in new tabs/windows would be great too:

http://www.dreamwidth.org/support/faqbrowse?faqid=82 (What Dreamwidth-specific markup/HTML tags can I use?)

http://www.dreamwidth.org/support/faqbrowse?faqid=260 (How can I use Markdown to format my entries?)

http://daringfireball.net/projects/markdown/syntax (Markdown formatting and syntax)

http://www.dreamwidth.org/support/faqbrowse?faqid=103 (What HTML can I use in my entry?)

Poll #18017 Create Entries beta : help button for HTML and Markdown

Open to: Registered Users, detailed results viewable to: All, participants: 44

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
36 (81.8%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
8 (18.2%)

(Other: please comment)
0 (0.0%)

marahmarie

Title:
Add complete pre-filled custom s2 template for beginners on the Wiki.

Area:
Styles

Summary:
Add a complete, pre-filled custom s2 template on the Wiki for Dreamwidth s2 beginners that anyone can edit to add more example code as desired, to help users help themselves to more customized code without necessarily having to ask for help in one of the style communities or hunt down the exact page containing the code they want in the Wiki.

Description:
Ever wonder how to add something not given to you out of the box on your Dreamwidth journal, like an extra row of links in your DW's header or a second custom text box in your sidebar? So have I. The answer is you need a custom theme layer to add Dreamwidth's s2 code to - and you need to know or else figure out the right chunks of s2 code to add to it. By adding the right chunks of code you can make different things on your journal like the extra custom text box or basically almost anything that won't automatically be stripped out by the s2 compiler.

For the most part, if I have a question about how to write the correct code to pull off one of my latest ideas, I'll ask for expert help over in our style_system community and most of the time I'll receive excellent answers and help with all of the code wrangling needed. But not everyone is willing to wait on asking others for help and/or learning to any extent how the code works (or why it doesn't); they just want the shiny and to teach themselves the code for it (or ask for help in learning it) as they go along - maybe later, or maybe never.

The question in one's mind at this juncture may be, "Why should there be this big code hurdle for me to jump just to get at some of the shiny"?

So my suggestion toward this is based on our s2 Cookbook which is kept here: http://wiki.dwscoalition.org/wiki/index.php/S2_Cookbook

My idea is to keep the separate pages we already have on the wiki for adding modules (http://wiki.dwscoalition.org/wiki/index.php/S2_Cookbook:_Modules), making the heading work as a link (http://wiki.dwscoalition.org/wiki/index.php/S2_Cookbook:_Linking_the_title_on_your_journal_to_your_main_journal_page) and so on, and to add more pages for other similar functions as needed, but to also add a new page that shows all of that code and more working together at once, starting from the opening lines (which are generally something like, "layerinfo "type" = "theme"; layerinfo "name" = "layer name";") for a sort of One Stop Shop where you can choose which bits of code you want for what or compile the entire thing to see how it all works and looks together at once.

With the code properly commented, it will be easy to see if any part of the code does what you need it to do and by reading the code under each comment you might get a sense of how it's doing what it does. For anything beyond that you can always still ask in the style communities for extra help.

Maybe this new Wiki page could be called "All known custom s2 functions adapted by our users - on one page!" and could be found under the "S2 Cookbook: Other Examples" heading, and be clearly marked as an example of how much each journal can be modified to do more interesting things and offer more interesting features. Anyone could contribute to it, so say if you learned in one of the style communities how to add extra previous and next links beyond what a standard DW offers out of the box (http://style-system.dreamwidth.org/108697.html), you could add the finalized code on that page to this new Wiki (besides giving it its own page on the Wiki like a few other functions already have) so others can see it as part of a complete example custom theme layer.

Poll #16807 Add complete pre-filled custom s2 template for beginners on the Wiki.

Open to: Registered Users, detailed results viewable to: All, participants: 24

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
14 (58.3%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
9 (37.5%)

(Other: please comment)
1 (4.2%)

pauamma

Title:
Merge full FAQ search form into FAQ list

Area:
User documentation

Summary:
Add a language field to http://www.dreamwidth.org/support/faq (like http://www.dreamwidth.org/support/faqsearch has) and redirect http://www.dreamwidth.org/support/faqsearch into http://www.dreamwidth.org/support/faq.

Description:
There's no real reason to have a separate search form since there's ample space for the one missing field (FAQ language), and the complete form isn't linked from the simplified one, meaning the only way to find it is through the sitemap. Then, the site map should be updated to merge the 2 items, and likewise for any applicable menus. (I can't use them because they don't work for me, so I don't know what's in them.)

Alternatively, there should be a link to the complete search form from the FAQ list (but since thw in-index search was added to avoid that, that's a markedly poorer solution.)

Poll #11271 Merge full FAQ search form into FAQ list

Open to: Registered Users, detailed results viewable to: All, participants: 41

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
19 (46.3%)

Should be implemented with changes. (please comment)
4 (9.8%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
18 (43.9%)

(Other: please comment)
0 (0.0%)

ninetydegrees

Title:
Support: widen the 'Reference FAQ' drop-down menu

Area:
support

Summary:
When you answer a support request, you have the possibility to reference a FAQ. To help you do this, there is a drop down menu listing all the existing FAQs. Some FAQs have long titles and the menu truncates them. I suggest it be made a little wider to make it easier to find the correct FAQ.

Description:
Maybe 25 characters longer.

Poll #9855 Support: widen the 'Reference FAQ' drop-down menu

Open to: Registered Users, detailed results viewable to: All, participants: 53

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
37 (69.8%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
16 (30.2%)

(Other: please comment)
0 (0.0%)

thnidu

Title:
make list of allowable HTML easier to get to

Area:
entries and comments

Summary:
Make it easier for the user to see what HTML tags are OK to use, *while they are writing or editing a post or comment*.

Description:
In order to check "can I use this HTML tag?" or "What's the name of that tag again?", a user who is composing or editing a post can scroll down to the list given below the post... unless it's a DW-specific tag. For that, they have to (as far as I can tell)
1. open up their home page in a new tab
2. click on "Help/FAQ"
3. open one of three different pages listed there (here in the order they appear in):
- a. What Dreamwidth-specific markup/HTML tags can I use? (a short list of those three tags, with links to further information about them such as available attribute)
- b. What HTML tags can I use on Dreamwidth? (a list with detailed examples)
- c. What HTML can I use in my entry? (a simple compact list of the allowed HTML tags, plus a link to page "a" above (Dreamwidth-specific markup/HTML tags)

Two suggestions:
1. After the list of general HTML tags that you have below the composition pane for a *post*, add a list of DW's local HTML tags, with something like "Dreamwidth-specific tags:".
2. Also,
- Make a separate page with those two lists -- not just allowable general HTML and a link the user has to follow to see the DW-specific list. Include
-- the "learn more" links that you already have on "What Dreamwidth-specific markup/HTML tags can I use?",
-- and a link to the detailed list with examples that is "What HTML tags can I use on Dreamwidth?"
- Put a link to that page in the *Reply* area, maybe under the composition pane just to the right of "Check spelling during preview", something like this: [Allowable HTML]. The link should open on a separate page.

I've been hand-coding HTML for decades, but even so I appreciate having a list of the HTML that DW accepts at the bottom of the entry window. And I would appreciate even more having an easily accessible list of your site-specific HTML tags, which I often do not remember; for example, exactly how to add a userhead and link to the name of a user on another site.

Poll #9373 make list of allowable HTML easier to get to

Open to: Registered Users, detailed results viewable to: All, participants: 68

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
57 (83.8%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
11 (16.2%)

(Other: please comment)
0 (0.0%)

thnidu

Title:
"Delete all" should not be option in inbox subfolders

Area:
inbox interface

Summary:
It's not clear to me whether the "... All" buttons in Inbox subfolders such as "unread" apply only to the messages in that folder, or to all messages, and I'm not about to test it.

Description:
When I go to my inbox and click on any of the subfolders, such as "New People" or "Unread" (see req. #12097), I still have the "mark all read" and "delete all" buttons at the top and bottom of the list.

Do these really affect *all messages*, or just the ones in the current subfolder? If the latter, I urge you to relabel them, e.g. "Delete all these" and "Mark all these read", to make it clear that they do not apply to ALL the messages.

Poll #9056 "Delete all" should not be option in inbox subfolders

Open to: Registered Users, detailed results viewable to: All, participants: 51

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
24 (47.1%)

Should be implemented with changes. (please comment)
8 (15.7%)

Shouldn't be implemented.
2 (3.9%)

(I have no opinion)
17 (33.3%)

(Other: please comment)
0 (0.0%)

thnidu

Title:
Make the tag "security" label useful, or remove, or at least explain it

Area:
tags

Summary:
The "security" label on the tag management page is (1) redundant and (2) misleading. (1) It is simply the lowest level (highest line on the chart right above it) that applies to any post tagged with it. (2) By being there at all, it suggests that it is useful, e.g., a settable value for "who can see this tag".

Description:
See Request #12096, under "Site Interface". I asked about the tag, and was told
"Tag security is tied to entry security. If the posts used for those tags are public, then the tags will also be public."

My reply:

So, if I use a tag only for filtered posts, the page for that tag will say "Security: filtered". But the first time I use it for a public post, the "security" level will change to "public". In other words, it's exactly equal to the label on the lowest security level (highest line on the list just above it) with a non-zero count.

The screen is deceptive. Giving a "security" level for the tag strongly implies that there is a security level ASSOCIATED SPECIFICALLY with the tag, and that it can be set somehow. I've been assuming I can set security for any post independent of any other post and any other setting. This "security" field is not only useless -- totally redundant with the list above it -- but misleading as well. Either

1. make it meaningful -- e.g., by letting the user set "who can see this tag" (I may not WANT everyone to know that I've tagged a particular post as "love life", or that I have such a tag!)
2. or rename it, e.g., "lowest security level of posts with this tag", or something shorter that says the same thing, if you can think of a wording
3. or remove it entirely.

Is the meaning of this field described anywhere online? Unless you follow option 3, there should at least be a link on the "security" label to explain it.

My preference is #1. I know that would take more work than #2 (+ the info link), but that would be adding something useful.

Poll #9006 Make the tag "security" label useful, or remove, or at least explain it

Open to: Registered Users, detailed results viewable to: All, participants: 65

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
28 (43.1%)

Should be implemented with changes. (please comment)
8 (12.3%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
28 (43.1%)

(Other: please comment)
1 (1.5%)

ninetydegrees

Title:
Index page for ways to filter a page

Area:
usability, recent page, reading page

Summary:
Create /index or /filter pages for recent and reading pages which list all the ways you can filter them, give example URLs or link to existing pages when necessary (and, of course, hide them from viewers if they're supposed to be private).

Description:
You can currently filter recent pages by year, month, day, tag, and/or tag combos, poster, security level and also group and type of account for reading pages, and sometimes even a combination of several filters. It's getting hard to remember what all the possibilities and their URL formats are.

This is inspired by at least two great suggestions: http://dw-suggestions.dreamwidth.org/545274.html and http://dw-suggestions.dreamwidth.org/33097.html.

Poll #7084 Index page for ways to filter a page

Open to: Registered Users, detailed results viewable to: All, participants: 60

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
53 (88.3%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (11.7%)

(Other: please comment)
0 (0.0%)

noracharles

Title:
Add privacy warning to faq about forwarding email from your username@dreamwidth.org address

Area:
privacy

Summary:
In the faq (http://www.dreamwidth.org/support/faqbrowse?faqid=196&q=forwarding&lang=) it is implied that forwarding email is a privacy concern, but it's not explained why. I would like a sentence added explaining that doing so may reveal that address to other users.

Description:
This is one of those things where a moment's thought will tell you the answer, but I didn't think, and other users may also be ignorant about the risk:

Don't forward your username@dreamwidth.org mail to an email address you do not wish connected to your pseud, because if it bounces, the person who emailed you will get an auto-reply containing the private email address.

I learned the real life name of a fandom friend this way.

Poll #3745 Add privacy warning to faq about forwarding email from your username@dreamwidth.org address

Open to: Registered Users, detailed results viewable to: All, participants: 47

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
47 (100.0%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
0 (0.0%)

(Other: please comment)
0 (0.0%)

ninetydegrees

Title:
Styles: Add links to Your Layers

Area:
styles

Summary:
Add links to Public Layers and S2 Doc to Your Layers so that you don't always have to go back to Advanced to get to these.

Description:
BTW, it would be nice if S2 Doc could now encompass the Wiki pages dealing with S2 (I know it's a big WIP but it already has very useful info) or even be replaced by http://wiki.dwscoalition.org/notes/S2_Guide:_Table_of_Contents.

Poll #3536 Styles: Add links to Your Layers

Open to: Registered Users, detailed results viewable to: All, participants: 27

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
13 (48.1%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
14 (51.9%)

(Other: please comment)
0 (0.0%)

zarhooie

Title:
Remove the phrase "I hope you enjoy it" from the Tell A Friend feature

Area:
Tell A Friend

Summary:
The phrase "I hope you enjoy it" is superfluous and should be removed from the Tell A Friend page.

Description:
Let us take a temporary stroll down It Could Happen Lane. I would like to tell my friend Y about an entry that I think would make her angry due to sheer stupidity contained therein. I make use of the thoughtfully-provided feature Tell A Friend (http://www.dreamwidth.org/tools/tellafriend), and compose my own note to her, saying "This will make you angry but you need to read it." The automatically appended phrase "I hope you enjoy it" does not make any sense at all in this context.

Therefore, I would like to suggest that it be removed. This will make this feature more appropriate to a variety of purposes and also will cease to annoy me quite as much.

I can not see any immediate drawbacks, as a sending user can write their own note of "I hope you enjoy it" in the custom text area. Advantages are mentioned above.

Poll #1794 Remove the phrase "I hope you enjoy it" from the Tell A Friend feature

Open to: Registered Users, detailed results viewable to: All, participants: 60

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
54 (90.0%)

Should be implemented with changes. (please comment)
2 (3.3%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
3 (5.0%)

(Other: please comment)
1 (1.7%)

azurelunatic

Title:
Improve comment title admonishment about HTML

Area:
comments, site copy

Summary:
Change comment subject warning from "HTML isn't allowed here" to "HTML doesn't work here".

Description:
The comment subject has a little warning that appears the instant you type '<' (but not the instant you type '<', it turns out), telling you that HTML isn't allowed here.

"Isn't allowed" makes me think that there is validation logic that will either strip it or hold the comment without posting until I fix it.

"Doesn't work" tells me that the site will allow me to type anything my fool head can think up, it just won't do anything with it.

To a non-technical user, "doesn't work" might also be more friendly.

Poll #1793 Improve comment title admonishment about HTML

Open to: Registered Users, detailed results viewable to: All, participants: 44

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
34 (77.3%)

Should be implemented with changes. (please comment)
1 (2.3%)

Shouldn't be implemented.
1 (2.3%)

(I have no opinion)
8 (18.2%)

(Other: please comment)
0 (0.0%)

zvi

Title:
Post diffs of style changes right before a code push

Area:
styles, communications, codepushes

Summary:
The styles team is working to improve the CSS for official styles all the time. Sometimes people like the unimproved style or their customizations are based on the imperfections. We should give people more info so they can fix their customizations after code pushes.

Description:
Specifically, when a code push is going live, there should be an entry on DW-styles that explains what changes are being made to any layouts or themes. Calling it a diff is a bit of a misnomer, because I think it should include more info than that, i.e.

1) The old code
2) The new code
3) A plain English explanation of what both sets of code do, and the problem being solved by changing the code.
4) The custom CSS/changed wizard settings required to get the old behavior back on the default layout and theme.

Drawbacks: This will require more work on the part of the styles team and more warning from The Bosses that a code push is coming than is now the custom. People will still be unhappy that we're making them make a change instead of offering two versions of the code and putting them on the unchanged version.

Poll #1537 Post diffs of style changes right before a code push

Open to: Registered Users, detailed results viewable to: All, participants: 21

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
16 (76.2%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (23.8%)

(Other: please comment)
0 (0.0%)

melannen

Title:
Content warning cuts on reading list

Area:
Adult content warnings

Summary:
The lj-cut text that shows up on a reading list and journal pages for entries in journals and communities with adult content filters is misleading.

Description:
When someone logged out (or otherwise having adult content filters set) is looking at a reading page containing entries from journals and communities that have set adult content warnings, the entries are replaced with cuts with a preset text.

All entries flagged 18+/adult content get the text "You're about to view content that a community administrator has marked as possibly inappropriate for anyone under the age of 18." - referencing a community administrator - even when the entry is in a private journal, which makes it appear that the flag could have been set by somebody other than the journal owner.

Conversely, all entries with the viewer discretion flag set get the text "You're about to view content which the journal owner has advised should be viewed with discretion. " - even if they're entries in communities, which is also confusing, though less so.

ETA: This problem seems to only appear when the entire journal is set to adult content, not when individual entries are marked. When individual entries are marked, the text is correct.

The language in the cuts should be changed so that references to community maintainers and journal owners are either removed, or match the type of the journal.

It would be very nice if the cut text was in general re-written to be more informative - more like the text you get if you click through to the warning page, giving a reason, who did the marking, and the fact that the whole journal is marked, not just the one entry* - but at the very least, the misleading language about community administrators needs to be fixed.

*yes, clicking on "You're about to view content which the journal owner has advised should be viewed with discretion" to get to pictures of a kitten playing with string *is* amusing, but also very odd to anyone who isn't already familiar with how the filters work.

Poll #1195 Content warning cuts on reading list

Open to: Registered Users, detailed results viewable to: All, participants: 33

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
22 (66.7%)

Should be implemented with changes. (please comment)
1 (3.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
9 (27.3%)

(Other: please comment)
1 (3.0%)

cesy

Title:
Changes to "Request for invite codes has been granted" email

Area:
invite codes, notifications, email

Summary:
Add the actual codes to the email unless there are loads of them.

Also, make sure it has the usual site footer.

Description:
The "your request for invite codes has been granted" email apparently just has a link to manage/invitecodes; it doesn't have the codes in the email. I'd suggest putting the codes in the email itself, as it is for the normal invite code granting email, unless the number of codes is more than, say, 20.

It doesn't appear to have the usual footer, either. ("-- Dreamwidth Team Dreamwidth Studios" or whatever with a link back to the main site)

(This is from testing on my Dreamhack - I haven't had the email on the main site to compare, but it looks like this is one of those things where the email text is in the code.)

Poll #1184 Changes to "Request for invite codes has been granted" email

Open to: Registered Users, detailed results viewable to: All, participants: 32

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
22 (68.8%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
10 (31.2%)

(Other: please comment)
0 (0.0%)

szabgab

Title:
what html and extra tags can be used?

Area:
post editor

Summary:
When writing a new post or editing an older one I could not find an easy (or for that matter any) link to a list of HTML tags I can use (or that are recommended) or the extra tags DW allows and their recommended usage (eg. <cut>...).

Description:
I'd like to have that.

Poll #1152 what html and extra tags can be used?

Open to: Registered Users, detailed results viewable to: All, participants: 32

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
17 (53.1%)

Should be implemented with changes. (please comment)
6 (18.8%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (21.9%)

(Other: please comment)
2 (6.2%)

justinfinchfletchley

Title:
Friend All Button or Reading List / Grant Access Button

Area:
admin console or possibly entries

Summary:
Basically, some journal communities like insanejournal enable you to create a form in a livejournal entry that access the admin console to add a group of friends with a click of a single button.

Description:
I don't know if this is possible to implement as I don't know what goes into it, but certain journal communities that were based on livejournal code (specifically insanejournal but previously also greatestjournal), you were able to create a submission form that basically accessed the admin console and let a user add everyone listed by the form to their friends list. This would be slightly different in function as dreamwidth uses both an access and subscribe option but overall I think the theory is the same.

The best I can point to is this for reference:
http://www.insanejournal.com/support/faqbrowse.bml?faqid=165&view=full

But it's very helpful in RPs to be able to provide members with one easy click method to add all the other members of the community to their reading/access list.

Poll #1129 Friend All Button or Reading List / Grant Access Button

Open to: Registered Users, detailed results viewable to: All, participants: 28

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
4 (14.3%)

Should be implemented with changes. (please comment)
7 (25.0%)

Shouldn't be implemented.
7 (25.0%)

(I have no opinion)
10 (35.7%)

(Other: please comment)
0 (0.0%)

cesy

Title:
Email summary of post-by-email commands/options

Area:
post-by-email

Summary:
Feature to request an email summary of post-by-email commands.

Description:
Inspired by http://community.livejournal.com/suggestions/938685.html

Add a feature to request an email summary of the post-by-email commands. This could be simply a copy of the FAQ on email posting, including all the commands, or (vote "with changes" if you want this) it could also include a list of the names of your custom access groups, for the lj-security command, and your icon keywords.

You'd be able to click a button on the site and get an email sent to your registered address with the info that's in the FAQ, so next time you're out and about and can't remember the commands, you can look them up in your email. In an ideal world it would also be possible to request this by emailing a specific command to the post-by-email address, but that would be more complicated to implement well.

Poll #997 Email summary of post-by-email commands/options

Open to: Registered Users, detailed results viewable to: All, participants: 32

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
20 (62.5%)

Should be implemented with changes.
4 (12.5%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
8 (25.0%)

(Other: please comment)
0 (0.0%)

Dreamwidth Suggestions

Create Entries beta : help button for HTML and Markdown

Add complete pre-filled custom s2 template for beginners on the Wiki.

Merge full FAQ search form into FAQ list

Support: widen the 'Reference FAQ' drop-down menu

make list of allowable HTML easier to get to

"Delete all" should not be option in inbox subfolders

Make the tag "security" label useful, or remove, or at least explain it

Index page for ways to filter a page

Add privacy warning to faq about forwarding email from your username@dreamwidth.org address

Styles: Add links to Your Layers

Remove the phrase "I hope you enjoy it" from the Tell A Friend feature

Improve comment title admonishment about HTML

Post diffs of style changes right before a code push

Content warning cuts on reading list

Changes to "Request for invite codes has been granted" email

what html and extra tags can be used?

Friend All Button or Reading List / Grant Access Button

Email summary of post-by-email commands/options

Profile

Most Popular Tags

December 2018

Page Summary

Active Entries

Style Credit

Expand Cut Tags

Syndicate