In this tutorial, we will create a “Hello World” shortcode.

1. Self-closing tag: [hello]

2. With attributes: [hello color="blue"]

Setting default attributes:

3. Enclosed Content tag: [hello]World[/hello]

The second argument has the content:

4. Many tags, one callback:

You can define just one callback for many different tags. In this case, use the third argument $tag to differentiate between tags.

Let’s implement two tags, [hello] and [world], with a single callback:

The post Creating Shortcodes on WordPress appeared first on Learn with Daniel.

Using SVN instead of GIT (as your code version control) wouldn’t be more than a mere inconvenience if wasn’t for the fact that WordPress’ SVN is not meant to be used as a code version control. You need to use something else for this.

From WordPress’ official page:

SVN and the Plugin Directory are a release repository. Unlike Git, you shouldn’t commit every small change, as doing so can degrade performance. Please only push finished changes to your SVN repository.

So, if you want to have a code version control (you should have one), you need to set it up separately. Even if you like SVN more than GIT, you must set an additional SVN repo just for your code version control. You can’t use WordPress’ SVN for code control.

In this tutorial, I will show you how to use GIT and SVN together, in an organized way. GIT for code control and SVN for publishing only.

1. Your current development structure:

I am 100% sure you are working in a structure like this:

my-project
└── wp-content
    └── plugins
        └── my-plugin
            └── my-plugin.php

The my-project folder is a full WordPress installation, used as a shell for your plugin development.

my-plugin is your actual plugin folder. It’s where all development happens.

And obviously, my-plugin/my-plugin.php is the plugin’s entry-point.

2. The plan:

Our final folder structure will be:

my-project
├── working-env
│   └── wp-content
│       └── plugins
│           └── my-plugin
│               ├── .git
│               └── my-plugin.php
└── svn
    ├── assets
    ├── branches
    ├── tags
    └── trunk
        ├── .git
        └── my-plugin.php

The working-env folder is our WP instance, just renamed. It is still where we do all our work. Notice that we have initialized GIT on my-plugin, which means the plugin folder is the only thing on GIT. We don’t need to keep the whole WP instance on version control nor make backups of it. In case we need to restore the project (ex. install it in a new machine), we re-create “working-env” from a brand new WP installation and clone the GIT repo in the “my-plugin” folder.

The svn folder is only used for deployment. It has the 4 standard SVN folders: assets, branches, tags, and trunk. This structure is automatically generated by WordPress once we clone the SVN repository. We don’t need to keep this folder on GIT nor make backups of it. Even if we destroy the entire “svn” folder, we can always restore it from the SVN repo. A quick explanation about its structure: the assets folder contains images displayed on the plugin’s page (screenshots, banners and plugin icon). The trunk folder is the current stable version that is available for download on WP.

The workflow is: we work on “my-plugin” (“working-env”) and once is tested and ready for deploy, we update the “trunk” folder (with “my-plugin” files), and we call the svn command to submit.

3. Preparing your code for publishing:

Once your first version is tested and ready to be published, we need to set up the readme.txt file (as per WP’s official guide).

We don’t have our GIT and SVN set up yet, but don’t worry – we will do after preparing our code for publishing.

2.1. Know the rules:

Read the rules for publishing. It only takes a few seconds and you will discover a lot of things that are not allowed (like having a jQuery library on your plugin):
https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

2.2. Choosing a name:

Our plugin must have a name and it must follow these rules:

• Must be unique: Check the WP plugin directory to see if there’s another plugin with the same name as yours.
• Trademark infringement: Do not use trademarks like “Facebook” in your plugin’s name. It is not allowed. For example, “Facebook Sign-Up” is not okay. If you really want to put a trademark on the name, read rule #17 – there are some ways to do it.
• Bad words: Not allowed at all.
• You can’t rename the plugin: So choose the name wisely.

2.3. Edit readme.txt (most IMPORTANT step!!!)

Before publishing your plugin, you MUST edit the readme.txt file. It seems a silly thing to do, but this file actually governs many aspects of the plugin.

The readme file defines the plugin name, version and other control information used for updates and repository management. This file is also the first thing the users will see when looking for plugins on the WP directory (description, screenshots, etc).

If you created your plugin with WP-CLI, you should have a “readme.txt” file with a full example ready to be edited.

Important fields you NEED to set:

• Version (stable tag): Same as in “my-plugin.php” headers (ex. “0.1.0”);
• License (ex. MIT, GPL2, etc): Must be a GPL-compatible license;
• Changelog: Set a “0.1.0: First version”;
• Screenshots: NO SCREENSHOTS for now – just remove this section (even if you have it, we can only define this section AFTER submitting our plugin for the first time);
• Plugin name / Short description / Long description, Author (contributors): Your moment to shine.

For a complete list of all fields (and for a full example):
https://developer.wordpress.org/plugins/wordpress-org/how-your-readme-txt-works/

Test your final “readme.txt” file here:
https://wordpress.org/plugins/developers/readme-validator/

3. Create an SVN repository on WordPress:

Once your readme.txt is ready, let’s create an empty SVN repository on WordPress:

• ZIP your plugin files (except the .git folder if exists);
• Name it as my-plugin.zip (change “my-plugin” to your plugin’s name);
• Test the ZIP file by manually installing the plugin into a different WP installation (Plugins > Add New > Upload Plugin > my-plugin.zip);
• Submit your ZIP file to review: https://wordpress.org/plugins/developers/add/

It can take a few days for your plugin be reviewed. Once approved, you will receive SVN credentials on your email.

Once approved, the SVN repo will be empty. They won’t prefill it with your plugin.

4. Setting GIT:

While you wait your plugin be approved, let’s set GIT on wp-content/plugins/my-plugin.

Gitignore:

If you have used wp-cli, you don’t need to do anything: there will be a .gitignore in your folder. If you haven’t used it, then you will need one:

.DS_Store
phpcs.xml
phpunit.xml
Thumbs.db
wp-cli.local.yml
node_modules/
*.sql
*.tar.gz
*.zip

Init your git repo locally:

cd wp-content/plugins/my-plugin
git init
git add -a
git commit -m "my first commit"

On GitHub (GitLab, etc), create a repo, submit the files (follow the second set of instructions, “Push an existing repository…”):

cd wp-content/plugins/my-plugin
(out)
git remote add origin git@github.com:username/new_repo
git push -u origin master

5. Move your WP installation from my-project to my-project\working-env:

mv my-project working-env
mkdir my-project
mv working-env my-project

Check the structure:

cd my-project
ls
(out)working-env

6. Clone your SVN (it will be empty – they won’t pre-fill it for you with your zip files):

Once the plugin has been approved and you get the SVN credentials on your email:

cd my-project
(out)
mkdir svn
svn co https://plugins.svn.wordpress.org/your-plugin-name svn

Structure of my-project/svn:

/assets/
/branches/
/tags/
/trunk/

7. Ignore .git folder on SVN:

1. Edit ~/.subversion/config
2. Look for the miscellany section, uncomment “global-ignores“, make sure “.git” is there (also “.env” if you use it to store sensitive information):

[miscellany]
global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo __pycache__ .git .gitignore .env

8. [Optional] Add a screenshot to the plugin’s page:

Steps:

• Take a screenshot (any size, ex. 760×500);
• Save the file on “svn/assets”;
• File name must be:
  • screenshot-1.jpg (or png)
  • screenshot-2.jpg (or png)

Change readme.txt:

== Screenshots ==

1. This is a screenshot description
2. This is a description for the second screenshot

Official Guide:
https://developer.wordpress.org/plugins/wordpress-org/plugin-assets/#screenshots

9. [Optional] Add Icon and Banner to the plugin page:

Icon (official guide here):

• Put on “/assets” folder;
• Set filename accordingly (ex. icon-256x256.png – see guide for different formats)
• No need for readme.txt changes.

Banner:
https://developer.wordpress.org/plugins/wordpress-org/plugin-assets/#plugin-headers

10. [FINAL STEP] Submit plugin:

Go to the project root:

cd my-project

Update svn/trunk with your most recent files (my-plugin):

rm -Rf svn/trunk
cp -R working-env/wp-content/plugins/my-plugin svn/trunk

Make sure .git/.gitignore is not going to be submitted:

svn stat

Submit your SVN for the first time:

cd svn
svn add trunk/*
svn ci -m 'Adding first version of my plugin'

Congratulations! Your plugin is now publicly available for download.

Updating your plugin (with a new version):

Do your changes on working-env and test them. Once you are ready, you can proceed.

Update the version:

In this example, let’s change the version from 1.0.0 to 1.0.1.

Change 2 files: readme.txt and my-plugin.php. Don’t forget to add a Changelog entry on “readme.txt”.

Push to GIT:

Go to my-plugin folder:

cd working-env/wp-content/plugins/my-plugin

Add files, commit, and push:

git add -i
git commit -m "some changes"
git push origin master

Submit the new code:

Go to the project root:

cd my-project

Update svn/trunk with your most recent files (my-plugin):

rm -Rf svn/trunk
cp -R working-env/wp-content/plugins/my-plugin svn/trunk

Make sure .git/.gitignore is not going to be submitted:

svn stat

Copy “trunk” to “tags” using the svn command:

svn cp trunk tags/1.0.1

Submit the new version:

svn ci -m "tagging version 1.0.1"

The post Publishing your first WordPress Plugin with GIT and SVN appeared first on Learn with Daniel.

1. ZIP field:

2. Hidden “State” field:

3. Take note of 3 IDs: FormID, ZipID, StateID

In our example:

• Form ID: 15
• ZIP ID: 2
• State ID: 3

4. Add to your theme’s functions.php:

Change the numbers 15, 2, 3 to your actual IDs (lines 4 and 6):

The post Gravity Forms: Populate State from a ZIP Code appeared first on Learn with Daniel.

Solution: Add this code to your functions.php (Appearance > Theme Editor > functions.php):

/**
 * Force notifications when submiting a GravityForm via REST API.
 */
add_action( 'gform_post_add_entry', 'add_entry_callback', 10, 2 );
function add_entry_callback( $entry, $form ) {
  if ($form['id'] === 1) {
    GFAPI::send_notifications( $form, $entry );	
  }
}

NOTICE: Change 1 (in yellow) to the form ID you use on the REST API.

The post [SOLVED] Notifications doesn’t work when submitting a form on GravityForm API appeared first on Learn with Daniel.

On this example let’s transform this:

Into this:

The main thing in our example is that we changed the product list from <table> to <ul>. We have also put the cart totals on the right side and moved the coupons from the product list to the “cart totals”.

1. Clone “cart.php”:

The cart template file is called “cart.php”. But if we change it directly, all our work will be lost (overwritten) once we update the WooCommerce plugin.

The update-safe way to do this is to copy the file we want to change to our theme folder and change this copy. WooCommerce detects the custom file and uses it instead of the default one.

First, create the structure:

cd wp-contents/themes/{yourtheme}
mkdir -p woocommerce/cart/cart.php

mkdir -p a/b/c creates the a/b/c structure even if “a” doesn’t exist.

Then, copy the original file to our new structure:

cp ../../plugins/woocommerce/templates/cart/cart.php ./woocommerce/cart/

2. Edit cart.php and change <table> to <ul>:

Refactor the code, changing the table/tr/td tags to ul/li/div. Feel free to play with the template file and change more elements, add some CSS styling code.

From this (table/tr/td):

To this (ul/li/div):

TIP: For each modification, test it on the browser. Add some CSS styling too.

3. Move “Apply Coupons” to the “Cart Totals” section:

You need to move this “Apply Coupon” HTML code:

To the “Cart Totals” wrapper:

As the inputs are outside the “form” tag, you need to reference the form on the inputs:

Add an id to the form so the reference can work (use a different id if you want):

Final code:

The post Customize your WooCommerce Cart Page Template appeared first on Learn with Daniel.

Gravity Forms doesn’t support icons, but you can easily add them using nothing but pure CSS:

Setting icon images:

To set the icon images, upload them to your “Media” files, get the image URL and set it on #gf_step_<form_id>_<step_number>.

The post Adding icons to GravityForm steps appeared first on Learn with Daniel.

If you want to change the contents of a WooCommerce page, you need to work with hooks. You can also work with templates, but they are very limited on what can be changed.

But don’t worry, I will show here how to change the HTML of the product page (both templates and hooks). You can use this knowledge to change any other WooCommerce page.

Obviously, the easier way to change a WooCommerce page is by CSS. This solution can even remove elements with a display: none; and add others with :before and :after. But of course, it can’t change the HTML structure, which is the goal of this article.

1. Templates:

Don’t expect to have some “product-page.php” file with the whole HTML code for the page, because there’s no such thing.

All pages are rendered programmatically in WooCommerce. Template files are basically a set of commands like “print_sidebar(); print_title() print_price();” and not actual HTML code.

These commands are actually implemented in a hook way. Something like: “do_action(‘print_sidebar’); do_action(‘print_title’);“.

The “Product page” file:

PS: I have stripped the comments for readability.

Whenever the product page is accessed, WooCommerce loads the actions and then the page template above.

The actions are loaded by the wc-template-hooks.php file. This file is called for ALL WC pages, not just the “product page” and it is no more than a collection of “add_filter()” commands:

After the hooks are loaded, the template content-single-product.php file (above) is called.

1.1. Changing the template files:

The template files are all in the plugins/woocommerce/templates folder:

You SHOULD NOT change any of these files directly. Instead, copy the file to wp-contents/themes/{yourtheme}/woocommerce/ and change the copy.

For example, let's say you want to edit single-product/price.php: copy this file to wp-contents/themes/{yourtheme}/woocommerce/single-product/price.php (and edit the copy).

There are few cases you may want to change a template file. You can do it if want to change a DOM element from "<p>" to "<span>", for example. But in most cases, you will want to manipulate the actions and filters in order to change the page HTML.

2. Hooks:

If you look again at the content-single-product.php file, you will notice it has 5 "do_action()". By default, these actions are hooked on the wc-template-hooks.php (called on all WC pages).

The wc-template-hooks.php file sets ALL hooks, for ALL WooCommerce pages. Let's look at the 5 actions used in our "product page" template:

Now, if you want to remove a page element, remove its hook with remove_action(). If you want to change the order of an element, remove the hook and re-add it with a new priority.

Examples:

Where to put these example codes? Put them in your theme's functions.php:

Remove "Short Description":

In your theme's functions.php:

Price before Title:

Description after Title:

Remove Tabs:

Option 1 - Remove hook:

Option 2 - Empty the "tabs" array:

Reference:

The full wc-template-hooks.php file, called on every WC page. This file loads all hooks for page display:

The "product page" file:

The post Customize your WooCommerce product page appeared first on Learn with Daniel.

This tutorial on video (29 seconds, no sound):

1. Open wp-config.php and look for the AUTH_KEY section:

2. Get new session tokens (from the official WP page):

Open: https://api.wordpress.org/secret-key/1.1/salt/

Copy these values (Ctrl+C). Each time you reload this page, new random values are generated.

3. Replace the old values on wp-config.php:

4. Save the file and that’s all!

This procedure kills all the sessions instantly. All the logged-in users will be instantly required to log in again.

This doesn’t affect any credentials. All passwords and usernames remain the same.

The post WordPress: Quickly Log out all users [Quick Tip] appeared first on Learn with Daniel.

The recipe:

sudo dpkg --add-architecture i386
wget -nc https://dl.winehq.org/wine-builds/winehq.key
sudo apt-key add winehq.key
sudo apt-add-repository 'deb https://dl.winehq.org/wine-builds/ubuntu/ disco main'
sudo apt install --install-recommends winehq-staging
rm winehq.key

Then, test it with:

wine --version
(out)wine-4.12.1 (Staging)

PS: This tutorial is based on the official instructions: https://wiki.winehq.org/Ubuntu

The post Install Wine Staging on Ubuntu 19.04 appeared first on Learn with Daniel.

This email address is used for ALL notifications, and unfortunately, you can’t set a different email just for the “New User Registration”.

Luckily, there is a way to fine-tune the “new user registration” notifications and send them to a different email address other than the “admin email address”.

Open your theme’s functions.php (Appearance > Theme Editor > Theme Functions):

That’s it!

In the example, we changed the email address to “john@snow.com“, by using the wp_new_user_notification_email_admin filter.

There are 4 variables you can use: to, subject, message, headers.

Let’s use the headers to send the notification to “john@snow.com” as a CC and keep the admin email as the recipient:

WordPress 4.8 and before:

This solution only works for WordPress 4.9+. For older versions, the filter wp_new_user_notification_email_admin doesn’t exist, but you can redeclare the WP core function wp_new_user_notification() as it is a pluggable function.

WP_REST_User plugin:

If you use the “WP_REST_User” plugin to create users via Ajax/REST, be aware that it doesn’t trigger a “wp_new_user_notification()” by default. So, you will need to add this:

Change admin to both if you want to send a notification to the user too.

The user notification is different than the admin. You can fine-tune the user notification using the filter wp_new_user_notification_email (same 3 arguments on function and same 4 customizable fields).

The post WordPress: Custom admin email for new user registration appeared first on Learn with Daniel.