Site Design

[Fangu]

Just throwing in that in general it's considered bad practice to render a broken image just because an image upload is missing, you'd rather just render no HTML at all. Kind of having problems understanding why the Fractions people chose to set it up that way.

 

[Flintlock]

Just throwing in that in general it's considered bad practice to render a broken image just because an image upload is missing, you'd rather just render no HTML at all. Kind of having problems understanding why the Fractions people chose to set it up that way.

Ah, your mention of Fraction jogged my memory that they actually included a setting to hide those broken images. I flipped the switch. So that's one less thing to argue about now.

 

[Shademp]

Ah, your mention of Fraction jogged my memory that they actually included a setting to hide those broken images. I flipped the switch. So that's one less thing to argue about now.

Many, many thanks. I truly appreciate it. =) If you find a switch to make it so the Featured Image only appears in search results (like in this type of search window you posted) then I would set the Unused Text Logo as the Featured Image to every UT article. Just as long as said logo isn't forced to show up inside the actual Page article, I'm good.

I remember that at least before the frontpage update, what you set as a "Featured Image" in a newspost only appeared on the frontpage newsfeed, not inside the actual article. So clearly WordPress, at least in that earlier version, was not alien to that type of functionality.

As I added to my previous post in an edit, I'm working on it. It's looking more and more like the solution is going to involve Javascript.

Just curious, but what was it that *really* made you remove the function to adjust the width and height of an [Embed] in the first place? Does it have to do with semantics again?

 

[Flintlock]

I remember that at least before the frontpage update, what you set as a "Featured Image" in a newspost only appeared on the frontpage newsfeed, not inside the actual article. So clearly WordPress, at least in that earlier version, was not alien to that type of functionality.

Yeah, it's certainly not impossible. It's a function of the theme we're using. I haven't looked into it much yet but I have a feeling it'll be a pain to change.

Just curious, but what was it that *really* made you remove the function to adjust the width and height of an [Embed] in the first place? Does it have to do with semantics again?

Not semantics, just presentation. It's pretty pointless nowadays to hard-code height and width when visitors' browsers range from 300px to 4000px in width (and that range will only grow in the future). It's much better to define sizes proportionately, and using 100% of the available width makes the most sense. I want 100% width videos on articles and I'm trying to find a way of allowing smaller videos on pages while keeping them responsive.

This is going to get a bit technical now, but the problem I'm bumping into is that the way to make videos responsive through CSS involves giving them absolute positioning while putting them inside a container div with relative positioning. Since the container div doesn't have an intrinsic size (because absolute elements are taken out of the flow of content), we have to define its size as 56.25% of the page width (because most videos have a 16:9 aspect ratio and 9/16 = 56.25%). But that ends up leaving a lot of blank vertical space if the video is less than full-width. It's not currently possible to adjust the size of the container in those cases through CSS alone; we'd have to use JS. After trying some code of my own without much luck (I'm not a JS person), I found a plugin called FitVids, but that too makes everything full-width. I've seen hints at how to make the necessary change but not a full solution, so I'm a bit stuck.

 

[Tashasaurous]

Can someone please help me? I'm trying to post a comment on one of the quick chat boards where you talking about anything. But I can't do it freely anymore and whenever I try to go the image thing and correctly verify, all I get is an error so my post is not allowed to be posted anyway.

What is that happening?

 

[Flintlock]

I'm not really sure. I turned off the Recaptcha plugin for now. I tried another one; that was accepting comments but marking them all as spam, so I turned that off too. Perhaps it's not necessary to have both a Captcha plugin and an anti-spam plugin (Akismet).

You should be able to make comments again. Thanks for reporting it.

—

As for the videos, I'm nearly there. Both full-width and smaller videos now display correctly when the page is loaded. The problem is that they're not resizing correctly if the browser width changes. More JS learning needed...

 

[Tashasaurous]

I'll try commenting again, but thanks for the help anyway.

Edit: Commented on the 30th Anniversary thing and it works without the Captcha plugin. Thanks, Flintlock.

 

[Flintlock]

As for the videos, I'm nearly there. Both full-width and smaller videos now display correctly when the page is loaded. The problem is that they're not resizing correctly if the browser width changes. More JS learning needed...

I've done it. I have become a summoner.

It's only taken five hours of my life but I'm glad to have figured it out. I didn't need to do anything "on resize" after all, just add another container with jquery setting its max-width property. Why does it feel like that [adding another container] is the solution to 99% of CSS problems and why didn't I realise that sooner?

To recap:

[embed]https://www.youtube.com/watch?v=ucfj2BaPBjs[/embed]

will produce a full-width Youtube video.

[embed width="[I]w[/I]"]https://www.youtube.com/watch?v=ucfj2BaPBjs[/embed]

where w is between 200 and 838 will produce a video with a maximum width of w px. 200 px is the lower limit for Youtube videos and 838 px is the upper limit for our layout.

[embed height="[I]h[/I]"]https://www.youtube.com/watch?v=ucfj2BaPBjs[/embed]

where h is between 150 and 471 will produce a video with a maximum height of h px. Again, 150 px is the lower limit for Youtube videos and 471 px is the upper limit for our layout.

There's no point setting both the height and width because one can be calculated from the other according to the video's aspect ratio. In fact, if you do set both, the height will be ignored anyway so as not to cause stretching. I recommend setting width only if you have to set either.

In all three cases the video will resize according to the browser width without cropping or stretching. In the latter two cases the less-than-full-width video will be centered on the page automatically, so you don't need to wrap it in <center> tags or <span style="text-align: center;"> or whatever. Note that <center> tags flat-out don't work in HTML5.

You're welcome.

 

[Fangu]

Why does it feel like that's the solution to 99% of CSS problems and why didn't I realise that sooner?

Because you're using a JavaScript library to solve a CSS problem?

It isn't entirely uncommon to do so though. Most surfaces rely on JS anyway these days.

 

[Flintlock]

Trust me, I'd switch to pure CSS in a heartbeat if I could.

 

[Shademp]

I've done it. I have become a summoner.

...

You're welcome.

Thank you muchly! Well done. I have proceeded to replace all old YouTube embedding code with the [embed] tag now.

In the latter two cases the less-than-full-width video will be centered on the page automatically, so you don't need to wrap it in <center> tags or <span style="text-align: center;"> or whatever. Note that <center> tags flat-out don't work in HTML5.

Auto-centering is also appreciated.

You say that <center> tags don't work in HTML5. So which HTML does the Text Editor currently use, since <center> tags still work there?

 

[Cthulhu]

After trying some code of my own without much luck (I'm not a JS person)

Hello I am a JS person

 

[Flintlock]

You say that <center> tags don't work in HTML5. So which HTML does the Text Editor currently use, since <center> tags still work there?

This isn't quite the right way to think about it. You can put whatever code you want in the text editor but it doesn't mean it's going to work properly when you publish an article/page &#8211; it's what they use that matters. And it is actually HTML5. You can see that if you "view source" anywhere on the site (not the forum). The first line of the source will be

<!DOCTYPE html>

which is the HTML5 declaration. Older versions of (X)HTML have longer declarations along the lines of

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

So this begs the question, why does the <center> tag still center things when it's not supposed to work? The answer is that browsers don't just follow standards; they do their best to take obsolete or garbled markup and produce what they think is the correct output. Chrome, for example, still allows the <center> tag to center things on HTML5 web pages presumably because millions of users would be annoyed if it didn't; an understandable decision, but not something we should rely on, because Google could remove that functionality at any moment. Or another browser could &#8211; maybe some already have, I'm not sure. The only way to ensure that our website looks the same across all of them (in theory, at least) is to use standards-compliant code.

 

[Shademp]

Bumping to remind that we need a proper "Login to TLS WordPress" button on the frontpage. I can't find one and currently I'm making do with a link to the login page in my Favorites.

 

[Flintlock]

Every comment section contains a login link (only visible if you're not logged in already). I'm not sure we need another one on the front page.

 

[Shademp]

That's good to know about the comment section, though in my opinion it's a little too obscure to have to enter a comment section to find a login link.

If it were me I would include a login at the very bottom, like this. But I won't insist anymore beyond this post. I have voiced my opinion.

 

[Flintlock]

I don't think it's obscure. There are only two reasons ever to log in:

1. To make a comment
2. To access the admin panel

The first case is, obviously, covered by the login link in the comment section, while the second only applies to about a dozen of the thousands of people who visit our site each month, so it's not unreasonable to ask them to bookmark it in their browser rather than get a dedicated link of their own. (That link is here in case anyone doesn't have it yet.)

Sorry if this comes off as defensive; it's not supposed to be. I just felt like giving an explanation because this is by design, not an oversight.

 

[The Twilight Mexican]

I second Shademp's opinion. I actually used a WaybackMachine capture of the front page from Archive.org to find the login link recently.

EDIT: We were posting at the same time, Flint. Give me a second to update this post.

EDIT 2:

I don't think it's obscure. There are only two reasons ever to log in:

1. To make a comment
2. To access the admin panel

The first case is, obviously, covered by the login link in the comment section, while the second only applies to about a dozen of the thousands of people who visit our site each month, so it's not unreasonable to ask them to bookmark it in their browser rather than get a dedicated link of their own.

Perhaps not unreasonable, but certainly frustrating when I might be using one of three different devices at any give time, one of them being my workstation at work that I'm not really supposed to save such stuff to.

If I'm online between the hours of 2:00 p.m. and 10:00 p.m. on Wednesdays, 6:00 p.m. and 6:00 a.m. Thursday nights, 10:00 p.m. and 6:00 a.m. Friday nights, or 6:00 p.m. and 6:00 a.m. Saturday nights, there's about a 99% chance I'm using my workstation here.

I suppose I could just memorize the URL, though.

 

[Fangu]

Have Yop set up a redirect, like /login

And fwiw, I'm with Yop, Tres and Demps on this. idk why you want to hide the Wordpress footer anyway. The site runs entirely on Wordpress. For free. Anyone can see right away the site isn't customware of any kind

 

[Flintlock]

It's not so much that I want to hide it, rather that the theme hides it and I didn't choose to add it back in. I'm certainly not trying to pretend that we're not running on Wordpress but I don't see why we need to advertise it either.

You say you're "with Yop" &#8211; when did he weigh in on this?

Setting up a /login redirect would be neat. Not that /wp-admin is particularly hard to remember, IMO.

 

[Fangu]

I counted Tres twice

 

[Flintlock]

FWIW, the default "powered by Wordpress" footer doesn't even include a login link. If I recall correctly, we added it to our previous theme with a widget.

 

[Cthulhu]

Aight so, thoughts:

* Admin links should probably be hidden, especially if you're not logged in in the first place; one of the security hints they give is to change the url of the admin page from something other than wp-admin, which already stops a lot of the bots trying to h4x0r.
* I can either set up a redirect, or a move from wp-admin to login if you guys would like that. changing it to /login would probably do that security thing too.
* I / we can also set up a link from the home page if you really want to, iirc the login as both a user and admin goes through the same page? Not actually sure.
* I would actually like the people that work on / with the site to have some basic knowledge on how to work with it. IIRC I made some documentation a long time ago, but, idk if that's still relevant. But just bookmark it or find the documentation, or something.

 

[The Twilight Mexican]

I'm cool with whatever now. I'll probably remember the wp-admin thing now that it's been discussed and I've seen it enough.

 

[Flintlock]

I took out the all-caps transformation from our main article titles on the index page because I got fed up of feeling like my titles were shouting at people. Bonus effect is that I was able to increase the font size a bit. No-cache refresh, yada yada.