Dreamwidth's open source repository
License: Other
Please see the LICENSE file for the license of this code. Note that all code
committed to this repository MUST be licensed under the GPL and have proper
copyright notices tagged at the top of the file.
For more information on how to use this software, please harass someone to actually write out documentation here. :-)
Please see our wiki for more information.
Thanks!
As implementing this means going over each style (and sometimes theme) to make sure things display correctly, this can be implemented gradually and doesn't have to be tackled by one person.
The first step is to add this to Core2. Second step can be to add this to non-Tabula Rasa styles (which can be done style-by-style); third to add it to TR then to TR-styles (and if you hide the option in TR using noui=1, you don't have to go through every TR style at once either).
Want to update /entry/new to Foundation. Better sooner rather than later.
Submission entry: http://dreamscapes.dreamwidth.org/126381.html
Note: this is a CSS submission and will require conversion to S2.
Submission entries: http://dreamscapes.dreamwidth.org/tag/~boxed+in
Note: Laitaine had this almost fully patched --I think there were only a few issues left.
Submission entry: http://dreamscapes.dreamwidth.org/123136.html
Currently, posts that are emailed in to the site use UTC (that being the timezone the DW servers use) rather than the user's specified timezone, if any.
In addition to causing problems with the "is this in the future" checks on subsequent updates (which I'm posting to dw-dev about maybe changing), it leads to inaccurate times on the entries: depending on how severe the timezone offset is, it can look like someone posted from work at 0200, or is just getting out of bed at 1500 when they're supposed to be at work, etc.
If a user has set a timezone for their account, the incoming email worker should check that timezone and apply the appropriate offset. So, for instance, if I've defined my timezone as EDT/EST, and I email in a post at 0600 UTC, it should be posted to my journal with a time/date stamp of 0200 EDT. (Or, if I'd done so two months ago when it was EST and not EDT, the datestamp should be 0100 EST, since 0600 UTC = 0200 EDT but 0100 EST.)
If the account does not have a timezone set, it should still fall back on UST.
This ticket is causing major issues. It should be dealt with, etc.
Sample code:
<iframe src="https://archive.org/embed/LeonardNimoy15Oct2013YiddishBookCenter" width="640" height="480" frameborder="0" webkitallowfullscreen="true" mozallowfullscreen="true" allowfullscreen></iframe> Submission entry: http://dreamscapes.dreamwidth.org/25858.html
In Location, the 'state' field only says 'states/regions/territories' if you've picked US as a country. Otherwise it's just 'state'. As several other countries don't have 'states' if would be nicer if the phrasing could seem more inclusive when you select them.
Submission entry: http://dreamscapes.dreamwidth.org/128228.html
Note: this is a CSS submission and will require conversion to S2.
Nobody has looked at this one. Please triage me! I'm cool.
We've had several requests from confused users who thought they weren't getting some notifications only to realize their account status didn't allow them to track comment threads. However, they can see the track icon and they can add the notification and nothing tells them it won't work. The icon at least should be hidden from them.
only on edit but not when posting
Icons which were uploaded with a pic#xxx keyword then later renamed cannot be used correctly in entries and comments: they revert to the default icon when posted. It is unclear whether deleting then reuploading the icon with one's desired keyword lets you use the icon.
Related pull request: #444
We've had multiple requests about this issue.
Suggestions generator (http://www.dreamwidth.org/site/suggest) posts two things: a public entry for discussion, and a private (admin) entry with a link that, when clicked, created a new Bugzilla bug with everything nicely preformatted.
Admin entry should be changed to post to Github instead. This will take some research into the Github API.
We've had several requests noting that loading http://www.dreamwidth.org/file/edit only resulted in an error message:
[Error: Image has no internal width/height! at /home/dw/current/cgi-bin/DW/Media.pm line 62 @ sb-web11.dreamwidth.org]
"Sorry, there was a problem."
[ former bug 1501 ]
The month view is the last remaining journal-styleable view that is still using a BML page for ?style=site by default.
Compare:
http://exor674.dreamwidth.org/2013/06/?style=site
http://exor674.dreamwidth.org/2013/06/?style=site&fallback=s2
Submission entry: http://dreamscapes.dreamwidth.org/32412.html
How to duplicate:
If you have somewhat long-ish meta text, it's cut off when you display icons at their full size, even when you browser's font size is pretty small.
Sample code:
<iframe width="450" height="338" src="http://video.yandex.ru/iframe/v-rednaia7/9hvgcmpgkd.5440/" frameborder="0" allowfullscreen="1"></iframe>Request is: http://www.dreamwidth.org/support/see_request?id=26816
Members-only entries an admin authored can be seen on the recent page of the community and at /editjournal but not edited or deleted when the admin isn't a member of the community.
OTOH, viewing the entry only via its URL gives you an error message (entry is protected blah blah blah).
I don't know if this is also true when you're not an admin.
Pretty sure we didn't use to be able to view members-only entries even when we authored them and this a result of the 'make sure authors always have access' bug with unforeseen results here.
This is a test issue. Please ignore.
Multiple viewers reported not being able to see time in 12h format either in comments or in entries when viewing their journal pages in site-skin style (via the display settings or the nav strip options).
Unchecking the setting for entry flags has no effect as the box is always displayed anyway (except when you're posting to a personal journal).
Side note: also having the box disappear is slightly unsettling (especially when you change your settings). By comparison, the crosspost box has a 'no can do' message when you post to a community journal but doesn't disappear.
Very large communities have their members list and therefore members' posts page disabled. Yet the message there is the common 'there are no entries to display because 14 days/1000 entries, etc.".
It would be nicer if it'd reflected the situation more accurately. Bonus points if there's a corresponding FAQ and it links to it?
Request is: http://www.dreamwidth.org/support/see_request?id=27538
We've had several requests over the years from users mentioning their style had suddenly, and for no apparent reason, reverted to our current default, Practicality/Neutral Good.
It's interesting to note that, as far we know, they switch to a newly created style (the style IDs we got were very high indicating these were new).
This means they can usually revert to their default by going to /advanced/styles and reselecting their usual style again.
CONTRIBUTING.md needs to be edited at the very least; there might be another elsewhere.
Submission entries: http://dreamscapes.dreamwidth.org/tag/%7Edaydream+believer
The current interface is very old and very impractical.
Having something close to what's in the Beta Update page would be awesome (and community admins would love you forever and ever...).
Having header links such as navigation links use module colors can cause readability issues. When links are displayed in the header they should use their own set of colors, distinct from module link colors as header and module can have different background colors.
I think this is implemented everywhere but in Bases and Practicality.
Note1: props in Core2 already exist. You don't need to create them.
Note2: users shouldn't see any changes if possible. You'll probably have to set the options to whatever colors were used instead. Nobody will blame you if you decide you don't want to do this for Practicality seeing as it has about 100 themes...
The settings in config.rb don't make any distinction between prod and dev. So things like whitespace, comments, which don't make sense in prod are added to the output. We should be okay because we then run it through yui, but I'd prefer to be explicit in the config, since it's relatively easy to do :)
Going to make the dev mode the most verbose I can the production mode the least verbose.
This is a demonstration ticket of an in-progress item.
People with the siteadmin:* priv should be able to PM accounts that have not confirmed their email addresses. (Reason: occasionally someone registers with the wrong email address, the owner of the email contacts us, and we have zero methods for contacting the account owner and telling them to update their email address.)
On leaving a screened comment in someone else's journal, the "Post Comment: Success" landing page reads: "Your comment has been added. According to this account's settings, it was marked as screened and will be visible only to you and the journal's owner unless the owner chooses to unscreen it. [View your comment.]"
However, on leaving a screened comment in your own journal, the landing page reads: "Your comment has been added. According to this journal's settings, it was marked as screened, and will be visible only to you until you choose to unscreen it. You can view your comment [here]."
This true only if you are leaving a top-level comment or a threaded response to yourself, not if you are leaving a response to a screened comment made by somebody else on your post. (Edge-case I haven't tested: if you leave a reply to a comment you left in a thread that was started by someone else, call them AB. Is the conversation as a whole visible to AB, or only screened comments left directly in response to AB's comments?) The landing-page text should be edited to accurately reflect what actually happens.
I recommend adding a .gitattributes file. See: https://help.github.com/articles/dealing-with-line-endings
Several styles allow the navigation module to be displayed at the top or in the header area rather than in the sidebar.
This should be turned into a Core2 option and implemented in every style if possible.
As the scope of this bug is pretty big, don't hesitate to do this gradually or to work on one or two styles only. This doesn't have to be done all at once, or by only one person.
This is true in every browser if you use a low enough font size/minimum font-size combo.
This is invalid in Foundation-upgraded pages so may not need to be actually fixed, just recorded for support purposes.
Perhaps not actually an RTE, but something that does preview / helps insert formatting without needing to know HTML / help with inserting an image or embed.
I'd like to experiment with a Markdown editor here.
With the problems with renaming "pic###" keywords we've been having, and the general way that the placeholder-keywords aren't very well integrated into the site (and how old that code is, anyway), I think we should actively discourage people from leaving icons unkeyworded.
So: Whenever anyone loads /editicons, if they have any icons that are unkeyworded, there should be a standout box at the top of the page:
"WARNING: You have not added keywords for one or more of your icons. They have been assigned an automated keyword, in the form of "pic###". Icons with automated keywords can be used in posts and comments, but may behave strangely. We strongly recommand that you assign keywords to your icons before using them."
It appears that more recent updates have started to work on commenting in ways other than use of the web interface. Cool. However, there are still no clients that can post comments (whether because they're orphaned or because it's not doable with the APIs, I don't know). Given that my interaction with DW, at least, is primarily comment- rather than post-oriented, bringing comments into first-class position is great.
Back when DW still used Bugzilla, noodles produced what was described as an "epic patch" exposing Dreamwidth over NNTP. For me, that was a dream come true. It's a shame, therefore, that despite some early moves in that direction, it wasn't tried. Thus the translation of the bug to a GitHub issue (unfortunately I don't have the original text cached, or I'd have used that).
Incidentally, if anyone has a copy of the patch lying around I'd love to get my hands on it and attempt to update it to the point where it would apply cleanly on the current version of Dreamwidth. As soon as I can do that, this issue will be more than just a general complaint (and will get a corresponding pull request, though I don't expect that the first such request would actually be accepted; it'd be more as a "this is in usable condition, time to talk about what it needs to get into mainline").
Submission entry: http://dreamscapes.dreamwidth.org/127130.html
D, if you could confirm we have their CLA?
Sample code provided by the user:
<iframe src="http://embed.ted.com/talks/handpring_puppet_co_the_genius_puppetry_behind_war_horse.html" width="560" height="315" frameborder="0" scrolling="no" webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>Sample code:
<iframe src="http://episodecalendar.com/icalendar/EMAIL/KEY/?v=light" width="100%" height="500" frameborder="0" scrolling="auto" allowtransparency="true"></iframe>My own request, please!
EMAIL is the address one registered with.
KEY is a seemingly randomly generated alphanumeric 20-character string.
On posting a screened comment, the success landing page currently includes "View your comment [here]." Descriptive link text is better link text: this should instead read something to the tune of "[View your comment]." (Where [] indicates link text).
Submission entry: http://dreamscapes.dreamwidth.org/96339.html
Note: this needs conversion to S2 and refactoring so it's a full-fledged Tabula-Rasa style.
This is a big'un.
Tagging issues requires read-write access to the repo. Let's see if we can at least automate that.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.