Direct Link | The Blog Pros

May 5, 2022

How to Find Your Saved Drafts in WordPress (Beginner’s Guide)

Are you trying to find your saved drafts in WordPress?

Most of the time it’s easy to find your drafted posts and pages, but sometimes they can go missing.

In this article, we will share several ways to find your saved drafts in WordPress.

How to find your saved drafts in WordPress

Why Can’t You Find Your Saved Drafts in WordPress?

When you’re getting started with your WordPress site, it takes time to learn the admin area.

You might save a draft, and then move on to another task. Then when you want to continue working on that draft, you may struggle to find your post.

It may be in a place you don’t expect, or it may have been accidentally deleted, especially if you have a multi-author blog with other users who have access to your drafts.

If you can’t find your draft, don’t panic. Even if it was deleted, there are still ways to get it back.

In this guide, we will cover five different ways to find your saved drafts in WordPress. If you prefer to jump straight to a particular method, then you can use the links below.

Check the Quick Draft Box for Missing Drafts
Find Missing Drafts in the WordPress Pages and Posts Menus
Use the Direct Link to View all Your WordPress Post Drafts
Check Your WordPress Trash for Missing Drafts
Check Your WordPress Database to Recover Lost Drafts

Check the Quick Draft Box for Missing Drafts

If you used the Quick Draft tool in the dashboard, then your drafts may seem to vanish when you click on the ‘Save Draft’ button.

If you recently created the draft, then you should still be able to find it in your WordPress Dashboard.

Simply click on ‘Dashboard’ in the left-hand menu and find the Quick Draft box. You’ll see all of your most recent drafts in this box.

To carry on working on any of these drafts, simply click on its blue title.

If the Quick Draft section is missing, then you can bring it back by clicking on the Screen Options tab on the top right of the page.

Just make sure the ‘Quick Draft’ checkbox is checked, and it should reappear.

Find Missing Drafts in the WordPress Pages and Posts Menus

Another easy way to find your saved drafts in your WordPress blog is to head over to Posts » All Posts for your posts, or Pages » All Pages for pages.

Once you’ve done that, you should see a ‘Drafts’ tab.

After clicking on the Drafts tab, you’ll see all of your saved draft posts.

You can now see options to edit, trash, or preview any of these posts by hovering your mouse over the draft.

Use the Direct Link to View all Your WordPress Post Drafts

Another option is to jump straight to the ‘Drafts’ screen using a direct link.

To start, make sure you’re logged into your WordPress dashboard. For more information, please see our guide on how to find your WordPress login URL.

Once you’ve done that, you’ll need to add some text to the end of your website’s URL. This text will be different depending on whether you want to see your drafted posts or pages.

To find all of your drafted posts, add the following to the end of your website’s URL:

/wp-admin/edit.php?post_status=draft&post_type=post

For example, if your website’s URL was ‘www.example.com’ then you would need to paste the following into your browser’s address bar:

www.example.com/wp-admin/edit.php?post_status=draft&post_type=post

The URL for your drafted WordPress posts

Then just press the Enter key on your keyboard. You will now be redirected to a screen showing all your drafted WordPress posts.

To see all of your drafted pages instead, add the following to the end of your website’s URL and press Enter:

/wp-admin/edit.php?post_status=draft&post_type=page

Once you’ve done that, WordPress will show a screen containing all of your drafted pages.

The URL for your drafted WordPress pages

Check Your WordPress Trash for Missing Drafts

Have you checked the ‘Drafts’ tab, but still can’t find your drafted page or post?

If a draft is missing, there’s a chance it may have been deleted by accident. If you’ve added other WordPress users or authors to your site, then it’s possible someone else may have deleted your draft.

Luckily, WordPress makes it easy to restore deleted posts and pages.

Just like your computer, WordPress moves deleted items into a ‘Trash’ folder. These pages and posts will no longer show up in your ‘Drafts’ tab, but they’re not deleted permanently right away.

By default, WordPress will keep items in the trash folder for 30 days. If you want to change how often your trash is emptied, then please see our guide on how to limit or disable the trash being automatically emptied in WordPress.

To look inside your trash folder, either go to Pages » All Pages, or Posts » All Posts.

Once you’ve done that, simply click on the ‘Trash’ tab.

Here you’ll find all your deleted posts or pages. If you see your missing draft, then hover your mouse over it.

After that, just click on the ‘Restore’ link.

Now, you can find this drafted page or post in your ‘Drafts’ tab following the same process described above.

Check Your WordPress Database to Recover Lost Drafts

Can’t find the missing draft in your WordPress ‘Trash’ folder?

Another option is to check your WordPress database. You can’t recover the deleted draft using this method, but you can get its content.

Once you do, then you can copy and paste it into a new draft in your WordPress admin area.

This method is more advanced, so it isn’t recommended for absolute beginners.

If you decide to go ahead with this method, then it’s a good idea to create a backup. Backups allow you to quickly restore your WordPress site in case something bad was to happen. You can see our expert pick of the best WordPress backup plugins to get started.

To reach your WordPress database, you’ll first need to log into your web hosting account. This is usually supplied by your WordPress hosting provider.

For example, if you’re a Bluehost customer then you just need to log into your cPanel dashboard.

Once you’ve logged into your control panel, look for any ‘phpMyAdmin’ settings. For Bluehost customers, you need to click on Advanced » phpMyAdmin in the left-hand menu.

You can then click on the ‘Databases’ tab.

In the left-hand menu, find the name of your WordPress database.

NOTE: If you’re not sure what your database name is, then you can find this information in your wp-config.php file.

In the left-hand menu find an option that has ‘posts’ in its name. Then, click to select this option. You will now see all of your WordPress posts and pages.

Next, find the draft that you want to restore.

You can then go ahead and click on its ‘Edit’ button.

Once you’ve done that, phpMyAdmin will show this draft in HTML format.

To restore this draft, simply copy everything in the ‘post_content’ section.

Now it’s time to switch back to your WordPress admin screen. Here, you can create a new WordPress page or post.

In the upper-right corner, click on the icon that shows a line of dots.

After that, click on ‘Code editor.’

This will open this page or post in the WordPress code editor.

Now simply paste the HTML code you copied in the previous step. Once you’ve done that, click on ‘Exit code editor.’

You’ll now see all of the content you copied from your WordPress database. To check how this draft will look to the people who visit your website, click on the ‘Preview’ button.

You can now work on this draft in the WordPress editor. For example, you’ll want to give your new draft an SEO-friendly title and add a focus keyphrase.

We hope this article helped you learn how to find your saved drafts in WordPress. You may also want to see our guide on how to add keywords and meta descriptions in WordPress, and see our expert pick of the best WordPress SEO plugins and tools that you should use.

If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.

The post How to Find Your Saved Drafts in WordPress (Beginner’s Guide) first appeared on WPBeginner.

July 27, 2020

CSS Vocabulary

This is a neat interactive page by Ville V. Vanninen to reference the names of things in the CSS syntax. I feel like the easy ones to remember are “selector,” “property,” and “value,” but even as a person who writes about CSS a lot, I forget some of the others. Like the property and value together (with the colon) is called a declaration. And all the declarations together, including the curly brackets (but not the selector)? That’s a declaration block, which is slightly more specific than a block, because a block might be inside an at-rule and thus contain other complete rule-sets.

Direct Link to Article — Permalink

The post CSS Vocabulary appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

June 30, 2020

Five 5-minute Videos from Ethan on Design & Accessibility

Ethan:

I’ve been working with Aquent Gymnasium to produce a series of five short tutorial videos, which have been launching over the course of this past week. Since the last video just went live, I’m thrilled to share the whole list with you:
• Introduction to using VoiceOver on macOS
• Designing beautiful focus states
• Flexible and accessible typesetting
• Responsively designing with viewport units
• Designing beautiful and accessible drop caps

Five minutes is a real sweet spot for a how-to video. Ain’t no time to screw around. I loved every minute of these.

Direct Link to Article — Permalink

The post Five 5-minute Videos from Ethan on Design & Accessibility appeared first on CSS-Tricks.

June 16, 2020

Web Engine Diversity and Ecosystem Health

As front-end developers, our job is working with browsers. Knowing how many we have and the health of them is always of great interest. As far as numbers go, we have fewer recently than we have in the past. It’s only this month that Edge is starting to auto-update browsers to the Chromium version, yet another notable milestone in the shrinking number of browsers.

A few years back, Rachel Nabors likened the situation to a biological ecosystem and how diversity means health:

If we lose one of those browser engines, we lose its lineage, every permutation of that engine that would follow, and the unique takes on the Web it could allow for.
And it’s not likely to be replaced.

A huge consideration in all this is the open-source nature of what we have left. Remember that Microsoft’s browser technologies were not open-source. Brian Kardell:

In important ways, we are a more diverse, efficient and healthier ecosystem with the three multi-os, open-source engines we have left (Blink, Gecko, and WebKit) than when we had had more and were dominated by projects that weren’t that at all.

As a followup Stuart Langridge touches on another kind of diversity:

What’s really important is diversity of influence: who has the ability to make decisions which shape the web in particular ways, and do they make those decisions for good reasons or not so good?

Here’s hoping that the browsers we have left will continue to evolve, perhaps even fork, and find ways to compete on anything except standards. While the current situation isn’t as bad as perhaps some folks were worried about with the loss of Microsoft’s engines (and maybe it’s even a good thing), it would certainly be bad news if we lost even more browsers [nervously glancing at Firefox], both in shrinking numbers and shrinking diversity of influence.

Direct Link to Article — Permalink

The post Web Engine Diversity and Ecosystem Health appeared first on CSS-Tricks.

May 8, 2020

prerender.js

This is another player in the game of rendering the page of the link that you’re about to click on before you click it. It’s like getting a decent performance boost for extremely little effort.

Instant.page is another one, and I’ve been sufficiently convinced by its methodology to the extent that I run it here on this site right now. I don’t really know the difference between the two. And they aren’t the only players either. Google has quicklink and there’s guess-js for really exotic preloading.

It’s a bit of a pity that Safari and Firefox don’t support <link rel="prerender">, as it really seems to me the absolute easiest way to pull this off would be to drop that on the page where, on mouseover of a link, it points to the href of that link.

Direct Link to Article — Permalink

The post prerender.js appeared first on CSS-Tricks.

May 7, 2020

Creating an Accessible Range Slider with CSS

The accessibility trick is using <input type="range"> and wrestling it into shape with CSS rather than giving up and re-building it with divs or whatever and later forget about accessibility.

The most clever example uses an angled linear-gradient background making the input look like a volume slider where left = low and right = high.

Direct Link to Article — Permalink

The post Creating an Accessible Range Slider with CSS appeared first on CSS-Tricks.

May 6, 2020

How to Create Custom WordPress Editor Blocks in 2020

Peter Tasker on creating blocks right now:

It’s fairly straightforward these days to get set up with the WP CLI ‘scaffold’ command. This command will set up a WordPress theme or plugin with a ‘blocks’ folder that contains the PHP and base CSS and JavaScript required to create a custom block. The only drawback that I noticed is that the JavaScript uses the old ES5 syntax rather than modern ESNext. Modern JavaScript allows us to write more concise code and use JSX in our custom block code.
You can also use the ‘create-guten-block’ tool by Ahmad Awais. It gives you a lot of the boilerplate stuff you need out of the box, like Webpack, ESNext support etc. Setting it up is fairly straightforward, and it’s similar to Create React App.

I’ve used create-guten-block for the handful of custom blocks I’ve made so far, and have found it a pretty nice experience.

But… I feel like I just sort of lucked into being comfortable with all this. I have one foot in WordPress development and just so happen to have one foot in React development. Building blocks with both technologies together feels decently natural to me. If blocks were Angular or something, I feel like I might not have even given it a shot.

I’ll echo this sentiment:

I also found it really annoying working on a block that’s actively changing in code. Every time you reload Gutenberg, you’ll get the “This block appears to have been modified externally…” message because the markup of the block has changed.
I get why it’s throwing the error, but it slows you down.

At the end, Peter mentions the approach of building blocks that Advanced Custom Fields has. It almost feels like a weird bizarro-reverso world. The ACF approach seems more like what WordPress would have done in a normal world (building blocks with just PHP and templating) and third-parties would be the ones adding all the fancy React stuff.

Direct Link to Article — Permalink

The post How to Create Custom WordPress Editor Blocks in 2020 appeared first on CSS-Tricks.

April 29, 2020

Click Once, Select All; Click Again, Select Normally

A bonafide CSS trick from Will Boyd!

Force all the content of an element to be selected when clicked with user-select: all;
If you click a second time, let the user select just parts of the text as normal.
Second click? Well, it’s a trick. You’re really using a time-delayed forwards-ending @keyframes animation when the element is in :focus to change it to user-select: text;

Will’s article has a bunch of more useful information and use-cases for user-select.

Direct Link to Article — Permalink

The post Click Once, Select All; Click Again, Select Normally appeared first on CSS-Tricks.

April 26, 2020

The Cost of Javascript Frameworks

I expect this post from Tim Kadlec to be quoted in every performance conference talk for the next few years. There is a lot of data here, so please check it out for yourself, but the short story is that JavaScript-framework-powered sites are definitely heavier and more resource-intensive than non-JavaScript-framework-powered sites. Angular is the beefiest and React is hardest on the CPU. But as Tim says:

… it says very little about the performance of the core frameworks in play and much more about the approach to development these frameworks may encourage

Another big caveat is that there isn’t data here on-site usage after first-load, which is a huge aspect of “single-page app” approaches.

Still, while you can be performant with frameworks (although even that top 10% isn’t super encouraging), the frameworks aren’t doing much to help what has turned into a bad situation. It mimics exactly what we talked about recently with accessibility. It’s not the frameworks “fault” exactly, but they are also the best positioned to stop the bleeding.

Direct Link to Article — Permalink

The post The Cost of Javascript Frameworks appeared first on CSS-Tricks.

April 17, 2020

Pseudo-Randomly Adding Illustrations with CSS

Between each post of Eric Meyer’s blog there’s this rather lovely illustration that can randomly be one of these five options:

Eric made each illustration into a separate background image then switches out that image with the nth-of-type CSS property, like this:

.entry:nth-of-type(2n+1)::before {
   background-image: url(image-1.png);
}

.entry:nth-of-type(3n+1)::before {
   background-image: url(image-2.png);
}

.entry:nth-of-type(4n+1)::before {
   background-image: url(image-3.png);
}

.entry:nth-of-type(5n+1)::before {
   background-image: url(image-4.png);
}

This seems like a good time to plug our very own little :nth Tester tool. It definitely helps me understand what something like (2n+1) means in English. You can type in any string you like and see what effect that has on your site:

Anyway, back to Eric’s post. As he mentions, his technique is pseudo-random in that it looks like a random image on the page but it technically isn’t. Either way, I think it’s a really lovely technique! And it certainly breaks up the visual monotony that happens when you’re looking at a website for too long.

Here’s what it looks like in practice:

Lovely stuff!

Another way to do this is to use random numbers in CSS. For example, we could set a variable in JavaScript and then apply it with CSS custom properties. Or we could put all the images in a single sprite file and change the background-position based on a random number.

This is definitely one of those things in CSS where there are no wrong answers; just different ways to do the same awesome thing!

Direct Link to Article — Permalink

The post Pseudo-Randomly Adding Illustrations with CSS appeared first on CSS-Tricks.

April 2, 2020

Rethinking Code Comments

Justin Duke asks if treating code comments like footnotes could help us understand the code in a file better. In his mockup, all the comments are hidden by default and require a click to reveal:

What a neat idea! Justin’s design reminds me of the way that Instapaper treated inline footnotes.

I guess the reason I like this idea so much is that a lot of comments don’t need to be read constantly, — they’re sort of a reminder that, “Hey, this needs work in the future” or “Yikes, this is weird and I’m sorry.” Keeping these comments out of the code makes it much easier to scan the whole file, too.

I do wonder if there could be a toggle that shows every comment, just in case you need to read all the comments in sequence rather than clicking to toggle each one.

Anyway, all this talk about comments reminds me of an absolutely fantastic talk by Sarah Drasner at JSConf this year where she discussed why comments are so dang hard to get right:

Direct Link to Article — Permalink

The post Rethinking Code Comments appeared first on CSS-Tricks.

March 31, 2020

Max Stoiber’s Strong Opinion About Margins

Going with that title instead of the classic developer clickbait version Max used. ;)

We should ban margin from our components.

Don’t use margin?! This thing I’ve been doing my entire career and don’t have any particular problems with?!

Well, that’s not exactly Max’s point. The point is that any particular component doesn’t necessarily know what context it is in, so it also doesn’t know what kind of spacing is necessary around it. His solution? Leave it to a parent component.

I don’t have any particular problem with that. Then again, constructing things can sometimes feel overwhelming when you’ve got a route component wrapping a query component wrapping a styled component wrapping a state machine component wrapping a spacer component wrapping some kind of semantic template. If that sounds like a lot, I bet a lot of y’all’s JavaScript-built codebases nest much deeper than that already.

In this world of component-driven front-ends, we need to make sure we don’t end up with such thick soup we can’t reason through it.

This also reminds me of a bold prediction from Adam Argyle, that the use of margin will decline entirely as gap is used more heavily in all-flexbox-and-grid situations.

Direct Link to Article — Permalink

The post Max Stoiber’s Strong Opinion About Margins appeared first on CSS-Tricks.

March 30, 2020

gqless

This is so cool. I mean, GraphQL is already cool. It’s very satisfying to write an understandable-looking query for whatever you want and then use that data in templates.

But what if you didn’t have to write the query at all? What if you just wrote the templates pretending you already had the data, and the query built itself? I haven’t even tried this project yet but it feels like how things should be.

Reminds me of how Perch CMS doesn’t ask you to model data up front. You build page templates, and the CMS creates data entry pages based on the data you need in the template.

Direct Link to Article — Permalink

The post gqless appeared first on CSS-Tricks.

March 30, 2020

How They Fit Together: Transform, Translate, Rotate, Scale, and Offset

Firefox 72 was first out of the gate with “independent transforms.” That is, instead of having to combine transforms together, like:

.el {
  transform: translate(10px, 10px) scale(0.95) rotate(10deg);
}

…we can do:

.el {
  rotate: 10deg;
  scale: 0.95;
  translate: 10px 10px;
}

That’s extremely useful, as having to repeat other transforms when you change a single one, lest remove them, is tedious and prone to error.

But there is some nuance to know about here, and Dan Wilson digs in.

Little things to know:

Independent transforms happen first. The transform property happens last and stacks on top of what has already been done, which can get confusing¹.
They all share the same transform-origin.
The offset-* properties also effectively moves/rotates elements. Those happen after independent transforms and before transform.

Claus Colloseus wrote in to fix some issues in this post and clarify just how confusing this can be. For example, rotate: 45deg; transform: rotate(-45deg); will do nothing as both of them will apply and effectively cancel each other out. So shouldn’t translate: 50px 0; rotate: 45deg; transform: translate(-50px, 0) rotate(-45deg); also all cancel out? No, because of the ordering, the end result is like translate(14.6447px, -35.3553px).

Direct Link to Article — Permalink

The post How They Fit Together: Transform, Translate, Rotate, Scale, and Offset appeared first on CSS-Tricks.