![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
Entry tags:
Question thread #28
It's time for another question thread!
The rules:
- 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 rules:
- 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.
no subject
Possibly an OT question but here I go anyway:
I was making a style and I noticed search used pretty old design both on journals and on the site (compared to the now usual custom of using a magnifier icon and putting it within the search field instead of having a whole button besides it) and I wondered if it was a choice or it just happened to be that way. In particular, I wondered if it was because newer designs aren't accessible or user-friendly? Or don't account for people who don't display pics. Or disable JS. I also noticed the beta Create Entries page made bigger use of iconography but there was very often text to accompany it. So yeah, I'm intrigued about the reasoning behind some design decisions because it's not often discussed here in dev but I think it's very important.
no subject
It is honestly mostly because of a lack of time to work on it.
There are certainly ways to make the newer designs accessible; as for user-friendliness, I believe that the new designs are common enough that people identify the pattern.
(With caveats of making sure there’s a [hidden] label for screenreaders / dictation users, etc)
For icons, we should always have text to explain them. Visible text almost always; non-visible only for the most common patterns that are immediately recognisable (e.g., a search box).
no subject
no subject
Look for "bulletproof icon fonts" -- it's a great resource I've gone over a lot :)
no subject
Thanks for your help!
no subject
The API we currently have available is the same as the old LiveJournal API (with a few functions removed because we split 'friends' into access/subscription). The docs are here -- out of date, but still accurate in the most part.
It's not great, in other words. We've had recurring discussion about a next-gen API (that was actually, you know, designed in the 21st century), which honestly I'd consider a prereq for a decent mobile client, but it's such a huge prospect that people sort of take one look at it and throw up their hands and back away slowly.
no subject
I ask because I've been learning about writing tests for other projects I've been working on (in Python) and I'm working on this bug: https://github.com/dreamwidth/dw-free/issues/659 and planning to pick up some more, and I like tests that tell me I haven't broken things.
no subject
The test coverage is spotty, and we don't make "run the tests" part of pre-pull-request testing because running them can corrupt the DB on your development machine. There's been some work done on it, but not a whole lot, so anything you wanted to do would be awesome!
no subject
(Anonymous) 2015-03-02 06:46 am (UTC)(link)no subject
no subject
I don't know much about it myself, but a quick Google search turns up this as a start. (I believe we do use Test::More.)
Debugging help?
I added what I thought ought to be a simple extra set of conditionals to check for whether there is in fact a parent comment and whether its author is the journal owner: https://github.com/fhocutt/dw-free/blob/bug659-screened-comment-incorrect-text/htdocs/talkpost_do.bml#L237
I get the following errors on /talkpost_do on my dreamhack when I try to respond to a screened comment left by somebody else:
[Error: /dreamhack/home/8274-quartzpebble/dw/htdocs/talkpost_do.bml.text:81: Bogus format. at /dreamhack/home/8274-quartzpebble/dw/cgi-bin/LJ/Lang.pm line 592. ]
[Error: syntax error at /dreamhack/home/8274-quartzpebble/dw/htdocs/talkpost_do.bml line 227, near ") {" syntax error at /dreamhack/home/8274-quartzpebble/dw/htdocs/talkpost_do.bml line 230, near "} elsif" Global symbol "$commentu" requires explicit package name at /dreamhack/home/8274-quartzpebble/dw/htdocs/talkpost_do.bml line 230. Global symbol "$commentu" requires explicit package name at /dreamhack/home/8274-quartzpebble/dw/htdocs/talkpost_do.bml line 230. syntax error at /dreamhack/home/8274-quartzpebble/dw/htdocs/talkpost_do.bml line 232, near "} else" syntax error at /dreamhack/home/8274-quartzpebble/dw/htdocs/talkpost_do.bml line 235, near "} }" syntax error at /dreamhack/home/8274-quartzpebble/dw/htdocs/talkpost_do.bml line 280, near "; }" @ newhack.dreamwidth.net]
Google suggests that the "requires explicit package name" usually shows up when one doesn't use my, but it looks to me like $commentu is. Am I missing anything obvious?
Re: Debugging help?
if ( $parentu && !($parentu->equals ( $journalu )) {The other error messages may be red herrings -- that is, the syntax error prevents the next lines from being able to be read correctly, so they throw out misleading errors.
Re: Debugging help?
Some of them were; others were complaining about tabs that had snuck into talkpost_do.bml.text somehow (I really don't know what was up with that, but they're out now).
Now I get:
Post Comment
Success
on talkpost_do for a screened comment, but no message body.
Is anything else obvious here?
Re: Debugging help?
Re: Debugging help?
Lost this line!
$ret .= “<?p " . BML::ml($mlcode, {'aopts' => "href='$commentlink'"}) . " p?>”;Re: Debugging help?
Yay, thank you! Now I can debug the logic itself...
Re: Debugging help?
Awesome. Good luck!