Plug-Ins in WordPress

Plug-Ins – Plug what?

In the WordPress application framework, plug ins are a very cool addition.  Plug-ins can help you deploy
a full-blown web application with little to no knowledge of actual code.  The definition of a plug-in provided in the WordPress codex is,

“a program, or a set of one or more functions, written in the PHP scripting language, that adds a specific set of features or services to the WordPress weblog, which can be seamlessly integrated with the weblog using access points and methods provided by the WordPress Plug-in Application Program Interface (API).”

Plug ins allow you to turn your site into anything you can think of, from a basic blog to an e-commerce site to a social
There are a couple of plug-ins that come standard with any new WordPress install:  Hello Dolly and Akismet.  If you didn’t know, the Hello Dolly plugin adds a random lyric from
the song “Hello Dolly” by Louis Armstrong to the top of your dashboard on each page load. It’s not useful, but is a good way to see how to structure your own plug ins.

The Akismet plug-in integrates with to automatically filter out spam comments from your blog. While Hello Dolly is useless outside of its educational value, Akismet is downright necessary on any site with commenting turned on.
You always have the ability to deactivate these plug-ins or delete them altogether if you do not see any use for them on your site.
There are over 26,000 plug-ins available that can be accessed through the official Word‐Press plug-in repository. Not all plug-ins can be found in the repository, so you can always do a search on the Internet for whatever functionality you are looking for. Many plug-in
creators have their work available for download through their personal or business sites and many of these are available for a fee. There are also premium plug-ins, which are supported and that you have to pay to use.

URL Types

When attaching an external JavaScript file to a web page, you need to specify a URL for the src attribute of the <script> tag.  A URL or Uniform Resource Locator is a path to a file—like another web page, a graphic, or a JavaScript file—located on the Web. There are three types of paths:

  • absolute path
  • rootrelative path
  • document-relative path

All three indicate where a web browser can find a particular file.  An absolute path is like a postal address–it contains all the information needed for a web browser located anywhere in the world to find the file.  An absolute path includes http://, the hostname, and the folder and name of the file.  For example:  A root-relative path indicates where a file is located relative to a site’s top-level folder–the site’s root folder.  A root-relative path doesn’t include http:// or the domain name. It begins with a / (slash) indicating the site’s root folder–the folder the home page is in. For example, /scripts/site.js indicates that the file site.js is located inside a folder named scripts, which is itself located in the site’s top-level folder. An easy way to create a root-relative path is to take an absolute path and strip off the http:// and the host name. For example, written as a root-relative URL is just /index.html.

A document-relative path specifies the path from the web page to the JavaScript file. If you have multiple levels of folders on your website, you’ll need to use different paths to point to the same JavaScript file. For example, suppose you have a JavaScript file named site.js located in a folder named scripts in your website’s main directory. The document-relative path to that file will look one way for the home page–scripts/site.js–but for a page located inside a folder named about, the path to the same file would
be different; ../scripts/site.js–the ../ means climb up out of the about folder, while the /scripts/site.js means go to the scripts folder and get the file site.js.

Here are some tips on which URL type to use:

  • If you’re pointing to a file that’s not on the same server as the web page, you must use an absolute path. It’s the only type that can point to another website.
  • Root-relative paths are good for JavaScript files stored on your own site. Because they always start at the root folder, the URL for a JavaScript file will be the same for every page on your website, even when web pages are located in folders and sub folders on your site. However, root-relative paths don’t work unless you’re viewing your web pages through a web server—either your web server out on the Internet, or a web server you’ve set up on your own computer for testing purposes. In other words, if
    you’re just opening a web page off your computer using the browser’s File→ Open command,  the web browser
    won’t be able to locate, load, or run JavaScript files that are attached using a root-relative path.
  • Document-relative paths are the best when you’re designing on your own computer without the aid of a web server. You can create an external JavaScript file, attach it to a web page, and then check the JavaScript in a web browser simply by opening the web page off your hard drive. Document-relative paths work fine when moved to your actual, living, breathing website on the Internet, but you’ll have to rewrite the URLs to the JavaScript file if you move the web page to another location on the server.

What is ? REST API



APIs allow different software to talk to one another. The REST API, for example is an alternative to the outdated XML-RPC, it allows for example, WordPress to easily interact with other websites and services on the Internet using JavaScript Object Notation, or JSON.

Nowadays, the acronym REST has become a buzzword, and as such, it’s being thrown into the digital wind very carelessly by a lot of tech people without fully understanding what it really means. Just because you can interact with a system using HTTP, and send JSON back and forth, doesn’t mean it’s a RESTful system. REST is a lot more than that.

REST has proven to be a huge jump forward regarding distributed systems interconnection, which is what developers were  looking for solutions to ” how to easily interconnect a nonhomogeneous set of systems.”
Developers before REST used to interconnect systems, mainly going over SOAP and XML-RPC (the two main players before REST).