Recent Entries

- You may ask any dev-related question you have in a comment. (It doesn't even need to be about Dreamwidth, although if it involves a language/library/framework/database Dreamwidth doesn't use, you will probably get answers pointing that out and suggesting a better place to ask.)- You may also answer any question, using the guidelines given in To Answer, Or Not To Answer and in this comment thread.

Mark is comfortable that with a few UI tweaks it could be added to the main menu (Organize --> Manage files, or similar) in order to be discoverable.

The big thing is "have the HTML for embedding an image provided anywhere other than immediately after uploading it". At this stage adding more features/functionality is not on the cards (unless you're volunteering!), but in the spirit of doing a relatively quick UI polish, is there anything else you'd like to see?

I'll be filing an issue in a week's time, and hopefully we can get UI tweaks out in the next code push...

- You may ask any dev-related question you have in a comment. (It doesn't even need to be about Dreamwidth, although if it involves a language/library/framework/database Dreamwidth doesn't use, you will probably get answers pointing that out and suggesting a better place to ask.)- You may also answer any question, using the guidelines given in To Answer, Or Not To Answer and in this comment thread.

Historically we've had a policy of trying to actively support people who might be running the DW code somewhere and that has influenced how we've built things, such as making many things options in the codebase and also maintaining support for legacy configurations and systems that we might not use in Dreamwidth.org's production environment.

Since there's not (and never much has been) people seriously running DW code for any major service, I would rather for us to focus our limited development resources on our own development needs. To be totally clear, we will continue to maintain Dreamwidth the open source platform and people are very welcome to use it. You just might have to either do some of your own development or use a production environment that closely mirrors ours.

Some examples of what this update means:

* Perlbal is no longer used at DW HQ and we're removing all support for it* MogileFS is on its way out (to be replaced by either simple on-disk storage or Amazon S3)* Master-Master support is deprecated and will be removed* Configuration options are being cleaned up and some things will become non-optional (i.e. compression, etc)* No more support for 32 bit systems (think this is gone already tho)

My goal here is to make Dreamwidth development faster and easier for actually developing on Dreamwidth.org. We'll still have to make it possible (and easier!) for people to run DW (if nothing else for our own developers!) but the number of at-scale-production-configurations supported is going down.

Sorry if my question is offtopic in this community, but it doesn't seem like your dev question thread is very active, so I'll take my chances and ask here. I'm trying to programmatically download DW posts from my journal and have troubles accessing friends-only and private posts. Suppose I have the following request:

1) I updated my develop branch so that I could rebase my work on converting /customize and /customize/options to TT, and having done so, discovered that the CSS files for both Tropospherical site schemes aren't being served properly. The files are there on the server, but for some reason when they're concatenated with other CSS files the server is falling over. I'm not sure how to fix it.

2) That said, I think I have the bulk of the conversion work done. It's a lot of code, and I had to make some changes to the HTML form template plugin, though, so I'd really appreciate it if some people could go bang on it some before we get it set up for a beta on production. My hackspace is http://www.momiji.hack.dreamwidth.net/

- You may ask any dev-related question you have in a comment. (It doesn't even need to be about Dreamwidth, although if it involves a language/library/framework/database Dreamwidth doesn't use, you will probably get answers pointing that out and suggesting a better place to ask.)- You may also answer any question, using the guidelines given in To Answer, Or Not To Answer and in this comment thread.

- You may ask any dev-related question you have in a comment. (It doesn't even need to be about Dreamwidth, although if it involves a language/library/framework/database Dreamwidth doesn't use, you will probably get answers pointing that out and suggesting a better place to ask.)- You may also answer any question, using the guidelines given in To Answer, Or Not To Answer and in this comment thread.

The update page should default to RTE on the beta update page. To disable it, go to Settings and check "Completely disable the Rich Text Editor (use plain textarea only)". (Historically speaking, a lot of RTE glitches happened when switching from HTML mode to RTE mode, so it's probably worth testing that a bunch.) Accessibility help is available by pressing Alt+0 (zero) while the editor is focused.

If you run into a problem or want to give feedback, you can comment on this entry. If reporting a problem, please include a link to the entry you made so wohali can see the markup!

Every few months, I run through changelog compiling a list of who has been contributing patches to our code repository, with the understanding that this is not a competition, or any sort of "high score" list. It's intended as a guide for casual developers, to discern not only our most prolific contributors, but also those who have contributed to the project most recently and therefore would be more likely to provide a timely, informed response to development questions. That is why the list is sorted by "Latest" instead of "Changes".

In general, one commit on Github equals one point in the "Changes" column, but fractional points are awarded for collaborative efforts — the most common example being a new S2 theme, where usually half credit is awarded to the theme author and the other half to the person who converts the theme into a code patch. Due to the nature of development, some changes are massive contributions of new code, and others are tiny tweaks; there is no correlation with the amount of effort involved. We are grateful to everyone who helps to improve Dreamwidth, in ways large or small.

I've just merged woggy's code for the new Selective Screening feature! I'm planning on making it live on the site in the next couple of days, but in the meantime, I encourage you to test it in your development environment and let me know if you have any feedback. Here is how it works:

There are three console commands that govern who is subject to selective screening in your journal or community. They are screen_set, screen_unset, and screen_list and they are very similar to the related console commands for banning users. The maximum number of users you are allowed to apply selective screening to is 500 per journal/community.

When a user is subject to selective screening, all of that user's comments in the affected journal/community will be automatically screened, regardless of what the entry's screening settings are. The affected user is informed that their comments are being screened when viewing the reply form. The user's screened comments are like any other screened comments and can be manually unscreened, receive screened replies, etc.

- You may ask any dev-related question you have in a comment. (It doesn't even need to be about Dreamwidth, although if it involves a language/library/framework/database Dreamwidth doesn't use, you will probably get answers pointing that out and suggesting a better place to ask.)- You may also answer any question, using the guidelines given in To Answer, Or Not To Answer and in this comment thread.

I'm in the process of updating /customize/ to move it away from BML and a million widgets, and I've got most of the HTML-y stuff done, but I'm having trouble with the Javascript. The biggest part of this is redoing the AJAX queries, which were previously done in widget-specific ways and passed through a bunch of the Widget class handlers. Working off jQuery, I've gotten as far as getting it to submit a POST request which reaches the controller - but the param formatting is all wrong and missing a bunch of the parameters sent with a TT form POST request. Do we have methods for creating proper POST requests from AJAX?

The Dreamhack machine currently seems to be suffering from a performance issue where if you try to start your Apache, it might tell you that Apache failed to start. In reality, the Apache server *has* started, but the 'start-apache' script is timing out before Apache can report that fact.

If the last line of your Apache log file is:

NOTE: Google::Checkout::* Perl modules were not found.

then Apache has most likely started successfully. (This is a normal warning on Dreamhack machines; we haven't used the Google Checkout code for some time and thus the modules are not installed on the Dreamhack machine.) You can verify this by navigating to your Dreamhack's Web address.

We're investigating this at the moment. This might require a reboot of the Dreamhack machine in the near future; we'll post about it here if that's the case.

[edit: We're going to reboot the Dreamhack machine. I'll edit this post again when it's up.]

[edit 2: The Dreamhack machine is back up, and I've rolled out a new version of start-apache that can wait a bit longer if Apache doesn't start up immediately. It prints out a "Waiting for Apache to start" message, and then checks every second (for up to 6 seconds) whether Apache started, so it shouldn't slow things down for anybody.]

Issue 1851: add alert for email output dropping too farCategory:Patch by:alierakDescription: Yeah. Yeah. You know that bit where the entire site just... stopped sending e-mails for several days? And this meant nobody got any notifications about comments or support requests about the lack of notifications? And I, for one, saw a few people mention it but was up to my eyeballs in lab and therefore assumed Google had just greylisted Dreamwidth again so didn't actually sound any klaxons? YEAH. It turns out that it's possible, with how notifications get sent, that the connection can... drop... and... no... alerts... went off? So it's now the case that an alarm will start Very Noticeably Blaring if the site doesn't actually succeed in sending any e-mail for longer than 15 minutes. This might get refined, but at least the site won't faceplant into this particular failure mode for quite this long again.

- You may ask any dev-related question you have in a comment. (It doesn't even need to be about Dreamwidth, although if it involves a language/library/framework/database Dreamwidth doesn't use, you will probably get answers pointing that out and suggesting a better place to ask.)- You may also answer any question, using the guidelines given in To Answer, Or Not To Answer and in this comment thread.

Are the answers to this thread reflective of the current state of accessing entry comments via an API? Or has anything changed? (In particular, denisementions a possible new API designed in the 21st century.