More and more often I keep seeing posts asking about what’s going on with their site when only the homepage seems to be working. Even developers are sometimes caught off-guard when this happens. This little quick tip should help you out in roughly 99.99999999% of the time.
So how would you fix this? Simple. Just re-save the permalinks. That’s literally all there is to it.
To do so, what you’ll need to do is head over to the “Permalinks” settings page. You can find this page by hovering over the “Settings” option in the left sidebar of the admin and then selecting “Permalinks”.
Once the page loads, you don’t even have to touch any settings. Simply click the blue “Save Changes” button that is near the bottom of the page.
Now, it may be cause for alarm when your site has been running great for a while and suddenly your subpages don’t work. In those situations, re-saving the permalinks will also work but you will also want to look for the root cause of why they broke. Otherwise, you may end up re-saving them every other week. In general, you’ll want to consider what plugins you installed last, and what plugins have been updated recently.
If re-saving your permalinks doesn’t fix this issue (I can almost guarantee that it will, but you never know), find me on Twitter and I’ll help you figure it out.
Disclaimer: This post is a bit humble-braggy. You’ve been warned.
People that know me will know that I’m comfortable in my little shell that allows me to do my thing in the background. Like a Roadie (by Tenacious D).
Since finding and fixing my first WordPress bug (told you, humble-brag), I’ve been mainly lurking in Slack and not getting involved very much (mainly time related, to be fair).
Until, in early February, I noticed that the WordPress accessibility team was calling for testers. This has been a catalyst in getting involved more, especially since testing doesn’t need much more than experience with WordPress. Screen reader experience and experience navigating with the web with just a keyboard are nice to have and will allow you to test more. But really, accessibility is more than just that, being able to understand what’s going on and how to interact with WordPress functionality is also a very big part of it. If you’re at all interested in contributing, sign up to become an accessibility tester and get started today!
But I digress.
My testing contributions quickly put me in a place where I could help more, leading to getting more involved in the accessibility meetings, test results, ticket reporting, and ultimately get added to the Make Accessibility blog to help in posting test and meeting summaries.
None of this would have been possible were it not for the awesome Andrea Fercia and Rian Rietveld, who have both been really helpful.
In the mean time, Adam and I have geared up to start writing plugins in our spare time. We finalised the development and got our very first plugin ready for release this week. I’ve used it on my website, and I can obviously recommend it if you’re interested in having your post series organised. You can download it from the Our Post Series Manager plugin on WordPress Plugin Repository.
Where will this go from here? Who knows. More plugins, surely. Hopefully I will also be able to find more time to help Andrea with developing patches for the bugs we find.
Accessibility is not just for developers. It is probably much more important when you’re a content manager/webmaster/marketing associate. You’re constantly writing content in WordPress long after a developer is done with the website and so it’s important to know how to make use some of the tips described here while you’re doing it.
So how would you go about this?
Get an “accessibility ready” theme, or have one built
All your efforts will go to waste if the theme that is installed on your website doesn’t do anything with the additional data you’re putting in. This goes specifically for what is being put in outside of the main content area or pages that are generated. For example, the featured image, the blog feed, or a predefined page template. Let alone if it doesn’t even have any :focus styles defined.
Can’t find anything you particularly like in the WordPress repository? Find a developer that will build one for you. You can email me if you’d like me to work with you to build an accessible theme with a stunning design.
Descriptive links
At the very least, try and make the text you’re turning into a link very clear. Click here is a very poor way to tell people what is going to happen when they actually do activate the link. If it’s impractical to describe your link in the link’s text, then make use of the title field to add that Rick Roll. See also the image below.
You will want to make an effort to make the link text as descriptive as possible. The title attribute isn’t exposed to users by most browsers, and screen reader users are very likely to have it disabled in their screen reader because of blatant abuse. If you really need your link text to be short (“Read More” links, or something else where the context is visually clear) you can use hidden “screen reader text”. This will require some basic HTML chops, however.
When adding an image to WordPress, it will add a title to the image but not much else. And more often than not, this title is pretty meaningless. If you’re adding images to your post, you will want to make sure to enter the “Alt Text” that describes your image to those that cannot see it.
Is the image not important enough for the context of your page? Consider adding a blank alt attribute, ie, alt="". WordPress will do this for you automatically if you leave the “Alt Text” and “Title” fields empty. It’s important to also remove whatever text is put in the “Title” field, because otherwise this will be used as the alt.
The fields to enter this information, where applicable, are on the right side of the media library.
Provide text alternatives!
This is something specific for content management, though your developer can most likely assist you in tackling this. When you embed audio or video, you will want to make sure you have a transcription of the content available. For video you will want to ensure to provide captions when it’s important for someone to be able to see what’s going on in the video. For example, a clip from a TV show or a play.
There’s a few ways to provide these transcriptions. If it’s part of a larger post and the clip is short, or if it’s the main content for the post, you can generally provide the transcript in line with the rest of the text. If it’s not, you may want to consider moving the transcript to a separate page and link to it.
Write readable content
I can’t tell you how to do your job. If anything, I could probably use some writing classes myself. I do, however, want to underline the importance of writing readable content. People with dyslexia will thank you for keeping your sentences simple.
Besides that, don’t overload your pages with images, or use an intense variety of styles, colours, and fonts. This will ensure your page looks clean and inviting to read.
Still need help?
Let me know! If there is something in this post you don’t fully understand, I probably did not do a good enough job explaining it. Feel free to leave feedback with this form, or hit me up on Twitter.
We’ve all been there. Happily writing our PHP for some template or another. But then you save your file and refresh the page and…the screen stays completely white.
So why does this happen? Most likely you’ve made a syntax error somewhere. Like, say, forgetting a semi-colon or curly bracket. Another reason is that you’ve reached the memory limit of your server. The latter will usually happen when you enable a particularly poor plugin or theme.
The reason this comes up as a white screen of DOOM is because your errors are being suppressed.
While this isn’t necessarily a bad thing on a production server (though, you do test your code before pushing it live, right? Right?), it can be very inconvenient while you’re developing a new template or WordPress plugin.
To get rid of this inconvenience on a development server is fairly simple. All you need to do is open up your wp-config.php file and locate the line that says: define('WP_DEBUG', false);. Change false to true and you should be good to go. If it’s not there, you can add it anywhere above where it says /* That's all, stop editing! Happy blogging. */.
Should this not work (it’s somewhat unlikely, but it’s possible), you can also set PHP’s error reporting on the fly.
And there’s that. My first quick tip. I’ll most likely post more of these in the future. If you’re still having issues with errors plaguing your WordPress website, drop me a line and we’ll figure it out together.
Lately I’ve been trying to get more active in the community of Orlando developers. Specifically for WordPress, since that’s what we’re using the most at Highforge. I’ve been attending WordPress meetups and felt it was time to start putting my coding skills to good use on the software we use and love.
WordPress has various ways for people to contribute. From Core contributions, to support, to documentation, there’s something to do for everyone. I can recommend heading over to Make WordPress and finding out what you can do.
Since I’m not a hardcore programming dude (yet) and am of more use on the front end of things, I decided to start out contributing to accessibility. This, in theory, should work out really well for me since it will help expand on my knowledge of accessibility by absorbing the expertise of the people at the a11y project while at the same time being able to fix the bugs we find.
Earlier this week WordPress 4.0-RC1 was released, making for the perfect jump in point to get started with testing, fixing, and contributing. Right off the bat I had found a bug: When using the tab key to browse through the admin section, I was unable to get to my multisite’s Network Admin page(My Sites -> Network Admin -> Dashboard). Instead, when selecting “Network Admin”, it seemed to close the menu completely.
“Excellent!” I thought. I had first read this thread and followed the instructions on posting my findings in the Alpha/Beta support forum. It quickly became apparent that this issue has been around longer and as such wasn’t technically an Alpha/Beta type issue.
In either case I would have had to create a ticket in the WordPress issue system “trac”. The main difference is that I’d be reporting the bug for version 3.9.2, as opposed to trunk (the most recent development version in SVN).
For those interested, here’s the link to my ticket: 29422.
The best part about the bug I’ve found, really, is the fact that it’s also fairly simple to fix. And so, not only did I get to contribute by filing a bug report, but I also got some experience with submitting patches for review.
Getting set up and actually fixing the bug is a story for another time, though. As I’ve just found out, I can easily keep rambling on the details of the fix and triple this post in size. But since it’s mostly code-related, I’ll end this post here and I’ll owe you the code stuff.
As always, feel free to ask me anything. If you need more help getting involved with WordPress, I may not be the perfect person to ask, but I will do my best to at least set you on the right path.
