WordPress 4.8 Increases Maximum Width of the Customizer Sidebar to 600 Pixels

WordPress 3.4 introduced the WordPress Customizer API and over time it has evolved from being a theme customizer to a framework for live-previewing changes to WordPress.

Since its inclusion, one of the most common complaints about the Customizer is its narrow sidebar. Even on widescreen monitors, the Customizer sidebar is only 300px wide.

This limitation was one of the motivating factors behind the Customize Pane Resizer feature plugin created in 2015. Although Customize component maintainers tried to get the feature plugin ready in time for WordPress 4.5, it didn’t make it.

In WordPress 4.8, the Customizer Sidebar Has a Variable Width

Weston Ruter, Customize component maintainer, announced that the Customizer sidebar in WordPress 4.8 has a variable width.

“Ticket #32296 was created to allow the sidebar pane to be user-resizable with a grabber just like the Dev Tools pane in Chrome can be resized,” Ruter said.

“After a lot of back and forth, the scope was reduced to remove the user-resizable aspect and to instead address a more fundamental issue that the sidebar is exceedingly and unnecessarily narrow on high-resolution displays.”

The sidebar has a minimum width of 300px and a maximum width of 600px. What users see depends on the width of their screen. I use a 21 inch widescreen monitor and the width of the sidebar on my screen is 345px.

Customizer345PixelsWide
345 Pixel Wide Customizer Sidebar

While not a huge change, the extra width is noticeable. WordPress theme and plugin developers who have built custom controls into the Customizer are highly encouraged to test WordPress 4.8 to ensure that they display properly on large screens.

“Custom controls in plugins and themes should utilize alternative approaches to doing layout than using pixel widths,” Ruter said.

“Use of percentage-based widths or flexbox will help ensure that controls will appear properly in larger displays, while also making controls future-compatible when the sidebar width could be user-resizable.”

If you’d like to be able to adjust the width of the sidebar, check out the Customize Pane Resizer plugin. I tested it on WordPress 4.8 beta 2 and it works as expected. There’s also the Fluid Customizer plugin which also allows you to manually resize the sidebar.

How to start a blog

If you’re thinking about starting a blog, the most important thing I have to say to you is: go for it! Start your blog! Just do it! Blogging is a great SEO strategy, it’s a wonderful marketing tool and blogging is lots of fun! A new blog will allow you to make smart and strategic choices. Just take a little time to think about how to set up your blog before you begin, so you’ll have less work later on. Let me share some tips with you on how to start a blog.

Choose your niche

You should always write about what you know. But you should not write about everything you know. Pick a niche. Decide upon a main topic and write posts related to that topic. It’s more likely that your audience will come back and read your other posts if you’re writing about similar topics. People will know what to expect. Starting a mom blog implies that you write about all things concerning your children and family life. Starting a travel blog implies you write about traveling. You can write about something slightly off topic once in a while of course, but try to stick to your niche. An audience of a travel blog doesn’t expect a blog post about gardening. 

Our SEO for WordPress eBook guides you through every aspect of Search Engine Optimization »

SEO for WordPress$ 25 - Buy now » Info

Do your keyword research

Once you’ve chosen your niche, you should do some solid keyword research. Try to find out what people are searching for. What words are they using when they want to read about your niche and your topic? You should really get inside the heads of your potential audience. If you do your keyword research properly, you should end up with a long lists of keywords you would like to be found for. Try to come up with competitive, head keywords as well as with less competitive long-tail keywords.

Read more: ‘How to start your keyword research’ »

Think about site structure

This is the best time to think about site structure. What categories are popular in your niche? What are the most important head keywords you’d like to rank for? You should write a long, kick-ass article about each of these keywords. Those will be your most essential articles, or in other words, your cornerstone content. You should give those articles a prominent place on your site.

After you’ve written those beautiful cornerstone articles, write lots of blog posts on sub topics of that main topic and always link to your cornerstones. That way, you’ll be telling Google exactly what the most important articles on your website are.

Keep reading: ‘What is cornerstone content?’ »

Write that first post

Take some time to do keyword research and to think about site structure. But don’t take too much time. Just write that first post! Put pen to paper and just do it. Your blog starts with the very first post. That post doesn’t have to be perfect, it just has to be published. Need some help to get started? Check out our 10 tips on how to make your post awesome.

Pictures and videos

Writing blog post is more than writing a nice story; a successful blog has pictures and videos as well. Every post should show at least one image. Taking nice photos yourself is a great way of creating images and making short videos is a really good blogging strategy as well. Especially if you’re blogging about (aspects) of your own life, photos of it are a necessity.

Read on: ‘Images for blogs’ »

Optimize for the search engines

Before publishing your post, optimize it using Yoast SEO (on WordPress of course, but on Magento and TYPO3 now too!). Don’t forget to create an awesome SEO title and a decent snippet. Finetune your text. Make sure your text is both readable as well as SEO-friendly.

Read more: ‘How to use the content & SEO analysis of Yoast SEO’ »

Promote your blog

Using social media is the best way to reach and grow the audience of your blog. That’s why your blog should have a Facebook page. Sharing your posts on Facebook is a good marketing strategy. Don’t forget Instagram and Twitter either!

In addition to the use of social media to promote your blog, we advise you send out a digital newsletter. Let people sign up for it and send out emails with your latest blog posts and some other fun facts.

Keep reading: ‘Marketing your blog’ »

Stick with it!

The most important thing to start a blog – besides setting up your new blog – is to write that very first blog post. Once you’ve written that first post, your blog has started. You should keep on writing blog posts to make it successful, so try to determine a frequency to publish new posts. You don’t have to blog every day, once a week or maybe even once in every two weeks would be a nice frequency to start with. Find a frequency you can stick with! Your audience will know what to expect, if your blogging frequency is stable.

Read on: ‘Blog SEO: make people stay and read your post’ »

WordPress 4.7.5 Patches Six Security Issues, Immediate Update Recommended

WordPress 4.7.5 was released today with fixes for six security issues. If you manage multiple sites, you may have seen automatic update notices landing in your inbox this evening. The security release is for all previous versions and WordPress is recommending an immediate update. Sites running versions older than 3.7 will require a manual update.

The vulnerabilities patched in 4.7.5 were responsibly disclosed to the WordPress security team by five different parties credited in the release post. These include the following:

  • Insufficient redirect validation in the HTTP class
  • Improper handling of post meta data values in the XML-RPC API
  • Lack of capability checks for post meta data in the XML-RPC API
  • A Cross Site Request Forgery (CRSF) vulnerability was discovered in the filesystem credentials dialog
  • A cross-site scripting (XSS) vulnerability was discovered when attempting to upload very large files
  • A cross-site scripting (XSS) vulnerability was discovered related to the Customizer

Several of the vulnerability reports came from security researchers on HackerOne. In a recent interview with HackerOne, WordPress Security Team Lead Aaron Campbell said the team has had a spike in reports since publicly launching its bug bounty program.

“The increase in volume of reports was drastic as expected, but also our team really hadn’t had to process any invalid reports before moving the program public,” Campbell said. “The dynamics of the Hacker Reputation system really came into play for the first time, and it was really interesting to figure out how to best work within it.”

If WordPress continues to sustain the same volume of reports on its new HackerOne account, users may see more frequent security releases in the future.

WordPress 4.7.5 also includes a handful of maintenance fixes. Check out the full list of changes for more details.

What to Expect in WordPress 4.8

WordPress 4.8 Beta 1 is available for testing and has a couple of features that will likely have a big impact.

New Image, Video, and Audio Widgets

WordPress 4.8 has three new core widgets and adds a visual editor to the Text widget. Adding video, audio, or images to text widgets typically involves using custom HTML.

Each of the new widgets in 4.8 takes advantage of the WordPress Media Library. Because the widgets use the media modal, users can insert content from a URL. This is particularly convenient for the Video widget as most videos are not stored locally.

Core Image Widget

Here is what the core widgets look like on Twenty Seventeen after they’ve been configured.

Core Widgets on Twenty Seventeen
Core Widgets on The Frontend

The text widget now has a visual editor with a couple of basic formatting tools available. The visual editor supports Keyboard shortcuts. However, it does not support oEmbed. Like the post editor, you can switch between Visual and HTML mode. The HTML version of the editor benefits from the upgrade as it provides users with the same formatting tools that are available in the visual editor.

Text Widget HTML Mode
Text Widget HTML Mode

Link Boundaries

Link boundaries are a byproduct of the ongoing work to Gutenberg, WordPress’ new block-based editor. If you’ve ever written links in the visual editor, you may have noticed that sometimes it’s difficult to move the cursor outside of the link element.

In WordPress 4.8, link boundaries provide a visual cue of when the cursor is inside a link element. This video recorded by Matias Ventura provides a visual demonstration of how link boundaries work.

Inside Link Boundary
Inside Link Boundary
Outside Link Boundary
Outside Link Boundary

During testing it felt like this was more of a bug fix to how the visual editor behaves rather than a new feature.

Dashboard News Widget Includes Upcoming Local WordPress Meetups

There are 1,180 WordPress meetups registered on Meetup.com and close to 100 WordCamps scheduled for this year. In an effort to remind users of the WordPress communities that exist around them world-wide, the WordPress News Dashboard widget has been modified to include Meetups and WordCamps near a user’s location.

News Widget Shows Upcoming Meetups and WordCamps
News Widget Shows Upcoming Meetups and WordCamps

The widget will try to guess your location automatically. If it’s incorrect, clicking the Pencil button opens a box where you can type in your city. The bottom of the widget includes links to the WordPress Meetup landing page, WordCamp Central Schedule, and the WordPress.org news blog.

WordPress 4.8 Sets the Stage for Gutenberg

It should be noted that WordPress 4.8 will not include Gutenberg. It does, however, lay the foundation for Gutenberg to arrive in a future release.

The easiest way to install and test WordPress 4.8 Beta 1 is to install and activate the Beta Tester plugin on a staging site. Once activated, visit Tools > Beta Testing and select Point release nightlies and then update WordPress.

If you believe you’ve encountered a bug, you can report it to the Alpha/Beta section of the WordPress support forums. Please provide as much detail about the bug as possible. WordPress 4.8 is tentatively scheduled for release June 8th.

WordPress Is Now on HackerOne, Launches Bug Bounties

WordPress now has its own official HackerOne account where security researchers can responsibly disclose vulnerabilities to the security team. The project’s page was previously listed under Automattic’s profile before HackerOne launched its free community edition for open source projects. WordPress has now transitioned to its own account, which also includes sister projects BuddyPress, bbPress, GlotPress, and WP-CLI, along with all of their respective websites.

The WordPress Security team launched its HackerOne profile privately at first and had been inviting reporters to use it when they reported security issues via email. Having the profile public makes it possible for the team to work together on triaging the issues that are submitted. WordPress Security Czar Aaron Campbell said the new system will reduce the time spent on responding to commonly reported issues, allowing the team to spend its time more effectively.

“We have about 40 people with access to triage reports, although, like most volunteer groups, not everyone is usually triaging at the same time,” Campbell said.

The project also launched bug bounties to reward reporters for responsibly disclosing security issues and Campbell said the team has awarded more than $3,700 in bounties to seven different reporters.

“So far bounties have ranged from $150 to $1,337,” Campbell said. “Anything that qualifies for a cash bounty will be $150+. We have a few swag bounties (hoodies) for really small things that will be going out soon as well (finishing getting everything set up with the swag store to do this now).”

Campbell confirmed that $1,337 is not the upper limit of the bounties and that there are bugs that could qualify for larger bounties.

“Bounties are calculated based on bug severity, the product or site it’s on (WordPress core being weighted more heavily than say the swag store), and also the quality of the report,” Campbell said. Automattic is sponsoring the bounty payouts on behalf of the WordPress project.

SVN Syncing Issues Continued

tl;dr – Yes we know, yes we’re working on it, no you don’t need to email.

I’m really sorry about this issue, but right now literally all I know is that the tool we use to automagically schedule everything that happens after you use SVN to bump your plugins is acting like a truculent child. It’s slow, it’s dragging it’s feet, and it’s taking WAY more than six hours (which is usually the outside norm for this stuff) to finish, if it does at all. It took 36 hours for one plugin, and even then some people got weird results.

And no, we don’t really know why yet.

It’s possible this is related to the new directory. It’s possible it’s from the entire .org slowdown last week or maybe it’s because we released the Beta and everything is slow from that. We literally don’t know.

I apologize for a series of very curt emails, but with the volume of people complaining, we had to resort to an auto-reply of, basically, we know, please be patient. If I have anything else to tell you, I will post, but right now we don’t know why and we can’t magically tell you what we don’t know, so please be patient with us.

Also no, there’s not a ticket because this is actually outside the meta repository. That means it’s not open source, the part that’s busted. The people with the access are aware and yes, I’ve pushed to escalate this. But it’s the weekend and it’s Mothers’ Day in the US, so you’re just going to have to be a little extra patient.

Repository Syncing Issues

Due to a network issue in the wee hours of May 11, updates to SVN are taking longer than normal to show up on the directory. The issue created a 2 hour backlog, which normally would work itself out pretty quickly. It’s currently being exacerbated by everyone who sees their code NOT showing up right away and pushing it again.

As Otto says:

In short, when it’s being slow, then it’s being slow and nothing you can do will speed it up, so just relax, go outside, walk around, and wait for it.

Do we want to make the process faster? Of course. And if you’re interested in helping that, please check out Meta ticket #1578 to understand how it was all written for the new directory.

To remind you:

  • Changes can take a couple hours to display even on the good days. While it is generally much shorter, 6-12 hours is about when you should start wondering if something’s up, not before.
  • Multiple commits to SVN means multiple builds of your code. The more times you commit, the more builds, and the slower it goes for everyone. Commit once, then go make a sandwich.
  • Zips are built for for every tag’d release in your repository. Fewer tags, faster builds. We advocate removing older builds as they’re generally not necessary for use.
  • Patience, patience, patience. With over 60k plugins (counting the closed ones), this is a HUGE database of things.

#announcement

Server Load Woes

If you got an error like this when using SVN today, it’s not just you:

Committing transaction...:   Error: Commit failed (details follow):  Error: Error running context: The server unexpectedly closed the connection.  Completed!:

Or

Committing transaction...:   Error: Commit failed (details follow):  Error: Failed to start '/home/svn/repos/wp-plugins/hooks/pre-commit' hook  

There was a high server load on WordPress.org on Monday May 8th, which caused the system to have those errors. When it happens to you, just go make a coffee or bake a pie and come back in a bit.

#downtime, #server-load

How to Block IP Addresses in WordPress

Do you want to block specific IP addresses from accessing your WordPress site? Blocking IP addresses is used as a solution to block spam and hacking attacks on your website. In this article, we will show you how to block IP addresses in WordPress, and we will also show you how to find out which IP addresses needs to be blocked.

How to Block IP Addresses in WordPress

What is an IP Address?

If internet was a physical world, then think of IP addresses as country, street, and house numbers. They are basically 4 sets of numbers from 0-255 separated by dots and look like this:

172.16.254.1

Each computer connected to the internet has an IP address assigned to them by their internet service provider.

All visitors to your website have an IP address which is stored in your website’s access log files. This means that all websites that you visit also stores your IP address.

You can hide this information by using a VPN service. This allows you to hide your IP address and other personal information.

Why & When You Need to Block IP Addresses?

Blocking an IP address from accessing your website is an effective way to deal with unwanted visitors, comment spam, email spam, hacking attempts, and DDOS (denial of service) attacks.

The most common sign that your website is under a DDOS attack is that your website will frequently become inaccessible or your pages will start taking forever to load.

The other attacks are more obvious such as when you start getting spam comments or a lot of spam emails from your contact form. We have a list of ways to fight spam comments, but the last solution is to block IP addresses.

Finding Out IP Addresses You Want to Block in WordPress

WordPress stores an IP addresses for users that leave a comment on your website. You can see their IP address by visiting the comments page in your WordPress admin area.

IP addresses stored in WordPress comments

If your website is under DDOS attack, then the best way to locate the IP addresses is by checking your server’s access log.

To see those logs, you will need to login to the cPanel dashboard of your WordPress hosting account. Next, locate the ‘logs’ section and click on the ‘Raw Access Logs’ icon.

Raw access logs

This will take you to the access logs page where you need to click on your domain name to download the access logs file.

Download access log file

Your access log file will be inside a .gz archive file. Go ahead and extract the file by clicking on it. If your computer does not have a program to handle .gz archive files, then you will need to install one. Winzip or 7-zip are two popular choices among Windows users.

Inside the archive, you will see your access log file which you can open in a plain text editor like Notepad or TextEdit.

The access log file contains raw data of all requests made to your website. Each line begins with the IP address making that request.

IP addresses in access log file

You need to make sure that you don’t end up blocking yourself, legit users, or search engines from accessing your website. Copy a suspicious looking IP address and use online IP lookup tools to find out more about it.

You will have to carefully look at your access logs for suspicious unusually high number of requests from a particular IP address. Tip: there’s a way to automate this that we share at the bottom of this article.

Once you have located those IP addresses, you need to copy and paste them in a separate text file.

Blocking IP Addresses in WordPress

If you just want to stop users with a specific IP address from leaving a comment on your site, then you can do that inside your WordPress admin area.

Head over to Settings » Discussion page and scroll down to ‘Comment Blacklist’ text box.

Blacklist IP addresses in WordPress comments

Copy and paste the IP addresses that you want to block and then click on the save changes button.

WordPress will now block users with these IP addresses from leaving a comment on your website. These users will still be able to visit your website, but they will see an error message when they try to submit a comment.

Blocking an IP Address Using cPanel

This method completely blocks an IP address from accessing or viewing your website. You should use this method when you want to protect your WordPress site from hacking attempts and DDOS attacks.

First, you need to login to cPanel dashboard of your hosting account. Now scroll down to the security section and click on ‘IP Address Deny Manager’ icon.

IP Address Deny Manager tool in cPanel

This will take you to the IP Address Deny Manager tool. Here you can add the IP addresses you want to block. You can add a single IP address or an IP range and then click on the add button.

Blocking IP addresses in cPanel

You can come back to the same page again if you ever need to unblock those IP addresses.

When IP Address Blocking Doesn’t Work – Automate It!

Blocking an IP address would work if you are just blocking some basic hacking attempts, specific users, or users from specific regions or countries.

However, many hacking attempts and attacks are made using a wide range of random IP addresses from all over the world. It is impossible for you to keep up with all those random IP addresses.

That’s when you need a Web Application Firewall (WAF). For the WPBeginner website, we use Sucuri. It is a website security service that protects your website against such attacks using a website application firewall.

Basically, all your website traffic goes through their servers where it is examined for suspicious activity. It automatically blocks suspicious IP addresses from reaching your website altogether. See how Sucuri helped us block 450,000 WordPress attacks in 3 months.

We hope this article helped you learn how to easily block IP addresses in WordPress. You may also want to see our ultimate step by step WordPress security guide for beginners.

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 Block IP Addresses in WordPress appeared first on WPBeginner.

WordPress 4.8 Release Targeted for June 8

WordPress 4.8 kicked off in this week’s core developer meeting and the schedule for the upcoming release is now published. Beta 1 is scheduled for May 12 and the official release is targeted for June 8. This will be the first major release in 2017 and is focused on laying the foundation for the new Gutenberg editor. The schedule identifies the features that contributors are aiming to ship in 4.8:

  • TinyMCE inline element / link boundaries
  • New media widgets
  • WYSIWYG in text widget
  • WordCamp / meetup dashboard upgrade to the “news” section

Several contributors expressed concern during the meeting about the compressed timeline, as both the beta and RC testing times have roughly half the time they have been given in the past. Also, the release’s close proximity to WordCamp Europe, which officially begins activities the following week, presented additional concerns about the added workload of a release within the May/June timeframe.

“I think people are thinking of this as a normal release, a train leaving the station that a bunch of stuff (multisite! meta!) has to get on to make it in,” 4.8 release lead Matt Mullenweg said. “I agree that needs a much longer timeframe.

“What is really going on is that we have a few simple, already working as plugin enhancements that add a few files, and we want to get those in the hands of users sooner rather than later. We already update TinyMCE all the time. Potential breakage or compatibility should be limited to things that interact with the text widget or the news dashboard module.”

After a brief discussion on the dev meeting notes, the proposed schedule was confirmed. The feature project merge deadline is coming up on May 10, followed by Beta 1 two days later. Any enhancements that are not ready to proceed on this timeline will be put on hold for a future release.

2016 in Review

It’s May. I forgot to post this. Go on and laugh 🙂

Anyway. At the end of last year, I looked at all the posts on Make/Updates and manually crafted out a spreadsheet that listed all the plugins submissions, rejections, approvals and closures. And here’s how the year looked:

image

If you don’t want to calculate it all yourself, I’ve made my Google sheet sharable. I didn’t go back and do 2015, and while I do plan to do one for 2017, we will have a big gap in numbers as I don’t have a way to calculate closed plugins at the moment.

By the way, there was a higher number of closed plugins in 2016 than ever before. That’s because more people than ever have asked us to close plugins, but also because we closed plugins without a committer with a valid email address. And that was a lot of people.

#announcement

New: Group Mentorship for WordPress Developers and Agencies

Over the past few years I’ve been receiving a steady flow of incoming inquiries for mentorship, coaching, consulting and general assistance coming from WordPress freelancers, consultants, developers, agency owners and tech leads in WordPress agencies.

A technical presentation on WordPress Code Architecture at WordCamp Netherlands

Currently, I work with a small group of people who reach out once or twice a month and ask for strategic decisions, sales strategy, technical advice on building a reliable infrastructure, marketing help, getting involved with the WordPress community and so forth. Some of my peers are actively growing and I’m super stoked to see ongoing progress, reports on closing large clients, signing long-term retainers and improving their technical and business skills on the way.

More often than not, when I receive a random question or any of my peers asks for help with a specific problem, I’ve already discussed that in details over a podcast interview, a guest post for a major outlet, a technical talk or elsewhere online – including Quora as of the past few months.

As a result, I regularly have to postpone responses or simply reject mentorship requests due to practical reasons (a.k.a. lack of time).

Since I’m following some smart and experienced folks on Quora, I have bookmarked a couple of brilliant responses regarding mentorship and coaching opportunities. Here are the two nuggets by David S. Rose and Gordon Miller:

The essential paradox is that the very people you would want as mentors are exactly the same people who simply don’t have the time to serve in that role, because they’re doing the things that make them good mentors in the first place. Therefore, the best that we can do is try to figure out ways to ‘scale’ our mentoring so as to positively affect the largest number of potential mentees. That is why I spend probably half my time:

Answering questions here on Quora (nearly 6,000 of them)
Creating and publishing free videos (over 1,000,000 views)
Speaking at conferences and panels (dozens of them each year)
Doing TEDtalks (at TED itself, and in half a dozen TEDx events)
Judging business plan competitions (dozens of them each year)
Running online webinars (for NASVF/NCET2, New York Angels, etc.)
Running in-person open training sessions (NYA Educational Meetup)
Teaching at colleges and business schools (Yale, Harvard, NYU, Columbia, Stevens, Rutgers, Carnegie Mellon, IESI, etc.)
Founding and teaching at an entrepreneurship program (Singularity U)
Founding and running a tech accelerator program (AREA)
Doing group events like StartUp Grind, FreeLunchFridays, and others
Writing two New York Times best selling textbooks, one on angel investing and the other on starting a company.
Blogging, tweeting and commenting on others’ blogs

David S. Rose on Quora

 

I have learned over the years that my time is more valuable than money. The only reason that people work for a living is that the money they get paid is enough for them to justify the time they spend doing the work. And that is great if you are an employee. But when you are an entrepreneur, there is the “opportunity cost” to be considered and the “time value of money”.

For example, If I were to meet with the over 100 people that have asked me to mentor them, and even if I only spent 30 minutes a week with each of them, then that is 50 hours a week. That is 125% of the time that I have to work on new opportunities. It might help the 100 of you, but it doesn’t help me or any of my other existing businesses.

Gordon Miller on Quora

Other entrepreneurs and consultants receive mentorship inquiries as well and can’t handle each and every ask for help. Most of them also retract these to a side medium – their blog, videos of talks they have presented, or books they have written.

With that in mind, I’m starting an experimental “group mentorship” program for developers and agency owners as well. The format would be an email newsletter 2-4 times a month including tips and strategies from me and relevant links to publications I’ve written online, interviews suitable for the audience, and other helpful resources that I stumble upon over the month.

Here are some of the main topics and goals that would be targeted in my emails:

  • How to improve your skills and provide professional development services to your customers
  • What strategies do other communities employ in technical architecture and business development
  • How to structure the sales and planning processes and ensure financial stability
  • What marketing strategies are instrumental in building trust and reputability
  • How to develop a unique business model that resonates with your customers and positions you in the top charts
  • What challenges do enterprises and large businesses face while looking for a professional team or consultant for their large project
  • How to explain problems in a way that is related to the business implications

My friend Marius has suggested a Q&A panel once a month or so. That sounds reasonable and given the right volume, I can send a monthly email answering some of the general questions that most freelancers, consultants, and agency owners struggle with.

The main target group is WordPress professionals providing development and other relevant services to their business peers. Building high-quality solutions is absolutely mandatory so keep that in mind before enrolling in the experimental email mentorship program.

If you have any questions regarding the program, don’t hesitate to reach out in the comments area or via email.

The post New: Group Mentorship for WordPress Developers and Agencies appeared first on Mario Peshev on WordPress Development.

Reminder: Google Hates Widget Links

In a blog post last year, Google reminded users that widgets are cool, but widget links are the suxxor.

Widgets can help website owners enrich the experience of their site and engage users. However, some widgets add links to a site that a webmaster did not editorially place and contain anchor text that the webmaster does not control. Because these links are not naturally placed, they’re considered a violation of Google Webmaster Guidelines.

If you look at the examples, they highlight things that many plugin (and theme) developers would consider acceptable links.

What does this mean for you? It means your powered-by link may adversely impact your users. Be smart. Make your links no-follow.

Also as a reminder: Any and all powered-by links and credits must be opt-in. That is a site owner must make the conscious and informed decision to display your credits. You cannot have them show by default, you cannot have them be opt-out, and you cannot hide them in display:none code or any other way that embeds a clickable link. Code comments like <!-- Powered by WordPress --> is fine.

WordPress 4.8 Will End Support for Internet Explorer Versions 8, 9, and 10

Over the weekend, Matt Mullenweg announced that the upcoming WordPress 4.8 release will drop support for IE versions 8, 9, and 10. Core contributors have been discussing browser support for the past two months in relationship to setting technical requirements for the new editor.

Microsoft discontinued support for IE 8, 9, and 10 in January 2016, which means these versions no longer receive security updates. Mullenweg said that attempting to continue supporting these browsers is holding back WordPress development.

“I realize that folks still running these browsers are probably stuck with them because of something out of their control, like being at a library or something,” Mullenweg said. “Depending on how you count it, those browsers combined are either around 3% or under 1% of total users, but either way they’ve fallen below the threshold where it’s helpful for WordPress to continue testing and developing against.”

In an effort to determine how many people are still using these insecure and obsolete browsers, Jonathan Desrosiers collected data from three different sources. The following are numbers for global IE usage published by StatCounter’s GlobalStats, which Desrosiers said are nearly identical to WordPress.com’s numbers:

  • IE8: 0.41%
  • IE9: 0.26%
  • IE10: 0.26%
  • IE11: 3.79%

WordPress will not stop working entirely in these browsers, but after the 4.8 release contributors will no longer test new features against older versions of IE. Some capabilities in wp-admin may be more limited. Mullenweg confirmed that the next versions of TinyMCE will no support older IE versions.

Global IE usage has declined from 7.44% in March 2016 to 4.18% in March 2017. IE marketshare has been shrinking as mobile device usage has gone up. October 2016 marked the first month in history that mobile and tablet traffic exceeded desktop usage worldwide. As this trend of declining desktop usage continues, IE will likely be buried within a couple of years.

“I have been hard pressed to find a U.S. government agency running a version of IE less than 11,” WordPress lead developer Andrew Nacin commented on the announcement. “Government agency websites similarly see negligible traffic from IE < 11.”

The decision to drop support for IE 8, 9, and 10 was met with celebration from the WordPress developer community. Focusing on browsers that still receive security updates is a better use of open source contributors’ time and resources. Developers who do client work can also refer to WordPress’ IE support policy when pressured by clients to support insecure browsers.

Naturally, the topic of raising minimum browser requirements resulted in developers lobbying to drop support for PHP 5.2, which reached end of life more than six years ago. In March 2015, WordPress stats estimated PHP 5.2 usage at 16.6%, but that number has dropped steadily to 5.1% today. The task of updating a browser to the latest version was designed to be easy for users, but upgrading PHP versions is still somewhat complicated for those who are not receiving help from their hosting companies. The 5.1% on PHP 5.2 represents millions of users who would need to cross a significant hurdle into order to stay current with the latest version of WordPress.

New Plugin Offers Better Plugin Recommendations in the WordPress Admin

If you work with WordPress every day you may have learned to tune out the recommended plugins in the admin by now, but the “Add Plugins” screen is an important part of the new user experience. WordPress developers Joey Kudish and Nick Hamze have released a plugin that brings better recommendations to the admin.

Hamze contends that the first plugins that appear in the featured section have a smaller, niche audience, and are unlikely to be useful to the majority of new users.

The recommended plugins are slightly better, as they are based on plugins that the user and other users have installed. However, Hamze believes they could be tweaked even further to display plugins that specifically benefit new users. The Recommended tab was introduced two years ago to display results based on plugins that are commonly used together. It excludes plugins that users already have installed.

“I really want to help WordPress but I think what is most needed isn’t a new editor or more guidelines but rather someone to take all the stuff in this fractured ecosystem and bring it together,” Hamze said. “Get rid of all the crap and only show people the stuff worth using.”

Hamze said he doesn’t know if WordPress can solve this problem diplomatically with code. He believes manual curation is required to deliver the best new user experience. A ticket for re-thinking the default ‘Add Plugins’ tabs/filters was is open on WordPress trac, as the plugins that appear in these screens have remained unchanged for some time. The ticket hasn’t received much discussion yet.

The Better Plugin Recommendations plugin removes the default and featured recommendations tabs and includes a new recommendations tab curated by Hamze to appeal to new users. Below is an example of the first 10 recommendations the plugin includes:

Hamze uses the following criteria to select the recommended plugins:

  • Price (Free)
  • Numbers of users
  • Average Rating
  • Last Updated
  • Support Given

When asked why the recommendations don’t include Jetpack, Hamze said it didn’t seem necessary, given its high position in the popular tab and the fact that it already comes pre-installed with many hosts.

Hamze and Kudish created a web service that delivers the recommendations to sites where the plugin is installed. The node server is powered by hapi.js and is open source on GitHub

“If the idea is well received in the community, I’d love to expand on it further and include some plugins from outside the WordPress.org plugin repository in our recommendations, as I think there’s some great third-party plugins that new users should definitely know about,” collaborator Joey Kudish said.

Hamze said he doesn’t expect there to be many regular users who will find and install the plugin but hopes that hosting companies will integrate it by default for their WordPress customers.

“What I’m hoping is that I can convince the hosting companies to preinstall this (maybe in the MU folder) for their customers,” Hamze said. “The app blends in seamlessly with WordPress. There are no ads or branding. The plugin is designed solely to help new users find great plugins to help them on their WordPress journey.”

WordPress 4.7.4 Fixes 47 Issues

WordPress 4.7.4 is available and is a maintenance release that fixes 47 issues reported against 4.7. This update includes a visual editor compatibility fix for an upcoming version of Chrome.

Uploading video and audio files no longer result in broken thumbnails and the REST API received a few enhancements related to data handling. WordPress 4.7.4 also restores the ability to Shift-click a range of checkboxes.

Auto updates are rolling out but if you’d like to update immediately, browse to Dashboard > Updates and click the update button.

To see a full list of changes visit the release notes page on the Codex. Since December, WordPress 4.7 has been downloaded more than 60 million times.

How to Fix Render-Blocking JavaScript and CSS in WordPress

Do you want to eliminate render-blocking JavaScript and CSS in WordPress? If you test your website on Google PageSpeed insights, then you will likely see a suggestion to eliminate render-blocking scrips and CSS. In this article, we will show you how to easily fix render blocking JavaScript and CSS in WordPress to improve your Google PageSpeed score.

How to fix render blocking JavaScript and CSS in WordPress

What is Render-Blocking JavaScript and CSS?

Every WordPress site has a theme and plugins that add JavaScript and CSS files to the front-end of your website. These scripts can increase your site’s page load time, and they can also block rendering of the page.

A user’s browser will have to load those scripts and CSS before loading rest of the HTML on the page. This means that users on a slower connection will have to wait a few milliseconds more to see the page.

These scripts and stylesheets are referred to as render-blocking JavaScript and CSS.

Website owners who are trying to achieve the Google PageSpeed score of 100 will need to fix this issue to attain that perfect score.

What is Google PageSpeed Score?

Google PageSpeed Insights is an online tool created by Google to help website owners optimize and test their websites. This tool tests your website against Google’s guidelines for speed and offers suggestions to improve your site’s page load time.

It shows you a score based on the number of rules that your site passes. Most websites get somewhere between 50-70. However, some website owners feel compelled to achieve 100 (the highest a page can score).

Do You Really Need the Perfect “100” Google PageSpeed Score?

The purpose of Google PageSpeed insights is to provide you guidelines to improve speed and performance of your website. You are not required to follow these rules strictly.

Remember that speed is only one of the many SEO metrics that help Google determine how to rank your website. The reason speed is so important is because it improves user experience on your site.

A better user experience requires a lot more than just speed. You also need to offer useful information, better user interface, and engaging content with text, images, and videos.

Your goal should be to create a fast website that offers great user experience.

We recently redesigned WPBeginner, and we kept our focus on speed as well as improving user experience.

We recommend that you use Google Pagespeed rules as suggestions, and if you can implement them easily without ruining user experience, then that’s great. Otherwise, you should strive to do as much as you can and then don’t worry about the rest.

Having said that, let’s take a look at what you can do to fix render blocking JavaScript and CSS in WordPress.

We will cover two methods that will fix the render blocking JavaScript and CSS in WordPress. You can choose the one that works best for your website.

1. Fix Render Blocking Scripts and CSS with Autoptimize

This method is simpler and recommended for most users.

First thing you need to do is install and activate the Autoptimize plugin. For more details, see our step by step guide on how to install a WordPress plugin.

Upon activation, you need to visit the Settings » Autoptimize page to configure the plugin settings.

Autoptimize Settings

You can start by checking the box next to JavaScript Options and CSS Options and then click on the save changes button.

You can now test your website using PageSpeed tool. If there are still render blocking scripts, then you need to come back to the plugin’s settings page and click on ‘Show Advanced Settings’ button at the top.

Advanced JavaScript Options

Here you can allow plugin to include inline JS and remove scripts that are excluded by default like seal.js or jquery.js.

Next, scroll down to CSS option and allow plugin to aggregate inline CSS.

Click on the ‘Save changes and Empty Cache’ button to save your changes and empty plugin cache.

Once you are done, go ahead and check your website again with the PageSpeed tool.

Make sure that you thoroughly test your website to see that nothing is broken by optimizing your JavaScripts or CSS.

How does it work?

Autoptimize aggregates all enqueued JavaScript and CSS. After that, it creates minified CSS and JavaScripts files and serves cached copies to your website as async or deferred.

This allows you to fix the render blocking scripts and styles issue. However, please keep in mind that it can also affect the performance or appearance of your website.

2. Fix Render Blocking JavaScript using W3 Total Cache

This method requires a little more work and is recommended for users already using W3 Total Cache plugin on their website.

First you will need to install and activate the W3 Total Cache plugin. If you need help, then see our guide on how to install and setup W3 Total Cache for Beginners.

Next, you need to visit Performance » General Settings page and scroll down to Minify section.

W3 Total Cache enable minify

First you need to check ‘Enable’ next to Minify option and then select ‘Manual’ for minify mode option.

Click on the save all settings button to store your settings.

Next, you need to add the scripts and CSS that you want to minify.

You can get the URLs of all the scripts and stylesheets that are render blocking from Google PageSpeed Insights tool.

Under the suggestions where it says: ‘Eliminate render-blocking JavaScript and CSS in above-the-fold content’, click on ‘Show how to fix’. It will show you the list of scripts and stylesheets.

Get JavaScript and Stylesheet URLs from Google PageSpeed tool

Take your mouse over to a script and it will show you the full URL. You can select this URL and then use your keyboard’s CTRL+C (Command+C on Mac) keys to copy the URL.

Now head over to your WordPress admin area and go to Performance » Minify page.

First you need to add JavaScript files that you want to be minified. Scroll down to JS section and then under the ‘Operations in areas’ set the embed type to ‘Non-blocking async’ for the <head> section.

Add scripts to minify

Next, you need to click on the ‘Add script’ button and then start adding script URLs that you copied from Google PageSpeed tool.

Once you are done, scroll down to CSS section and then click on the ‘Add a stylesheet’ button. Now start adding stylesheet URLs you copied from Google PageSpeed tool.

Add stylesheets to minify

Now click on the ‘Save settings and purge cache’ button to store your settings.

Visit the Google PageSpeed tool and test your website again.

Make sure that you also test your website thoroughly to see that everything is working fine.

Troubleshooting

Depending on how the plugins and your WordPress themes uses JavaScript and CSS, it could be quite challenging to completely fix all render blocking JavaScript and CSS issues.

While the above tools can help, your plugins may need certain scripts at a different priority level to work properly. In that case, the above solutions can break your plugins or they could behave unexpectedly.

Google may still show you certain issues like optimizing CSS delivery for above the fold content. Autoptimize allows you to fix that by manually adding inline CSS required to display the above fold area of your theme.

However, it could be quite difficult to find out what CSS code you will need to display above the fold content.

That’s all, we hope this article helped you learn how to fix render blocking JavaScript and CSS in WordPress. You may also want to see our ultimate guide boost WordPress speed and performance for beginners.

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 Fix Render-Blocking JavaScript and CSS in WordPress appeared first on WPBeginner.

Submitted a Plugin? Please Check Your Emails!

Currently ~30% of all new plugins are approved within 7 days of submission.

Why so low? People don’t reply to their emails. We have over 100 plugins waiting on replies from developers. At this precise moment (10:30 am US Pacific Time, Sunday April 16) there are ZERO plugins pending review. That means everyone who submitted a plugin between April 1 and today has been emailed.

If you didn’t get the email, please go check your spam. Free email clients like Hotmail, Yahoo, and Google tend to file us as ‘automated’ emails, which is not true, but whatever. Put plugins@wordpress.org in your whitelist (actually put @wordpress.org in a filter to have it never treated as spam and always important) because if you’re not getting emails from WP and you’ve submitted a plugin or a theme, you’re going to have a bad time.

Again. Everyone’s been emailed. I promise. Check your emails. Drop us a line if you can’t find it. Remember to whitelist us.

#reminder

Disable WordPress Responsive Images

[ Bruce Lee ] WordPress responsive images are awesome. But some people want to use their own methods to implement. This post explains how to disable WordPress responsive image functionality so that you can use your own methods. It makes things easier when you don’t have to wrestle with what WordPress is doing.

tl;dr

Grab the plugin.

WordPress responsive images

If you haven’t looked under the hood of your WP-powered site recently, you may be surprised at some of the new liberties that WordPress is taking with your images. As of version 4.4, WordPress is executing its own responsive-image functionality behind the scenes. Specifically, there are two things that WordPress does with its built-in responsive-image feature:

  1. Creates an additional copy of your image that is 768px
  2. Adds srcset attributes to your image markup on the frontend

Again, this is great news for those who want automated responsive images. But for those of us who prefer our own solutions, it’s counter-productive. For example, The additional 768px image happens behind the scenes, with no corresponding option in the WP Admin (under Settings > Media). And further, srcset attributes are not always optimal or required. Consider the typical markup required to display an image:

<img src="http://example.com/wp/wp-content/uploads/2017/03/photo-600x471.jpg" alt="Whatever">

Here is what that image markup looks like after WordPress gets ahold of it (unfolded for clarity):

<img 
class="wp-image-944 size-medium" 
src="http://example.com/wp/wp-content/uploads/2017/03/photo-600x471.jpg" 
alt="photo" 
width="600" 
height="471" 
srcset="http://example.com/wp/wp-content/uploads/2017/03/photo-600x471.jpg 600w, 
http://example.com/wp/wp-content/uploads/2017/03/photo-1024x804.jpg 1024w, 
http://example.com/wp/wp-content/uploads/2017/03/photo.jpg 1600w" 
sizes="(max-width: 709px) 
85vw, (max-width: 909px) 
67vw, (max-width: 984px) 
61vw, (max-width: 1362px) 
45vw, 600px" />

Again, sweet for those who need it; not so much for those who don’t. I mean, that’s a LOT of extra markup just to display a responsive image. Imagine 10 or more images on the same page.. the extra bytes can really add up and chew into site performance.

Behind the scenes

Before looking at how to disable WordPress’ responsive image functionality, let’s examine what’s happening under the hood. First, here is the array of image data that is accessible via the intermediate_image_sizes_advanced filter hook:

array(4) {
	["thumbnail"]=> array(3) { 
		["width"]=> string(3) "150" 
		["height"]=> string(3) "150" 
		["crop"]=> string(1) "1"
	}
	["medium"]=> array(3) {
		["width"]=> string(3) "300" 
		["height"]=> string(3) "300" 
		["crop"]=> bool(false) 
	}
	["medium_large"]=> array(3) { 
		["width"]=> string(3) "768" 
		["height"]=> string(1) "0" 
		["crop"]=> bool(false) 
	}
	["large"]=> array(3) {
		["width"]=> string(4) "1024" 
		["height"]=> string(4) "1024" 
		["crop"]=> bool(false)
	}
}

So that means we can access the array and modify it however we would like. Here is a function that demonstrates this:

function shapeSpace_customize_image_sizes($sizes) {
	unset($sizes['thumbnail']);
	unset($sizes['medium']);
	unset($sizes['medium_large']);
	unset($sizes['large']);
	return $sizes;
}
add_filter('intermediate_image_sizes_advanced', 'shapeSpace_customize_image_sizes');

Here we are hooking into intermediate_image_sizes_advanced and unsetting (removing) each image size data from the $sizes array. Of course, this is just an example to illustrate the concept. Now let’s use this information to disable WP’s responsive image functionality.

Step 1: Disable the extra image

Using the above technique, we can prevent WordPress from auto-creating the additional 768px (medium_large) image:

function shapeSpace_customize_image_sizes($sizes) {
	unset($sizes['medium_large']); // 768px
	return $sizes;
}
add_filter('intermediate_image_sizes_advanced', 'shapeSpace_customize_image_sizes');

No modifications are required. Adding this function restores the pre-4.4 default image sizes, which also correspond to the settings provided on the WP Settings > Media screen:

  • Thumbnail (default 150)
  • Medium (default 300)
  • Large (default 1024)

Note that you can skip this step if you want to keep medium-large copies of your uploaded images. You can implement only the next step, only this step, both, or none. Your call.

Step 2: Disable the srcset attributes

After disabling the auto-generated medium-large 768px image, the final step in disabling WordPress’ responsive functionality is to disable the srcset markup that is added to every <img> tag on the frontend. We can do that with the following slice of code:

// disable srcset on frontend
add_filter('max_srcset_image_width', create_function('', 'return 1;'));

And done. No modifications are required, just add to functions.php and enjoy the results. Which, by the way, you can verify by examining the source code of your web pages.

Disable via plugin

If you would rather use a plugin to disable WP’s responsive images, here you go:

<?php
/*
Plugin Name: Disable Responsive Images Complete
Plugin URI: https://plugin-planet.com/
Description: Disables WP's responsive-image feature
Author URI: https://plugin-planet.com/
Author: Jeff Starr
Version: 1.0
*/

// disable srcset on frontend
add_filter('max_srcset_image_width', create_function('', 'return 1;'));

// disable 768px image generation
function shapeSpace_customize_image_sizes($sizes) {
	unset($sizes['medium_large']);
	return $sizes;
}
add_filter('intermediate_image_sizes_advanced', 'shapeSpace_customize_image_sizes');

This plugin combines the two steps above into a simple plugin. I use this on several of my own sites, including this one. It just works. If and when WordPress changes how it handles responsive images, I’ll update this code accordingly. So if you know of any changes, or if I’ve missed anything, please let me know in the comments or directly via email.


Display bbPress Posts without a Plugin

[ Display bbPress Posts without a Plugin ] I recently redesigned my .htaccess site, htaccessbook.com. Before the redesign, I was using bbPress for the forum functionality. It worked okay for a few years, but along the way there were all sorts of really nasty bugs and important things breaking. It seemed like, no matter what, each updated version of the bbPress plugin caused serious problems, like replies not working, permalinks changing, and all sorts of other issues. Eventually, I got tired of spending hours after each bbPress update to try and fix things. It was time to find a better way.

No plugins required

After researching possible replacements for bbPress, I felt unimpressed and uninspired. There just weren’t any good fits that met all of my requirements, which honestly were fairly modest. So I gave up on existing “solutions” and decided to roll my own. After some investigation and planning, it turned out that all I needed was a way to display all of the forum topics and replies. Didn’t need any other functionality, just a way to display existing forum content.

Currently the forum is closed to new replies, which is why I needed only to display content. At some point in the future I will reopen the forum and use USP Pro to enable logged in users to submit new topics and replies. But for now, I’m simply displaying the existing forum content publicly on the front-end.

And so that’s what this tutorial is all about: displaying your bbPress content without using a plugin. This may be useful if you are ditching bbPress or in the process of finding another forum solution (which unfortunately is easier said than done).

Before diving in, please understand that this technique is not really meant to be a full-fledged solution. It’s simply a way to access your forum content from the database and display it on the front-end of your WordPress-powered site. With that in mind, here are the steps (and code) required to make it happen.

Step 0: Back up your database and files

Before making any changes, take a moment to ensure that you have a good working backup of your site files and database. This is entirely a precautionary measure and just good practice in general. So if anything unexpected or weird happens, you can restore your site’s functionality as quickly as possible.

Step 1: Add support for Topics and Replies

First, we need to add support for a couple of Custom Post Types (CPTs). When bbPress was installed, it provided the support required for its various CPTs. Now bbPress is removed, but all of that CPT data remains in the database. For this tutorial, we want to display Topics and Replies, so we need to add CPT support accordingly. To do so, add the following template code to your current theme’s functions.php file:

// add support for topic cpt
function shapeSpace_topic_cpt() {
	$labels = array(
		'name'               => __('Topics', 'shapeSpace'),
		'singular_name'      => __('Topic', 'shapeSpace'),
		'menu_name'          => __('Topics', 'shapeSpace'),
		'name_admin_bar'     => __('Topics', 'shapeSpace'),
		'add_new'            => __('Add New', 'shapeSpace'),
		'add_new_item'       => __('Add New Topic', 'shapeSpace'),
		'new_item'           => __('New Topic', 'shapeSpace'),
		'edit_item'          => __('Edit Topic', 'shapeSpace'),
		'view_item'          => __('View Topic', 'shapeSpace'),
		'all_items'          => __('All Topics', 'shapeSpace'),
		'search_items'       => __('Search Topics', 'shapeSpace'),
		'parent_item_colon'  => __('Parent Topics:', 'shapeSpace'),
		'not_found'          => __('No topics found.', 'shapeSpace'),
		'not_found_in_trash' => __('No topics found in Trash.', 'shapeSpace'),
	);
	$args = array(
		'labels'              => $labels,
		'taxonomies'          => array(),
		'public'              => true,
		'publicly_queryable'  => true,
		'show_ui'             => true,
		'show_in_menu'        => true,
		'query_var'           => true,
		'rewrite'             => array('slug' => 'topic'),
		'capability_type'     => 'post',
		'has_archive'         => true,
		'hierarchical'        => false,
		'menu_position'       => null,
		'supports'            => array('title', 'editor', 'author', 'excerpt', 'custom-fields'),
		'exclude_from_search' => false, 
	);
	register_post_type('topic', $args);
}
add_action('init', 'shapeSpace_topic_cpt');



// add support for reply cpt
function shapeSpace_reply_cpt() {
	$labels = array(
		'name'               => __('Replies', 'shapeSpace'),
		'singular_name'      => __('Reply', 'shapeSpace'),
		'menu_name'          => __('Replies', 'shapeSpace'),
		'name_admin_bar'     => __('Replies', 'shapeSpace'),
		'add_new'            => __('Add New', 'shapeSpace'),
		'add_new_item'       => __('Add New Reply', 'shapeSpace'),
		'new_item'           => __('New Reply', 'shapeSpace'),
		'edit_item'          => __('Edit Reply', 'shapeSpace'),
		'view_item'          => __('View Reply', 'shapeSpace'),
		'all_items'          => __('All Replies', 'shapeSpace'),
		'search_items'       => __('Search Replies', 'shapeSpace'),
		'parent_item_colon'  => __('Parent Replies:', 'shapeSpace'),
		'not_found'          => __('No replies found.', 'shapeSpace'),
		'not_found_in_trash' => __('No replies found in Trash.', 'shapeSpace'),
	);
	$args = array(
		'labels'              => $labels,
		'taxonomies'          => array(),
		'public'              => true,
		'publicly_queryable'  => true,
		'show_ui'             => true,
		'show_in_menu'        => true,
		'query_var'           => true,
		'rewrite'             => array('slug' => 'reply'),
		'capability_type'     => 'post',
		'has_archive'         => false,
		'hierarchical'        => false,
		'menu_position'       => null,
		'supports'            => array('title', 'editor', 'author', 'excerpt', 'custom-fields'),
		'exclude_from_search' => true, 
	);
	register_post_type('reply', $args);
}
add_action('init', 'shapeSpace_reply_cpt');

You can add this code wholesale without any modifications, or you can consult the WP Codex and customize everything according to your needs. Note that some of the parameters defined in these two functions are required in order to properly display the bbPress Topics and Replies.

Step 2:

Once the Custom Post Types are defined, we need a template to display their content. The easiest way to do this is to create a new Page and assign a custom template that contains the following code:

<?php 
	/* Template Name: Forum Posts */ 
	/* 
		This is a temporary Page template for looking up old forum posts
		See also functions.php for creation of related custom post types
	*/
?>
<?php get_header(); ?>

<div class="content" id="content">
	<article class="wrap">
		
		<?php if (current_user_can('manage_options')) : ?>
			
			<?php // Topics
			
			$paged = (get_query_var('paged')) ? get_query_var('paged') : 1;
			
			$args = array('post_type' => array('topic'), 'posts_per_page' => 1, 'paged' => $paged, 'order' => 'ASC'); // forum, topic, reply
			
			$temp = $wp_query;
			$wp_query = null;
			
			$wp_query = new WP_Query();
			$wp_query->query($args);
	
			if ($wp_query->have_posts()) : while ($wp_query->have_posts()) : $wp_query->the_post(); ?>
			
			<h1><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h1>
			<div class="meta">Post ID: <?php echo $post->ID; ?> &bull; Forum: <?php echo get_the_title($post->post_parent); ?> &bull; Posted by <?php the_author_posts_link(); ?> on 
			<time datetime="<?php echo the_time('Y-m-j'); ?>" pubdate><?php the_time('l, F jS, Y'); ?></time></div>
			<div class="the-content"><?php the_content(); ?></div>
				
				
				<?php // Replies
				
				$topic = $wp_query->post->ID;
				
				$replies_args = array('post_type' => array('reply'), 'posts_per_page' => -1, 'order' => 'ASC', 'post_parent' => $topic); 
				
				$replies = new WP_Query();
				$replies->query($replies_args);
				if ($replies->have_posts()) : while ($replies->have_posts()) : $replies->the_post(); ?>
					
					<h4><?php the_title(); ?></h4>
					<div class="meta">Post ID: <?php echo $post->ID; ?> &bull; Reply to: <?php echo get_the_title($post->post_parent); ?> &bull; Posted by <?php the_author_posts_link(); ?> on 
					<time datetime="<?php echo the_time('Y-m-j'); ?>" pubdate><?php the_time('l, F jS, Y'); ?></time></div>
					<div class="the-content"><?php the_content(); ?></div>
					
				<?php endwhile; ?>
				<?php endif; ?>
				
				
			<?php endwhile; ?>
			<?php wp_reset_postdata(); ?>
			<?php previous_post_link('<div class="prev">%link</div>', '&larr;&nbsp;%title'); ?>
			<?php next_post_link('<div class="next">%link</div>', '%title&nbsp;&rarr;'); ?>
			<?php wp_reset_query(); ?>
			<?php endif; ?>
			
		<?php endif; ?>
		
	</article>
</div>

<?php get_footer(); ?>

This is a complete page template that can be added directly to any custom page (e.g., /mytheme/page-custom.php). Here is a rundown of what it does:

  1. Gets the theme header template
  2. Checks that the current user can manage_options, so only admin-level users can view the forum posts. If desired, you can remove this line and just set the Page visibility to Private or Password Protected. Or if you want to give all users access, you can remove this line (and the last closing endif; statement).
  3. Begins the Loop for forum topics: we set the $paged variable so that paged navigation will work. This will enable the navigation links to work, so you can browse through each forum topic.
  4. Begins the custom loop for the topics. This loop first displays the topic title, date, forum, and other metadata. After displaying the topic content, a second, nested loop is started for the topic replies.
  5. The second loop for replies is similar to the first, parent loop. We grab the topic ID from the parent loop, and then use it to run the replies loop. Inside of the replies loop, we display the reply title, ID, content, and other related information.
  6. After closing each of the two loops, we use wp_reset_postdata() to restore the global $post variable of the main query loop.
  7. Then navigation links are added via previous_post_link() and next_post_link(), enabling navigation through each forum topic.
  8. Lastly and just to be safe, we use wp_reset_query() to restore the $wp_query and global post data to the original main query.

Wrapping thoughts..

Again, this is not meant as any type of permanent solution, but rather just provides an interface for you to access your forum content. It’s meant to give you an idea going forward, to build from and customize as needed to display your topics and replies as needed. You can see my implementation of this basic technique at .htaccess made easy.


Customizer Team Proposes Image Widget for WordPress 4.8

WordPress contributors to the customizer have published a merge proposal for a new JavaScript and REST API-powered core image widget. The new widget interfaces with the WordPress media library to provide a simpler, more intuitive experience for adding images. No new widgets have been added to core since the Custom Menu widget was included in 3.0 nearly seven years ago.

Image widget demo optimized

The current method of inserting images into widgets is a multi-step process that many plugins have attempted to simplify. Hundreds of thousands of WordPress users have installed a plugin with this feature. The Image Widget plugin, created by Modern Tribe, is one of the most popular with more than 500,000 active installs.

Widget architecture in WordPress currently relies on PHP and AJAX, but the new image widget will follow the recent trend towards JavaScript interfaces.

“In the time since WP_Widget was introduced in 2.8, WordPress has made dramatic shifts toward developing interfaces in JavaScript, including with the Customizer in 3.4 and the Media Library in 3.5, and more recently with the focus on the REST API,” Mel Choyce said in the proposal. “Given that the media widgets are naturally interfacing with the media library JS, it is necessary that the media widgets make use of JavaScript to construct their UI instead of relying on PHP.”

Customizer component co-maintainer Weston Ruter noted in the comments that the new proposed image widget also allows for external images to be embedded by URL. This is a feature that Jetpack offers in its image widget. The new core widget will support both use cases that WordPress users are already familiar with from popular plugins.

The image widget is the first of several planned JS-powered media widgets, including video, audio, galleries, and slideshows. Ruter said progress on the video widget is coming along well and he anticipates it will likely land next. Contributors have begun work on the audio widget, but Ruter said galleries and slideshows are a higher priority.

Matt Mullenweg, who is leading core development this year, confirmed in his quarterly update today that the image widget will be considered for 4.8.

“The plan is for the larger block-driven customization work to kick off in June,” Mullenweg said. “Prior to that, we’re focusing on widgets and other low-hanging fruit. Lack of developers slowed us down the last few months, now doing better but could still use more help there. Media widgets + WYSIWYG on text widget seem simple but will have a big user impact.”

Contributors on the Customizer team are asking for developers and users to test the new image widget. The latest version of the plugin is available on GitHub. The Core Media Widgets plugin is also available on WordPress.org.

WordPress .htaccess file

[ WordPress .htaccess file ] The WordPress core uses .htaccess for two things: Permalinks and Multisite. This means that .htaccess is only required if you have enabled either of these features. Otherwise, .htaccess is entirely optional for default WordPress installations. Beyond the WP core, many plugins also use the .htaccess file for custom directives involving rewrites, redirects, custom headers, file compression, and much more. In many cases, such plugins add their .htaccess rules to your .htaccess file automatically, behind the scenes.

So even if you haven’t enabled Permalinks or Multisite, your site may be using .htaccess rules added by WordPress plugins for various types of functionality. That’s one of the cool things about .htaccess: it can be configured and customized to improve your site’s performance, security, and usability. To help you get started, this tutorial provides a collection of .htaccess techniques that are useful for any WordPress-powered site. Combined into a blank .htaccess file, these techniques serve as a great starting point for creating your own custom .htaccess file for WordPress.

Before diving in..

Before making any changes to your site’s .htaccess file(s), remember to make a backup copy. That way you can quickly restore original functionality should anything unexpected happen. These rules are all well-tested and commonly used, but in this line of work anything can happen, so it’s best to be prepared with good working backups just in case.

Disable directory views

With this technique, we increase security by disabling directory views, which also are known as “directory indexes” or “directory listings”. Many web hosts disable directory views by default, but it’s important to know for sure. If your files are visible, here is an effective way to lock things down.

# Disable directory views
Options -Indexes
<IfModule dir_module>
	DirectoryIndex disabled
	DirectoryIndex index.php
</IfModule>

Here we disable Indexes via the Options directive. Then we specify the DirectoryIndex just in case. So technically it’s fine to just do this:

# Disable directory views
Options -Indexes

I include the additional dir_module rules because they are related, and some people may find them useful. To learn more about customizing directory views, check out my tutorial, Better Default Directory Views with HTAccess.

Set default encoding

Setting your site’s default encoding as UTF-8 helps browsers and devices correctly interpret your page content.

# Set default encoding
AddDefaultCharset UTF-8

This directive helps to improve the accuracy and consistency of your web pages. It’s also possible to set the character encoding for specific file types. For example, here we are setting UTF-8 encoding for all CSS and JavaScript files:

# Set encoding for CSS & JS
<IfModule mod_mime.c>
	AddCharset utf-8 .html .css .js
</IfModule>

For more possibilities, check out the “Add mod_mime suport” section of my tutorial, Useful .htaccess rules for all websites.

Add Vary header

According to Google and others, publicly cacheable, compressible resources should include the following header:

Vary: Accept-Encoding

This is to prevent certain public proxy services from delivering compressed versions of your files to clients that do not support compression. Sending a Vary header for compressed resources helps resolve this issue by instructing the proxy to cache both compressed and uncompressed versions. To implement, add this code to your site’s root .htaccess file:

# Add Vary header
<IfModule mod_headers.c>
	<FilesMatch ".(css|js|gz|xml)$">
		Header append Vary: Accept-Encoding
	</FilesMatch>
</IfModule>

This code sends the necessary Vary header for CSS, JavaScript, gzip, and XML files. If your site serves other compressed resources, you can add their respective file types to the list, like so:

.(css|js|gz|xml|zip)$

Here we have added the ZIP file format, zip.

Add security headers

There are lots of useful headers that can be added to any website. For example, here are three headers that provide some great security benefits:

  • Protect against XSS attacks
  • Protect against page-framing and click-jacking
  • Protect against content-sniffing

Amazingly, you can add these security benefits with a simple slice of .htaccess:

# Add Security Headers
<IfModule mod_headers.c>
	Header set X-XSS-Protection "1; mode=block"
	Header always append X-Frame-Options SAMEORIGIN
	Header set X-Content-Type-Options nosniff
</IfModule>

No edits need made for this code. Simply add to root .htaccess and enjoy the extra protection. You can learn more about this technique by visiting my tutorial, Increase Security with X-Security Headers.

Protect sensitive files

By default, all WordPress installs include the following files:

  • wp-config.php – WP configuration file
  • license.txt – WP license information
  • readme.html – WP install & version information

Of these, wp-config.php should by default NOT be publicly accessible. The other two files, license.txt and readme.html, are by default publicly accessible. All three of these files contain information about your WordPress-powered site. By blocking public access to these files, you prevent bad actors from obtaining and using the information when crafting their attacks. Here is the code to make it happen:

# Protect sensitive files
<FilesMatch "^(wp-config.php|license.txt|readme.html)">
	Order Allow,Deny
	Deny from all
</FilesMatch>

This simple technique uses FilesMatch to target each of the files that should be denied access. You can protect any other loose or sensitive files by adding them to the FilesMatch directive.

Leverage browser caching

Browser caching plays an important role with all websites, especially WordPress. This technique ensures that your site is taking advantage of browser caching by setting optimal ExpiresByType HTTP headers.

# Leverage browser caching
<IfModule mod_expires.c>
	ExpiresActive on
	ExpiresDefault "access plus 1 month"
	#
	ExpiresByType image/jpg  "access plus 1 year"
	ExpiresByType image/jpeg "access plus 1 year"
	ExpiresByType image/gif  "access plus 1 year"
	ExpiresByType image/png  "access plus 1 year"
	ExpiresByType text/css   "access plus 1 month"
	#
	ExpiresByType text/javascript        "access plus 1 month"
	ExpiresByType application/javascript "access plus 1 month"
	ExpiresByType text/x-javascript      "access plus 1 month"
	#
	ExpiresByType image/x-icon "access plus 1 year"
</IfModule>

This code helps to optimize performance by setting expires headers for the most common file types. You can adjust the cache times to suit your needs, and add more file types as required. For more information, check out Google’s article, Leverage Browser Caching.

Enable file compression

File compression reduces the amount of data that is sent to the client, so it is a great way to improve performance. Fortunately, Apache enables compression via its Deflate module, which can be implemented with the following slab of .htaccess:

# Enable file compression
<IfModule mod_deflate.c>
	AddOutputFilter       DEFLATE css js
	AddOutputFilterByType DEFLATE image/svg+xml image/x-icon
	AddOutputFilterByType DEFLATE application/vnd.ms-fontobject application/x-font-ttf font/opentype
	AddOutputFilterByType DEFLATE application/javascript application/x-javascript text/javascript text/x-js
	AddOutputFilterByType DEFLATE text/html text/plain text/richtext text/css application/json text/xsd text/xsl
	AddOutputFilterByType DEFLATE text/xml text/x-component application/xml application/xhtml+xml application/rss+xml application/atom+xml
</IfModule>

This code first enables compression for all CSS and JavaScript files. It then enables compression for many other types of files. Feel free to customize the file formats that should be compressed. For more information, check out .htaccess enable compression.

Block external POST requests

POST requests are required when submitting certain forms. For example, the comment form, login form, and most contact forms all submit their data via the POST request method. Normally, POST requests are initiated by users who are visiting your site. But it’s also possible for bad actors to submit malicious POST requests from another domain or source, in an attempt to hack your stuff. To prevent this, we can deny access to all POST requests that are not initiated from your domain. This can be accomplished with the following slice of .htaccess:

# Block external POST
<IfModule mod_rewrite.c>
	RewriteCond %{REQUEST_METHOD} POST
	RewriteCond %{REQUEST_URI} (wp-comments-post|wp-login).php [NC]
	RewriteCond %{HTTP_REFERER} !(.*)example.com [NC,OR]
	RewriteCond %{HTTP_USER_AGENT} ^$
	RewriteRule .* - [L]
</IfModule>

Remember to change example.com to match your own domain. Once implemented correctly, this code does the following:

  1. Checks if the request is POST
  2. Checks if the request is for the comments form or the login form
  3. Checks if the request is not from your domain, or if the user agent is empty
  4. If these conditions are true, the request is denied via 403 “Forbidden” response

In doing this, the above technique helps to keep your site secure by blocking any POST requests that do not originate from your domain. This helps to reduce spam, brute-force login attacks, and lots of other malicious mischief.

Note that you can protect other POST forms as well. For example, if you have a contact form located at http://example.com/contact/, you can add it by modifying the REQUEST_URI directive like so:

RewriteCond %{REQUEST_URI} (wp-comments-post.php|wp-login.php|/contact/) [NC]

Remember to test well before going live with any changes. More info: Block Spam by Denying Access to No-Referrer Requests.

Enable WordPress permalinks

Last but not least, if you have enabled Permalinks for your site, you must include the required .htaccess directives. There are two possibilities here: WordPress installed in the site’s root directory, or WordPress installed in a sub-directory. Depending on where WordPress is installed, you will want to include one of the following sets of directives.

WordPress in site root directory

Here is the code to use if WordPress is installed in the site’s root directory:

# BEGIN WordPress
<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteBase /
	RewriteRule ^index.php$ - [L]
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteCond %{REQUEST_FILENAME} !-d
	RewriteRule . /index.php [L]
</IfModule>
# END WordPress

No modifications are required for this code.

WordPress in a subdirectory

Alternately, here is the code to use if WordPress is installed in it’s own (sub) directory (e.g., a subdirectory named /wordpress/):

# BEGIN WordPress
<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteBase /wordpress/
	RewriteRule ^index.php$ - [L]
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteCond %{REQUEST_FILENAME} !-d
	RewriteRule . /wordpress/index.php [L]
</IfModule>
# END WordPress

For this code, you will need to edit both instances of wordpress with the path/directory in which WordPress is installed. For example, here at Perishable Press, WordPress is installed in a directory named /wp/, so I replaced wordpress with wp.

For more information about either of these techniques, check out my tutorial, The htaccess Rules for all WordPress Permalinks.

Bonus tip!

As a bonus, you can add the following directive (just after the first RewriteRule) to automatically redirect all login requests to the actual WP Login Page:

RewriteRule ^login/?$ /wp-login.php [QSA,L]

For more information on this trick, check out Chris Coyier’s DigWP post, Simpler Login URL. This is a useful technique for client sites :)

Download ’em all

The techniques presented in this article are not dependent on each other. So you can use them separately, as desired; or you can combine them all into a single .htaccess file to create a solid .htaccess file for WordPress. To make things easier, here is a text file that contains all of the techniques from this tutorial:

WordPress .htaccess file – Version 1.0 (3 KB txt)

Going further

Intentionally, the techniques provided in this article are kept as general and as widely applicable as possible. There are thousands more useful techniques that could be added, but keeping it simple with only the essentials is optimal when first getting started. I encourage you to go further with your .htaccess file. Here are some recommended resources that are worth exploring.

Questions and comments always welcome :)


WordPress Editor Experience Survey Shows 75% of Respondents Don’t Use Distraction-Free Writing Mode

The WordPress Editor Experience survey results have been published with data from 2,563 participants, a significantly larger sampling than the 50 who responded to the recent customizer survey. Both the editor and the customizer are included in Matt Mullenweg’s three main focus areas for core development in 2017. The purpose of the surveys is to find out how WordPress users are using or not using the current features.

More than half of the survey respondents (66%) identified themselves as developers (in addition to other roles). Since this category of users dominated the survey results, Mark Uraine decided to break it down further to display other categories developers selected.

Based on these results, it isn’t surprising that more than 85% of respondents use the markup text editor and 35% of those use it exclusively. Support for syntax highlighting is also a popular request.

The distraction-free writing mode received quite a bit of feedback on the survey. More than 75% of respondents said they do not use it.

The current implementation of the distraction-free writing mode was introduced in WordPress 4.1 at the end of 2014. The idea was to minimize distractions without having to go through a clunky transition to access the admin menu or meta boxes. Moving the cursor to the right or left of the editor brings them back into view, but many people find the admin interface sliding in and out of view to be distracting. Several who commented suggested that the feature could use some major improvements.

The survey also revealed that the majority of respondents (72%) install plugins that add features to the editor. These most commonly include shortcodes, Advanced TinyMCE, Tables, and Visual Composer. The results indicate that users often extend the editor to get more basic advanced layout capabilities for presenting their content.

The Editor Experience survey was a good first start, but it doesn’t accurately represent WordPress’ global user base. The results are heavily skewed towards developers’ needs and experiences. Developers are users, too, but there has to be a way to get these surveys into the hands of a more diverse sampling of users. Reopening the survey and circulating it beyond the WordPress developer community might help to paint a more accurate picture of users’ experiences with the editor.

A more diverse sampling would reveal whether or not the vast majority of users have no use for the current implementation of the distraction-free writing mode, as developer feedback seems to suggest. It could also provide more feedback on the visual editor features that 35% of respondents to this survey never use.

How to Fix “Missing a Temporary Folder” Error in WordPress

Are you seeing ‘Missing a temporary folder’ error on your WordPress site? This error makes it impossible to upload images, update themes and plugins, or update WordPress core. In this article, we will show you how to easily fix “Missing a temporary folder” error in WordPress.

How to fix 'Missing temporary folder' error in WordPress

What Causes The ‘Missing a Temporary Folder’ Error in WordPress?

This error is caused by incorrect PHP settings on your WordPress hosting environment. There is a specific PHP setting that defines a temporary folder to be used by apps like WordPress to temporarily store data before saving it to the desired location.

WordPress needs access to this temporary folder when you upload an image, install or update a theme or plugin, or update WordPress core.

If the location of this folder is not defined in your server’s PHP configuration, then WordPress will be unable to do any of these things and will show you ‘Missing a temporary folder’ error.

Missing temporary folder error

Having said that, let’s see how to easily fix the ‘Missing a temporary folder’ error in WordPress.

Fix Missing Temporary Folder Error in WordPress

For this tutorial, you will need to edit wp-config.php file in WordPress. If you haven’t done this before, then please see our guide on how to edit wp-config.php file in WordPress.

First, you will need to connect to your website using an FTP client or File Manager in cPanel dashboard of your hosting account.

Next, you will need to locate the wp-config.php file and edit it.

Editing wp-config.php file using an FTP client

You need to paste this code to the file just before the line that says ‘That’s all, stop editing! Happy blogging’.

define('WP_TEMP_DIR', dirname(__FILE__) . '/wp-content/temp/');

Save your changes and upload the wp-config.php file back to your website.

Next, you need to go to /wp-content/ folder and create a new folder inside it. You need to name this new folder temp.

Creating temp folder

That’s all, you can now visit your WordPress admin area and try uploading an image.

Troubleshooting

If this method doesn’t work, then check the directory permissions for your wp-content folder.

Note: This error is caused by poorly configured hosting environment. The solution described above is just a workaround. You should still ask your hosting provider to fix this. If they don’t, then you should switch to one of these top WordPress hosting companies.

We hope this article helped you fix the ‘Missing a temporary folder’ error in WordPress. You may also want to bookmark our ultimate list of the most common WordPress errors and how to fix them.

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 Fix “Missing a Temporary Folder” Error in WordPress appeared first on WPBeginner.