Simple big tips for common frustrations in webdev

[torrent-empress]

Wanted to drop a tip because everything keeps getting trapped in discords and dead reddits and since we're trying to make sure things actually surface in this version of the web, I wanted to maybe start a random big tips thread for webcrafting based on extremely frustrating webdev/Webcrafting issues that could be fixed by simple fixes.

I wanted to start one that I thought would be good to post:

I had a problem where my links kept breaking in neocities and I could not for the life of me figure out why: Turns out that because Neocities is run off of Linux - all file names should be in lowercase to make sure that they don't break - apparently linux and MacOS files are case sensitive but not windows. (The one time Windows did something good for UX)

I would love to get a thread like this: Cuz there's so many spaces and resources to *start* making a website - but not so much about the actual maintenance of it all and common weird problems.

[mretn_]

actually Mac files are not case sensitive if your file system is set to be as such

⚑ Moderators Note ⚑

Note to mretn_: Please expand posts to provide context and meaning following the posting guide.

Context: mretn_ is describing the fact that mac harddrives can be formatted for case-sensitive or case-insensitive files. However all macs are case-insensitive by default and it requires a reinstall to change. Its uncommon for macs to be configured for case sensitivity, normally only businesses do it to fit into their workflow better.

[lakes]

I had a problem where my links kept breaking in neocities and I could not for the life of me figure out why: Turns out that because Neocities is run off of Linux - all file names should be in lowercase to make sure that they don't break - apparently linux and MacOS files are case sensitive but not windows. (The one time Windows did something good for UX)

I checked to make sure the case sensitive thing applied to my distro and not just some specific one they were using, and sure enough, it was true.
I can't speak for MacOS though because I've never tried it.

[Dan Q]

Two tips related to your browser debug tools:

1. They're almost always more-powerful than you think! It's not just "inspect element". You can "edit at HTML" those elements or drag-drop them around the DOM. You can edit CSS (I do about half of my development this way: editing CSS in the browser until I get the look I want and then copying my changes back into my code!). You can link the CSS you're editing to your filesystem so the changes you make get saved into a file. You can look at exactly what's being requested from the network. You can disable caching. You can have JavaScript code pause when it hits a particular line so that you can check what every variable contains (or even change them) and you can run JavaScript code at any time. You can use it on other people's sites, not just your own. You can see what's in your cookies and localStorage and edit those values. You can "block" particular URLs from loading or edit how they're loaded. You can simulate smaller screens and slower connections. You can work out exactly which font is being rendered to a page (and download a copy for your own use!). There's so much power in modern browser dev tools, and most developers only scrape the surface.

2. That said... your debug tools (especially Inspector) can be misleading! It's worth learning and remembering that what you see in Inspector might look like HTML code... but it's not. If you want to see the actual HTML code you want View Source. The Inspector shows you what happens when the browser interprets the HTML code (including running any JavaScript!), and then represents that back to you as if it were the original HTML!

So yeah: (a) know what your debug tools can do, because it's more than you'd think, and (b) know what your debug tools don't do, because there's one particularly-deceptive edge case (View Source and Inspector work very differently and show different things)!

[Noah_S]

There are multiple ways to get the result you want. I've made it a goal to learn one new thing in coding for every thing I make. And it doesn't have to be perfect the first time. It's possible to go back and edit what you've already made.

I did both of these things with my template picker. At the joomla forum people were telling me that no one knows how to make one with more options than light/dark, but that I would have to code database interactions somehow. I most certainly didn't have to do that, I made different templates call for different menus and set the template for the menu links. And recently I went back and added template previews after learning how to load images based on option value in a select form.

If something feels overwhelming, break it into smaller steps. What's needed to make it functional, even if it's not perfect? Which parts do you already know how to make from something you've made before? Start with that. I've found that seeing the result of that almost always makes it easier for me to figure out how to find a tutorial for the rest.

[lakes]

If you open an xml/rss/etc file in your browser, it will not only tell you if there's an error, but tell you which line has the earliest error.

[Seechain]

I had a problem where my links kept breaking in neocities and I could not for the life of me figure out why: Turns out that because Neocities is run off of Linux - all file names should be in lowercase to make sure that they don't break - apparently linux and MacOS files are case sensitive but not windows. (The one time Windows did something good for UX)

I would love to get a thread like this: Cuz there's so many spaces and resources to *start* making a website - but not so much about the actual maintenance of it all and common weird problems.

Canonical event!!

It happened to me the first time I tried something with a DSC_1234.JPG file from a camera.

Now when I see an uppercase filename, I immediately convert it to lowercase without even questioning why.

MELONLAND-FORUM.GIF -> melondland-forum.gif 

Other canonical events:

    The first time you have to set permissions to 644 or 755 on a file.

    The first time you have to touch .htaccess for a configuration.

    The first time you edit php.ini

    Your first cron job.

-----------------------------------------------------------------------------------------------------------------
When starting a website, you need to think about making things easier for the maintainer (surprise it’s you). For example, being organized and descriptive with files. I recommend being ridiculously organized even if the site is small, even if you think you’ll only have a handful of images. I think dumping all images into a single folder and then suffering while trying to locate a specific one is another canonical event. (To be honest, I always make this mistake because I'm lazy.) 

[TheFrugalGamer]

Here's a small one that I learned long ago: always, always, always do a "hard" refresh when viewing your website over a "soft" one. Basically this means that the browser dumps the cache and re-loads everything directly from the server instead of relying on the cached files it's grabbed. Since you want to see the latest version of your site to make sure everything looks good (especially when you're editing the layout), you never want to use the cached files to view anything.

On Firefox (and I think a few others), you can do this by holding the "shift" key when you click the Refresh button on he address bar. You'll know it worked because you'll see the screen clear when it re-loads the page. If that's not doing the trick, there's a plugin called "Clear cache" that adds a button you can click, and it will immediately dump any related files your browser has grabbed for the current website.