How to get the current page URL in WordPress

In most scenarios get_permalink() will cover your needs, however, that will only get you the current page URL for single posts, pages, and custom post types and only works within the loop.

There is get_post_type_archive() for post type archive URLs and get_term_link() for category/taxonomy URLs but it would be nice if we had one all-encompassing function that worked in all scenarios.

You may have seen long complicated functions using $_SERVER['HTTPS'] to work out the protocol and joining this with $_SERVER['HTTP_HOST'] before appending $_SERVER['REQUEST_URI'] but this can all be simplified down to a one-liner. We let WordPress’ built-in home_url() function do all the heavy lifting.

WordPress Get Current URL Function

PHP
functions.php

You don’t need to worry about $_SERVER['REQUEST_URI'] ever being empty as WordPress calls the wp_fix_server_vars() function on every load to ensure this and other server variables it relies on exist. As a bonus, this preserves query string values ensuring it works with plain and custom permalink structures.

Remember to escape the output of the above function, as $_SERVER['REQUEST_URI'] can be source of unsafe user input which could be used in XSS (Cross-Site Scripting) attacks. Don’t worry, this is a simple as passing the output to esc_url() when used in HTML attributes and esc_html() otherwise. You’re in the habit of doing this anyway though, aren’t you?

Current Page URL Example Usage

PHP
footer.php

How to exclude Gutenberg blocks from certain post types

At first glance you might consider using the allowed_block_types filter to disable certain blocks.

PHP
plugins/pw-examples/pw-examples.php

The problem with this however is that by default the value that is passed to this filter as $allowed_blocks is boolean true, and not a list of all the registered blocks as you might expect. This is because most blocks are wholly registered on the client side via javascript rather than on the server side via PHP.

That makes this filter great for white-listing blocks, but useless for black-listing them.

Unregister a block type

As mentioned in the Gutenberg Block Filters documentation you can unregister a block type with the wp.blocks.unregisterBlockType javascript function.

PHP
plugins/pw-examples/pw-examples.php
JS
plugins/pw-examples/unregister-block.js

There are a few problems using this above method however:

  1. Not all blocks are registered at this time. (You can only guarantee the core blocks are registered, not those added via other plugins).
  2. If the post you are editing already has one of the block types you’ve unregistered you’ll get an error about the block type not existing.
  3. Some blocks types depend on others existing so you have to be careful what you unregister.

Hiding a block type from the inserter

The solution to the above problems is to hide the blocks you don’t want available to users from the inserter so they can’t be inserted in to posts.

The core Columns block type makes use of this feature. You may not be aware but there is also a Column block type that isn’t available to be inserted manually; this block is programmatically inserted as a child of the main Columns block. The code to register a block like that goes something along the lines of the following.

JS
column.js

By default, all blocks will appear in the Gutenberg inserter. To hide a block so that it can only be inserted programmatically, set inserter to false.

WordPress.org documentation on the supports option when registering a block type.

Luckily there is a javascript registerBlockType filter for the registerBlockType function which will allow us to forcibly set inserter to false for any block we choose.

PHP
plugins/pw-examples/pw-examples.php
JS
plugins/pw-examples/filter-register-block-type.js

Creating a disallowed_block_types filter

Bringing everything above together we can create a disallowed_block_types filter that functions similarly to the built in allowed_block_types filter; allowing us to black-list blocks on the server/PHP side with full knowledge of the post (and therefore post type) being edited.

PHP
plugins/pw-examples/pw-examples.php

We can then use the disallowed_block_types filter we’ve created just as we would the built-in allowed_block_types one.

PHP
plugins/pw-examples/pw-examples.php

As we have access to the $post object we can also conditionally remove block types e.g. based on the post type.

PHP
plugins/pw-examples/pw-examples.php

How to disable automatic ‘Smart Quotes’ for specific HTML elements.

By default WordPress will run the wptexturize() function on your post’s content, as output with the_content(). This converts common plain text characters into stylised entities, most notably changing straight single and double quotes into their curly equivalents.

'Lorem ipsum' dolor sit 'amet - "consectetur" adipiscing elit...

becomes:

‘Lorem ipsum’ dolor sit ‘amet – “consectetur” adipiscing elit…

Disable for a specific element

WordPress does not texturise the content of pre, code, kbd, style, script and tt elements by default. You can add to this list using the no_texturize_tags filter.

PHP
plugins/pw-examples/pw-examples.php

The above code is displayed using the Code block added by Advanced Gutenberg Blocks which outputs code in textarea elements before formatting it via JavaScript. Here we have added the textarea element so that quotes aren’t converted.

Disable for the entire post

You can stop WordPress ‘texturising’ any post content by removing the wptexturize function from the the_content filter.

PHP
plugins/pw-examples/pw-examples.php

Disable completely

While the above snippet will disable this feature from the main post content, it will still run in other places, for example when outputting the post title. Rather than finding and removing the function from all the relevant filters, we can disable the wptexturize function completely using the run_wptexturize filter.

PHP
plugins/pw-examples/pw-examples.php