The more you work with WordPress or PHP in general, the more you will begin to make use of callback functions. In WordPress specifically, one of the more common use of callback functions would be with WordPress Hooks. The use of WordPress Actions and WordPress filters allow WordPress Developers to: add, modify, or remove existing functionality within the WordPress ecosystem. In order to do so, you need to attach a callback function to your desired hook. That callback function is responsible for the task at hand.
This is my first WordPress Tutorial. My goal here in this tutorial is to teach you how to create a WordPress plugin in a simple and organized way, with a focus on code isolation and consistency. By the time you’ve finished this tutorial, you’ll have a plugin shell created which you can use essentially as a boiler plate template for all of your future plugin ideas.
When I develop WordPress Plugins or WordPress Themes, I like to always consider organization and efficiency. Organization comes in many forms. In this article, I’d like to discuss hook organization.
There are times where you might not want an event to occur until another event has occurred; Or maybe you want to have an event conditionally occur before or after another event has occurred.
I was working on a Bootstrap project, which had a vertical accordion menu as a means of navigation. I had it set to keep each menu opened, unless clicked again. Where as a typical accordion menu would close all other menus, except the one recently clicked / opened.
At the very bottom of the accordion menu, I had another block. This was the affixed item. On initial page load, as you scrolled down, the block would automatically affix properly and follow you as you continue to scroll down the page (as expected).
The problem was, what if the user had previously opened one or multiple accordion menus above? This has now adjusted the overall height of the page. Now when you scroll down, the affixed item beneath the accordion menu would now start to affix “prematurely”, causing it to overlap the menu unexpectedly. This is due to the top offset assigned to the item on initial page load.
The affixed item was assigned a top offset on initial page load. The height of the page is adjusted post page load. That means, top offset from the initial page load is no longer valid.
Upon doing some research, I’ve figured out a solution that meets my needs specifically. I’ve tested it several times on large and medium screen sizes. This item isn’t affixed on small or extra small screen sizes.
This article aims at clarifying the difference between a “Local IP Address” assigned by a “Local Network” and a “Remote IP Address” assigned by a “Remote Network”.