w w w. r o y d i g i t a l .

i n

WEBSITE
DESIGN
AND
DEVELOPMENT
 Website Development and Designing

What is the difference between web design and web development?

I remember in my early stages of learning web development, that I found myself confused
multiple times about the differences between design and development. What are the roles
of a web designer? What is involved in working with web design? Our web design and web
development the same? Are they interchangeable terms with the same meaning?

The simple answer would be no. The role of each is completely different from the other. But
let’s have a look into the different roles and methods, of both a web designer and a web
developer.

Ø Web design

Think about web designers as those who transform an idea, or a story, into a visually
appealing design, and use their layout to build the user experience throughout the whole
website. They design the website’s look and feel. As an architect would create a plan of
your house prior to starting building it, similarly a web designer would model the layout of
Web designers have a difficult role which is often underrated. In their designs, they need to
integrate the best user experience possible and create a welcoming environment for the
user. They have to change an idea from writing, into a usable design and interface that
catches the user’s attention. A website cannot be described as great if a proper design
strategy wasn’t applied in the early stages of the project. Nowadays, web designers are
rated at the same level of web developers, as without a great user experience, the
development cannot be truly appreciated by the user.

Web designers have built a whole library of strategic techniques for themselves. You don’t
just create a perfect website immediately after reading or thinking about the specifications
or the features required. You start with a scope — the focus point and the purpose that the
website will offer. You would first roughly envision the designs in your head, and start with a
sketch or draft of the design. From sketching, web designers move to wireframes, mock-
ups, and to the final design. Professional web designers build the whole website in design
components, with a pixel-perfect layout of all the web pages, icons, typography, and other
intricate features.

These are some of the main roles of a web designer:

Ÿ Using software tools such as Adobe Photoshop, Illustrator, or Sketch to build the final
layout design of the website
Ÿ Have good skills in graphic design and logo design
Ÿ Have a good feel for user experience, to identify the simplest approach possible to attain
the desired function. This includes the layout, buttons, images and the general format of
the website.
Ÿ Web designers need to keep themselves up to date with the latest design trends. It’s
also important to keep design consistency that is made popular by other web giant
companies, such as Google, and Facebook. This makes the website environment and
interfaces easier to navigate and use, as it is already familiar to the user's eyes.
Ÿ Web designers have to also keep in mind the branding of the website, color palettes to
be used, and the typography and readability of the website.

Ø Web development

Think about web developers like those who turn the designs into a live website. Web
developers use web languages and software tools to develop the design and functionality
of a website. Notice, that web developers are further split into two sub-categories; front-
end developers, and back-end developers. I see front-end developers as the connection
between both web designers and back-end developers, as having a little knowledge of
both, would allow a front-end developer to build a fully working website. A front-end
developer is the one who builds the interface and provides the layout of the interaction
between the back-end of the website and the user.

Front-end developers use three main languages; Hypertext Markup Language (HTML),
Cascading Style Sheets (CSS), and JavaScript (JS). With these languages, a developer is
able to create a full-fledged website. From the main design layout to inserting images,
applying different types of typography and font families, implementing animations, the flow
of different pages, form interfaces, and more.

Back-end developers are those who control the server data and requests. Usually, a
website requires back-end services if it contains dynamic data. This means, for example,
users submitting a form with personal data (such as creating an account), or saving an
article for your blog page. Generally, if the website requires data to be saved, and making it
accessible at a later stage, it means that it would also need a database connection.
Database connections are made possible by a direct connection from the server itself.
Thus, a back-end developer then uses server languages such as PHP or ASP.NET and
writes database queries by using languages such as SQL or MySQL.

Here are some of the main roles of a web developer:

Ÿ Building the actual interface through which a user interacts with the website. This
interface is built by front-end developers using HTML, CSS, and JS languages.
Ÿ Front-end developers can use styling preprocessors, javascript libraries, and
frameworks to fasten the process of development.
Ÿ Front-end developers provide the markup design to back-end developers, so they can
implement a dynamic website, and submit all the required data on the server and
databases.
Ÿ Back-end developers create the backbone of the website using languages such as
PHP and MySQL.
Ÿ Both front-end and back-end developers can use the same development environments
or IDEs (Integrated Development Environment). These are software application tools
where you code and build the structure of the website.
Ÿ Web developers may also use versioning tools to keep a history of the previous builds.
This will help them to quickly and effortlessly move back to a previous “unbroken”
version if required to do so.

Closing thoughts
What does a full-stack developer do?
Full-stack developers are those who have a good knowledge of all of the development
areas discussed above. This means that if you are a full-stack developer, you should be
able to build a website from scratch, from looking at a design, and creating the markup of
the design, up to handling back-end processes, and database queries. Usually, a full-stack
developer would also have a basic knowledge of design and user experience. Being a full-
stack developer does not mean you have to be an expert on all of the languages. It’s
already hard to become an expert or a professional on just one of the languages. It’s also
hard to learn all the best techniques and strategies on how to be most effective in all of the
areas we discussed above. Remember, web technologies are evolving every day.

a. Page Creation.

Ÿ creating a WordPress page is very similar to creating a post. Just remember that pages
are intended for static content.
Ÿ
Ÿ Creating a WordPress Page
Ÿ To get started adding a new page to your WordPress site, find the Pages menu in the
WordPress Dashboard Navigation menu. Click Add new. The WordPress page editor
looks nearly identical to the post editor, except for a few different boxes located on the
right side of the screen.
Ÿ Add the title of the page, like About. Note: If you have pretty permalinks set up, the title of
your page will also be the URL slug.
Ÿ Next, add some content.
Ÿ The Publish section of the page editor is exactly the same as for writing posts. When
you’re ready to publish, you can either publish immediately, save this or a draft, or
schedule the page to be published later.
Ÿ The Page Attributes section applies a parent page and template to your new page. For
the Parent section, you can arrange your pages into hierarchies. For example, you
could create this new page with additional pages under it. There are no limits to how
many levels you can nest pages.
Ÿ Some WordPress themes have custom page templates, so the next Template section
allows you to apply a template to your new page.
Ÿ The Order box allows you to order your page numerically. Pages are usually ordered
alphabetically, but you can choose your own order by entering a number in this field.
Ÿ Preview the page one last time, then click Publish. You’ve added a new page to your
WordPress site.

b. Menu Setup

How to Add a Mega Menu on Your WordPress Site (Step by Step)

Mega Menus allow you to add a multi-column drop-down menu to your navigation with rich
media such as images and videos. In this article, we will show you how to easily add a
mega menu to your WordPress site.
Why and Who Should Add Mega Menu in WordPress?

Mega Menus are particularly helpful for websites with a lot of content. This allows website
owners to show more items in their top menu.

Popular websites like Reuters, Buzzfeed, and Starbucks use mega menus to display
highly engaging and interactive navigation menus.
While default WordPress navigation menus let you add drop-down sub-menus and even
add image icons next to each item, sometimes you just need a mega menu.

Adding a Mega Menu in WordPress

The first thing you need to do is install and activate the Max Mega Menu plugin. It is the
best free mega menu WordPress plugin available on the market. For more details, see
our step by step guide on how to install a WordPress plugin.

Upon activation, the plugin will add a new menu item, Mega Menu, to your WordPress
admin menu. Clicking on it will take you to the plugin’s settings page.

The default settings will work for most websites. However, you will need to change the
menu colors, so they match the colors used by your WordPress theme’s navigation menu
container.

To find out which colors are used in your theme, you can use the Inspect tool in your
browser.
Once you get the color hex code, you can paste it in a text file to use later.
Next, you need to visit the mega menu settings page, click on the ‘Menu Themes’ tab and
then click on ‘Menu Bar’ section.
Here you can replace the background color used by mega menu to match your theme’s
navigation menu container.
Don’t forget to click on the save changes button to store your settings.
Now that we have configured the mega menu settings, let’s go ahead and create our mega
menu.
First, you need to visit the Appearance » Menus page and then add top-level items to
your navigation. For detailed instructions see our beginner’s guide on creating navigation
menus in WordPress.
Next, on the Menus screen, you need to enable the mega menu by checking the box under
‘Max Mega Menu Settings’.

After that, you need to take your mouse to a menu item, and you will see a “Mega Menu”
button appear on the menu tab.

Clicking on the button will bring up a popup. Here you can add any WordPress widget to
your mega menu and select the number of columns you want to display.
You can also click on the wrench icon on a widget to edit the widget settings. Don’t forget to
click on the save button to store your widget settings.

Once you are done, you can close the popup and visit your website to see the mega menu
in action.
We hope this article helped you learn how to add a mega menu in WordPress. You may
also want to see our guide on how to speed up WordPress and boost performance for
beginners.

c. Theme Setup and customization

How to Customize WordPress Themes Tutorial

Depending on the theme you're using for your WordPress site there are a different set of
changes you can make to your site from within your admin panel. This tutorial explains
how to do some of the changes to your site using the Customization page. For the
purpose of this tutorial, we will use the Twenty Seventeen theme.

How to Access the WordPress Customization Page

To start customizing your WordPress theme, first go to Appearance -> Themes page.

On this page, locate the active theme (Twenty Seventeen in our case) and click on the
Customize button next to its title.
On the page that opens, you can modify your WordPress theme in real time. On the left you
will see a list of the available options and on the right a live preview of your site and how
those changes will affect it.
How to Modify your WordPress Title and Tagline

The theme customization page allows you to modify your site's title and tagline and see
how it will look on your actual site immediately. To do this, expand the Site Identity group
of settings and alter the text. As you type you will see the new text showing up in the
preview on the right side. Once you're happy with the result, simply click on the big Save &
Publish button.

Additional WordPress Theme Customizations

Depending on the theme you're using there might be additional options in that page. For
example, the Twenty Seventeen theme allows you to modify header image, color scheme,
add additional css and more. Once you're happy with the result, simply click on the Save &
Publish button to save the changes.
d. Understanding of Plugins and usage
How Plug-ins are used

Plug-ins offer a rich variety of features that can increase the flexibility of Gecko-based
browsers. Plug-ins like these are now available:
Ÿ multimedia viewers such as Adobe Flash and Adobe Acrobat
Ÿ utilities that provide object embedding and compression/decompression services
Ÿ applications that range from personal information managers to games
The range of possibilities for using plug-in technology seems boundless, as shown by the
growing numbers of independent software vendors who are creating new and innovative
plug-ins.

With the Plug-in API, you can create dynamically loaded plug-ins that can:
Ÿ register one or more MIME types
Ÿ draw into a part of a browser window
Ÿ receive keyboard and mouse events
Ÿ obtain data from the network using URLs
Ÿ post data to URLs
Ÿ add hyperlinks or hotspots that link to new URLs
Ÿ draw into sections on an HTML page
Ÿ communicate with JavaScript/DOM from native code
You can see which plug-ins are installed on your system and have been properly
associated with the browser by consulting the Installed Plug-ins page. Type
"about:plugins" in the Location bar. The Installed Plug-ins page lists each installed plug-in
along with its MIME type or types, description, file extensions, and the current state
(enabled or disabled) of the plug-in for each MIME type assigned to it.
Notice in view-source that this information is simply gathered from the JavaScript.

Because plug-ins are platform-specific, you must port them to every operating system and
processor platform upon which you want to deploy your plug-in.

Plug-ins and helper applications

Before plug-ins, there were helper applications. A helper application is a separate, free-
standing application that can be started from the browser. Like a plug-in, the browser
starts a helper application when the browser encounters a MIME type that is mapped to it.
Unlike a plug-in, a helper application runs separately from the browser in its own
application space and does not interact with the browser or the web.

When the browser encounters a MIME type, it always searches for a registered plug-in
first. If there are no matches for the MIME type, it looks for a helper application.

Plug-ins and helper applications fill different application needs.

How plug-ins work

The life cycle of a plug-in, unlike that of an application, is completely controlled by the web
page that calls it. This section gives you an overview of the way that plug-ins operate in the
browser.

When Gecko starts, it looks for plugin modules in particular places on the system. For
more information about where Gecko looks for plugin modules on different systems, see
How Gecko Finds Plug-ins.

When the user opens a page that contains embedded data of a media type that invokes a
plug-in, the browser responds with the following sequence of actions:
Ÿ check for a plug-in with a matching MIME type
Ÿ load the plug-in code into memory
Ÿ initialize the plug-in
Ÿ create a new instance of the plug-in
Gecko can load multiple instances of the same plug-in on a single page, or in several open
windows at the same time. If you are browsing a page that has several embedded
RealAudio clips, for example, the browser will create as many instances of the RealPlayer
plug-in as are needed (though of course playing several RealAudio files at the same time
would seldom be a good idea). When the user leaves the page or closes the window, the
plug-in instance is deleted. When the last instance of a plug-in is deleted, the plug-in code
is unloaded from memory. A plug-in consumes no resources other than disk space when it
is not loaded. The next section, Understanding the Runtime Model, describes these
stages in more detail.
Understanding the runtime model

Plug-ins are dynamic code modules that are associated with one or more MIME types.
When the browser starts, it enumerates the available plug-ins (this step varies according
to platform), reads resources from each plug-in file to determine the MIME types for that
plug-in, and registers each plug-in library for its MIME types.

The following stages outline the life of a plug-in from loading to deletion:

Ÿ When Gecko encounters data of a MIME type registered for a plug-in (either embedded
in an HTML page or in a separate file), it dynamically loads the plug-in code into
memory, if it hasn't been loaded already, and it creates a new instance of the plug-in.

Gecko calls the plug-in API function NP_Initialize when the plug-in code is first loaded. By
convention, all of the plug-in specific functions have the prefix "NPP", and all of the
browser-specific functions have the prefix "NPN".

Note: NP_Initialize and NP_Shutdown are not technically a part of the function table that
the plug-in hands to the browser. The browser calls them when the plug-in software is
loaded and unloaded. These functions are exported from the plug-in DLL and accessed
with a system table lookup, which means that they are not related to any particular plug-in
instance. Again, see Initialization and Destruction for more information about initializing
and destructing.

Ÿ The browser calls the plug-in API function NPP_New when the instance is created.
Multiple instances of the same plug-in can exist (a) if there are multiple embedded
objects on a single page, or (b) if several browser windows are open and each displays
the same data type.
Ÿ A plug-in instance is deleted when a user leaves the instance's page or closes its
window; Gecko calls the function NPP_Destroy to inform the plug-in that the instance is
being deleted.
Ÿ When the last instance of a plug-in is deleted, the plug-in code is unloaded from
memory. Gecko calls the function NP_Shutdown. Plug-ins consume no resources
(other than disk space) when not loaded.

Note: Plug-in API calls and callbacks use the main Navigator thread. In general, if you
want a plug-in to generate additional threads to handle processing at any stage in its
lifespan, you should be careful to isolate these from Plug-in API calls.
See Initialization and Destruction for more information about using these methods.

Plug-in detection

Gecko looks for plug-ins in various places and in a particular order. The next section, How
Gecko Finds Plug-ins, describes these rules, and the following section, Checking Plug-ins
by MIME Type, describes how you can use JavaScript to locate plug-ins yourself and
establish which ones are to be registered for which MIME types.
How Gecko finds plug-ins
When a Gecko-based browser starts up, it checks certain directories for plug-ins, in this
order:

Ø Windows

Ÿ Directory pointed to by MOZ_PLUGIN_PATH environment variable.

Ÿ %APPDATA%\Mozilla\plugins, where %APPDATA% denotes per-user Application
Data directory.
Ÿ Plug-ins within toolkit bundles.
Ÿ Profile directory\plugins, where Profile directory is a user profile directory.
Ÿ D i r e c t o r i e s p o i n t e d t o b y
HKEY_CURRENT_USER\Software\MozillaPlugins\*\Pathregistry value, where * can
be replaced by any name.
Ÿ Directories pointed to by HKEY_LOCAL_MACHINE\Software\MozillaPlugins\*\Path
registry value, where *can be replaced by any name.

Ø Mac OS X

Ÿ ~/Library/Internet Plug-Ins.
Ÿ /Library/Internet Plug-Ins.
Ÿ /System/Library/Frameworks/JavaVM.framework/Versions/Current/Resources.
Ÿ Plug-ins within toolkit bundles.
Ÿ Profile directory/plugins, where Profile directory is a user profile directory.

Ø Linux

Ÿ Directory pointed to by MOZ_PLUGIN_PATH environment variable. For example:

#!/bin/bash
export MOZ_PLUGIN_PATH=/usr/lib64/mozilla/plugins
exec /usr/lib64/firefox/firefox
Ÿ Profile directory/plugins, where Profile directory is the directory of the current user
profile.
Ÿ ~/.mozilla/plugins.
Ÿ /usr/lib/mozilla/plugins (the 64-bit Firefox checks /usr/lib64/mozilla/plugins as well).
Ÿ /usr/lib64/firefox/plugins (for 64-bit Firefox)

Note: Firefox Nightly checks a subset of these locations. Also some Linux distributions
provide a system browser configured differently.

Advanced: You can determine which directories a Gecko program checks with the Linux
strace command, for example:
Ÿ strace -e open /usr/bin/firefox 2>&1 | grep plugin
Ÿ But with version firefox-41.0.2 we can not check. I found other way how check which
paths support Firefox :
$ strace -y /usr/bin/firefox 2>&1 | grep acces | grep -v search | grep plugins
access("/home/user_name/.mozilla/firefox/dqh2nb5k.default-1441864569209/plugins",
F_OK) = -1 ENOENT (No such file or directory)
access("/home/user_name/.mozilla/plugins", F_OK) = -1 ENOENT (No such file or
directory)
access("/usr/lib64/firefox/browser/plugins", F_OK) = -1 ENOENT (No such file or
directory)
access("/usr/lib/mozilla/plugins", F_OK) = 0

This output I have after close Firefox. I checked also this command with above script (with
environment variable) on my system and also working.

However, primary working path with binary file was /usr/lib/mozilla/plugins

for 32-bit and 64-bit Linux distributions and looks still working.

Firefox and OpenSuse probably use "MOZ_PLUGIN_PATHenvironment variable" in

script to run Firefox, so in this way /usr/lib64/mozilla/plugins also should be supported.
About distributions:
Example Debian 64bit probably use:
/lib/x86_64-linux-gnu/ --> for 64 libs
/lib/i386-linux-gnu/ --> for 32 libs
if exist
/lib32/ --> this is symlinked (or bind mounted) desired
proper directory
/lib64/ --> this is symlinked (or bind mounted) desired
proper directory
more in https://wiki.debian.org/Multiarch/TheCaseForMultiarch

something wrong, please edit.

Example Fedora 64bit use:

/lib/ --> for 32 bit libs
/lib64/ --> for 64 bit libs

Ÿ Plug-ins within toolkit bundles.

To find out which plug-ins are currently installed visit about:plugins. Gecko displays a page
listing all installed plug-ins and the MIME types they handle, as well as optional descriptive
information supplied by the plug-in.

On Windows, installed plug-ins are automatically configured to handle the MIME types
that they support. If multiple plug-ins handle the same MIME type, the first plug-in
registered handles the MIME type. For information about the way MIME types are
assigned, see Registering Plug-ins.

Checking plug-ins by MIME type

The enabledPlugin property in JavaScript can be used to determine which plug-in is
configured for a specific MIME type. Though plug-ins may support multiple MIME types
and each MIME type may be supported by multiple plug-ins, only one plug-in can be
configured for a MIME type. The enabledPlugin property is a reference to a Plugin object
that represents the plug-in that is configured for the specified MIME type.

You might need to know which plug-in is configured for a MIME type, for example, to
dynamically create an object element on the page if the user has a plug-in configured for
the MIME type.

The following example uses JavaScript to determine whether the Adobe Flash plug-in is
installed. If it is, a movie is displayed.

// Can we display Adobe Flash movies?

var mimetype = navigator.mimeTypes["application/x-shockwave-flash"];

if (mimetype) {
// Yes, so can we display with a plug-in?
var plugin = mimetype.enabledPlugin;
if (plugin) {
// Yes, so show the data in-line
document.writeln("Here\'s a movie: <object data='mymovie.swf' height='100'
width='100'></object>");
} else {
// No, so provide a link to the data
document.writeln("<a href='mymovie.swf'>Click here</a> to see a movie.");
}
} else {
// No, so tell them so
document.writeln("Sorry, can't show you this movie.");
}

Overview of plug-in structure

This section is an overview of basic information you will need as you develop plug-ins
.
Ÿ Understanding the Plug-in API
Ÿ Plug-ins and Platform Independence

Understanding the plug-in API

A plug-in is a native code library whose source conforms to standard C syntax. The Plug-in
Application Programming Interface (API) is made up of two groups of functions and a set of
shared data structures.

Ÿ Plug-in methods are functions that you implement in the plug-in; Gecko calls these
functions. The names of all the plug-in functions in the API begin with NPP_, for
example, NPP_New. There are also a couple of functions (i.e., NP_Initialize and
 NP_Shutdown) that are direct library entry points and not related to any particular
plug-in instance.
Ÿ Browser methods are functions implemented by Gecko; the plug-in calls these
functions. The names of all the browser functions in the API begin with NPN_, for
example, NPN_Write.
Ÿ Data structures are plug-in-specific types defined for use in the Plug-in API. The names
of structures begin with NP, for example, NPWindow.

All plug-in names in the API start with NP. In general, the operation of all API functions is
the same on all platforms. Where this varies, the reference entry for the function in the
reference section describes the difference.

Plug-ins and platform independence

A plug-in is a dynamic code module that is native to the specific platform on which the
browser is running. It is a code library, rather than an application or an applet, and runs
only from the browser. Although plug-ins are platform-specific, the Plug-in API is designed
to provide the maximum degree of flexibility and to be functionally consistent across all
platforms. This guide notes platform-specific differences in coding for the MS Windows,
Mac OS X, and Unix platforms.

You can use the Plug-in API to write plug-ins that are media type driven and provide high
performance by taking advantage of native code. Plug-ins give you an opportunity to
seamlessly integrate platform-dependent code and enhance the Gecko core functionality
by providing support for new data types.

The plug-in file type depends on the platform:

Ÿ MS Windows: .DLL (Dynamic Link Library) files

Ÿ Unix: .SO or .DSO (Shared Objects) files
Ÿ Mac OS X: PPC/x86/Universal loadable Mach-O bundle

Windowed and windowless plug-ins

You can write plug-ins that are drawn in their own native windows or frames on a web
page. Alternatively, you can write plug-ins that do not require a window to draw into. Using
windowless plug-ins extends the possibilities for web page design and functionality. Note,
however, that plug-ins are windowed by default, because windowed plug-ins are in
general easier to develop and more stable to use.

Ÿ A windowed plug-in is drawn into its own native window on a web page. Windowed
plug-ins are opaque and always come to the top HTML section of a web page.
Ÿ A windowless plug-in need not be drawn in a native window; it is drawn in its own
drawing target. Windowless plug-ins can be opaque or transparent, and can be invoked
in HTML sections.
Whether a plug-in is windowed or windowless depends on how you define it.

The way plug-ins are displayed on the web page is determined by the HTML element that
invokes them. This is up to the content developer or web page author. Depending on the
element and its attributes, a plug-in can be visible or hidden, or can appear as part of a
page or as a full page in its own window. A web page can display a windowed or windowless
plug-in in any HTML display mode; however, the plug-in must be visible for its window type
to be meaningful. For information about the way HTML determines plug-in display mode,
see "Using HTML to Display Plug-ins.”

Using HTML to Display Plug-Ins

When a user browses to a web page that invokes a plug-in, how the plug-in appears (or
does not appear) depends on two factors:

Ÿ The way the developer writes the plug-in determines whether it is displayed in its own
window or is windowless.
Ÿ The way the content provider uses HTML elements to invoke the plug-in determines its
display mode: whether it is embedded in a page, is part of a section, appears on its own
separate page, or is hidden.

This section discusses using HTML elements and display modes. For information about
windowed and windowless operation, see Windowed and Windowless Plug-ins.

For a description of each plug-in display mode, and which HTML element to use to achieve
it, go on to Plug-in Display Modes. For details about the HTML elements and their
attributes, go on to:

Ÿ Using the object Element for Plug-in Display

Ÿ Using the embed Element for Plug-in Display

Plug-in display modes

Whether you are writing an HTML page to display a plug-in or developing a plug-in for an
HTML author to include in a page, you need to understand how the display mode affects the
way plug-ins appear.

A plug-in, whether it is windowed or windowless, can have one of these display modes:

Ÿ embedded in a web page and visible

Ÿ embedded in a web page and hidden
Ÿ displayed as a full page in its own window

An embedded plug-in is part of a larger HTML document and is loaded at the time the
document is displayed. The plug-in is visible as a rectangular subpart of the page (unless it
is hidden). Embedded plug-ins are commonly used for multimedia images relating to text
in the page, such as the Adobe Flash plug-in. When Gecko encounters the object or
embed element in a document, it attempts to find and display the file represented by the
data and src attributes, respectively. The height and width attributes of the object element
determine the size of the embedded plug-in in the HTML page. For example, this object
element calls a plug-in that displays video:

<object data="newave.avi" type="video/avi"

width="320" height="200"
autostart="true" loop="true">

</object>

A hidden plug-in is a type of embedded plug-in that is not drawn on the screen when it is
invoked. It is created by using the hidden attribute of the embedelement. Here's an
example:

<embed src="audiplay.aiff" type="audio/x-aiff" hidden="true">

Note: Whether a plug-in is windowed or windowless is not meaningful if the plug-in is

invoked with the hidden attribute.

You can also create hidden plug-ins using the object element. Though the object element
has no hidden attribute, you can create CSS rules to override the sizing attributes of the
object element
object {
visibility: visible;
}

object.hiddenObject {
visibility: hidden !important;
width: 0px !important;
height: 0px !important;
margin: 0px !important;
padding: 0px !important;
border-style: none !important;
border-width: 0px !important;
max-width: 0px !important;
max-height: 0px !important;
}

In this case, the object element that picks up these special style definitions would have a
class of hidden. Using the class attribute and the CSS block above, you can simulate the
behavior of the hidden plug-in in the embed element:

<object data="audiplay.aiff" type="audio/x-aiff" class="hiddenObject"></object>

A full-page plug-in is a visible plug-in that is not part of an HTML page. The server looks for
the media (MIME) type registered by a plug-in, based on the file extension, and starts
sending the file to the browser. Gecko looks up the MIME type and loads the appropriate
plug-in if it finds a plug-in registered to that type. This type of plug-in completely fills the
web page. Full-page plug-ins are commonly used for document viewers, such as Adobe
Acrobat.

Note: The browser does not display scroll bars automatically for a full-page plug-in. The
plug-in must draw its own scroll bars if it requires them.
The browser user interface remains relatively constant regardless of which type of plug-in
is displayed. The part of the application window that does not display plug-in data does not
change. The basic operations of the browser, such as navigation, history, and opening
files, apply to all pages, regardless of the plug-ins in use.

Using the object element for plug-in display

The <object> element is part of the HTML specification for generic inclusion of special
media in a web page. It embeds a variety of object types in an HTML page, including plug-
ins, Java components, ActiveX controls, applets, and images. object element attributes
determine the type of object to embed, the type and location of the object's
implementation (code), and the type and implementation of the object's data.

Plug-ins were originally designed to work with the embed element rather than the object
element (see Using the embed Element for Plug-in Display), but the object element
itself provides some flexibility here. In particular, the object element allows you to invoke
another object if the browser cannot support the object invoked by the element. The
embed element, which is also used for plug-ins, does not.

The object element is also a part of the HTML W3C standard.

Also, unlike the <applet> element, object can contain other HTML elements including
other object elements, nested between its opening and closing tags. So, for example,
though Gecko does not support the classid attribute of the object element - which was
used for Java classes and ActiveX plug-ins embedded in pages - object elements can be
nested to support different plug-in implementations.

See the Mozilla ActiveX project page in the Plug-in References section below for more
information about embedding ActiveX controls in plug-ins or embedding plug-ins in
ActiveX applications.

The following examples demonstrate this use of nested object elements with markup
more congenial to Gecko included as children of the parent object element.

Example 1: Nesting object Elements

<html>
<head>
<title>Example 1: Nesting object Elements</title>
<style type="text/css">
.myPlugin {
width: 470px;
height: 231px;
}
</style>

</head>
<body><p>
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"

codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#v
ersion=5,0,30,0"
class="myPlugin">

<param name="movie" value="foo.swf"/>

<param name="quality" value="high"/>
<param name="salign" value="tl"/>
<param name="menu" value="0"/>

<object data="foo_movie.swf"
type="application/x-shockwave-flash"
class="myPlugin"/>

<param name="quality" value="high"/>

<param name="salign" value="tl"/>
<param name="menu" value="0"/>

<object type="*" class="myPlugin">

<param name="pluginspage"

value="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version
=ShockwaveFlash"/>
</object>

</object>
</object>
</p></body>
</html>

The outermost object element defines the classid; the first nested object uses the type
value application/x-shockwave-flash to load the Adobe Flash plug-in, and the innermost
object exposes a download page for users that do not already have the necessary plug-in.
This nesting is quite common in the use of objectelements, and lets you avoid code forking
for different browsers.

Nesting rules for HTML elements

The rules for descending into nested object and embed elements are as follows:
Ÿ The browser looks at the MIME type of the top element. If it knows how to deal with that
MIME type (i.e., by loading a plug-in that's been registered for it), then it does so.
Ÿ If the browser cannot handle the MIME type, it looks in the element for a pointer to a
plug-in that can be used to handle that MIME type. The browser downloads the
requested plug-in.
Ÿ If the MIME type is unknown and there is no reference to a plug-in that can be used, the
browser descends into the child element, where these rules for handling MIME types
are repeated.

The rest of this section is a brief introduction to this HTML element. For more information
on the object element and other elements used for plug-in display, see W3C HTML 4.01
specification.

To embed a variety of object types in an HTML page, use the object element.

<object
classid="classFile"
data="dataLocation"
codebase="classFileDir"
type="MIMEtype"
align="alignment"
height="pixHeight"
width="pixWidth"
id="name"
>

...

</object>

The first set of object element attributes are URLs.

Ÿ classid is the URL of the specific object implementation. This attribute is similar to the
code attribute of the applet element. Though Gecko does not support this object
attribute, you can nest object elements with different attributes to use the object
element for embedding plug-ins on any browser platform (see the example above).
Ÿ data represents the URL of the object's data; this is equivalent to the srcattribute of
embed.
Ÿ codebase represents the URL of the plug-in; this is the same as the codebaseattribute
of the applet element. For plug-ins, codebase is the same as pluginspace.
Ÿ type represents the MIME type of the plug-in; this is the same as the typeattribute of
embed.
Ÿ height, width, align are basic img/embed/applet attributes supported by object. height
and width are required for object elements that resolve to embed elements.
Ÿ Use the id attribute, which specifies the name of the plug-in, if the plug-in is
communicating with JavaScript. This is equivalent to the name attribute of applet and
embed. It must be unique.
Using the appropriate attributes

It's up to you to provide enough attributes and to make sure that they do not conflict; for
example, the values of width and height may be wrong for the plug-in. Otherwise, the plug-
in cannot be embedded.

Gecko interprets the attributes as follows: When the browser encounters an

objectelement, it goes through the element attributes, ignoring or parsing as appropriate. It
analyzes the attributes to determine the object type, then determines whether the browser
can handle the type.

Ÿ If the browser can handle the type-that is, if a plug-in exists for that type-then all
elements and attributes up to the closing </object> element, except param elements
and other object elements, are filtered.
Ÿ If the browser cannot handle the type, or cannot determine the type, it cannot embed the
object. Subsequent HTML is parsed as normal.

Using the embed element for plug-in display

A plug-in runs in an HTML page in a browser window. The HTML author uses the HTML
<embed> element to invoke the plug-in and control its display. Though the object element
is the preferred way to invoke plug-ins (see Using the object Element for Plug-in
Display), the embed element can be used for backward compatibility with Netscape 4.x
browsers, and in cases where you specifically want to prompt the user to install a plug-in,
because the default plug-in is only automatically invoked when you use the embed
element.

Gecko loads an embedded plug-in when the user displays an HTML page that contains an
embedded object whose MIME type is registered by a plug-in. Plug-ins are embedded in
much the same way as GIF or JPEG images are, except that a plug-in can be live and
respond to user events, such as mouse clicks.

The embed element has the following syntax and attributes:

<embed
src="location"
type="mimetype"
pluginspage="instrUrl"
pluginurl="pluginUrl"
align="left"|"right"|"top"|"bottom"
border="borderWidth"
frameborder="no"
height="height"
width="width"
units="units"
hidden="true|false"
hspace="horizMargin"
vspace="vertMargin"
name="pluginName"
palette="foreground"|"background"
>

...

</embed>

You must include either the src attribute or the type attribute in an embe delement. If you do
not, then there is no way of determining the media type, and so no plug-in loads.

The src attribute is the URL of the file to run. The type attribute specifies the MIME type of
the plug-in needed to run the file. Navigator uses either the value of the type attribute or the
suffix of the filename given as the source to determine which plug-in to use.

Use type to specify the media type or MIME type necessary to display the plug-in. It is good
practice to include the MIME type in all the plug-in HTML elements. You can use type for a
plug-in that requires no data, for example, a plug-in that draws an analog clock or fetches
all of its data dynamically. For a visible plug-in, you must include width and height if you use
type; no default value is used.

The pluginurl attribute is the URL of the plug-in or of the XPI in which the plug-in is stored
(see Installing Plug-ins for more information on the XPI file format).

The embed element has a number of attributes that determine the appearance and size of
the plug-in instance, including these:

Ÿ The border and frameborder attributes specify the size of a border for the plug-in or draw
a borderless plug-in.
Ÿ height, width, and units determine the size of the plug-in in the HTML page. If the plug-in
is not hidden, the height and width attributes are required.
Ÿ hspace and vspace create a margin of the specified width, in pixels, around the plug-in.
Ÿ align specifies the alignment for the plug-in relative to the web page.
Use the hidden attribute if you do not want the plug-in to be visible. In this case, you do not
need the attributes that describe plug-in appearance. In fact, hidden overrides those
attributes if they are present.

Use the name attribute, which specifies the name of the plug-in or plug-in instance, if the
plug-in is communicating with JavaScript.

For example, this embed element loads a picture with the imaginary data type dgs:

<embed src="mypic.dgs" width="320" height="200" border="25" align="right">

Gecko interprets the attributes as follows:

Ÿ src: Load the data file and determine the MIME type of the data.
Ÿ width and height: Set the area of the page handled by the plug-in to 320 by 200 pixels. In
general, use CSS to control the size and location of elements within an HTML page.
Ÿ border: Draw a border 25 pixels wide around the plug-in.
Ÿ align: Align the plug-in at the right side of the web page.
The following example shows an embed element nested within an object element, which is
necessary for browsers that do not support the embed element.

Example 2: embed within object

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"

codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#v
ersion=5,0,30,0"
width="749" height="68">

<param name="movie" value="foo.swf">

<param name="quality" value="high">
<param name="bgcolor" value="#EEEEEE">
<param name="salign" value="tl">
<param name="menu" value="0">

<embed src="foo.swf"
quality="high"
pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_V
ersion=ShockwaveFlash"
type="application/x-shockwave-flash"
width="749"
height="68"
bgcolor="#EEEEEE"
salign="tl"
menu="0">

</embed>

</object>

Using custom embed attributes

In addition to these standard attributes, you can create private, plug-in-specific attributes
and use them in the embed attribute to pass extra information between the HTML page
and the plug-in code. The browser ignores these nonstandard attributes when parsing the
HTML, but it passes all attributes to the plug-in, allowing the plug-in to examine the list for
any private attributes that could modify its behavior.

For example, a plug-in that displays video could have private attributes that determine
whether to start the plug-in automatically or loop the video automatically on playback, as in
the following embed element:

<embed src="myavi.avi" width="100" height="125" autostart="true" loop="true">

With this embed element, Gecko passes the values to the plug-in, using the arg
parameters of the NPP_New call that creates the plug-in instance.
argc = 5
argn = {"src", "width", "height", "autostart", "loop"}
argv = {"movie.avi", "100", "125", "true", "true"}

Gecko interprets the attributes as follows:

Ÿ src: Load the data file and determine the MIME type of the data.
Ÿ width and height: Set the area of the page handled by the plug-in to 100 by 125 pixels.
Ÿ autostart and loop: Ignore these private attributes and pass them along to the plug-in
with the rest of the attributes.

The plug-in must scan its list of attributes to determine whether it should automatically
start the video and loop it on playback. Note that with an objectelement, param values are
also sent in this array after the attributes, separated by a param entry.

e. Widgets customization

WordPress Widgets add content and features to your Sidebars. Examples are the default
widgets that come with WordPress; for Categories, Tag cloud, Search, etc. Plugins will
often add their own widgets.

Widgets were originally designed to provide a simple and easy-to-use way of giving
design and structure control of the WordPress Theme to the user, which is now available
on properly "widgetized" WordPress Themes to include the header, footer, and elsewhere
in the WordPress design and structure. Widgets require no code experience or expertise.
They can be added, removed, and rearranged on the Theme Customizer Appearance >
Widgets in the WordPress Administration Screens.

Some WordPress Widgets offer customization and options such as forms to fill out,
includes or excludes of data and information, optional images, and other customization
features.

The Appearance Widgets Screen explains how to use the various Widgets that come
delivered with WordPress.

Plugins that come bundled with widgets can be found in the WordPress Plugin Directory.

Installing Widgets

WordPress comes pre-packaged with a variety of Widgets. If those are insufficient for your
needs you can install new ones by searching the WordPress Plugin Directory which is
accessible from the WordPress Administration Plugins > Add New Screen.

Displaying Widgets

Existing Widgets in Existing Widget Areas

Before you can add a Widget you must verify that the Theme you're using supports Widgets
(more specifically: Widget Areas). You can do so by simply navigating to the Appearance
menu and looking for a submenu titled "Widgets".
If your Theme supports Theme Customizer then you can use the following Steps. In Theme
Customizer, the live preview of changes is available.

Ÿ Go to Appearance > Customize in the WordPress Administration Screens.

Ÿ Click the Widget menu in the Theme Customizer to access to the Widget Customize
Screen.
Ÿ Click the down arrow of Widget Area to list the already registered Widgets.
Ÿ Click Add a Widget button at the bottom of the sidebar. It shows the list of available
widgets.
Ÿ Click a widget you want to add. The widgets should be added in the sidebar.
Ÿ Preview your site and you should see the content from your new Widget.
Ÿ To arrange the Widgets within the Sidebar, drag and drop the widgets in the order you
want or click Reorder link and click up arrow and down allow of each widget and click
Done after the arrange operation.
Ÿ To customize the Widget features, click the down arrow in the right to expand the
Widget's interface.
Ÿ To remove the widget, click Remove from Widget's interface in above step.
If your Theme does not support Theme Customizer then you can use the following
conventional steps:

Ÿ Go to appearance > widgets in the wordpress administration screens.

Ÿ Choose a widget and either drag it to the sidebar where you wish it to appear, or click the
widget, (select a destination sidebar if your theme has more than one) and click the add
widget button. There might be more than one sidebar option, so begin with the first one.
Once in place, wordpress automatically updates the theme.
Ÿ Preview the site. You should find that the "default" sidebar elements are now gone and
only the new addition is visible.
Ÿ Return to the widgets screen to continue adding widgets.
Ÿ To arrange the widgets within the sidebar or widget area, click and drag it into place.
Ÿ To customize the widget features, click the down arrow in the upper right corner to
expand the widget's interface.
Ÿ To save the widget's customization, click save.
Ÿ To remove the widget, click delete.

If you want to remove the widget but save its setting for possible future use, just drag it into
the Inactive Widgets area. You can add them back anytime from there. This is especially
helpful when you switch to a theme with fewer or different widget areas.

When changing themes, there is often some variation in the number and setup of widget
areas/sidebars and sometimes these conflicts make the transition a bit less smooth. If you
changed themes and seem to be missing widgets, scroll down on the screen to the
Inactive Widgets area, where all of your widgets and their settings will have been saved.
Enabling Accessibility Mode, via Screen Options, allows you to use Add and Edit buttons
instead of using drag and drop.

Widget Areas

While widget areas typically occur in webpage sidebars, a theme can place widget areas
anywhere on a page. For example, besides the usual sidebar locations, the Twenty
Fourteen theme has a widget area in the footer of every page.

If you would like to place a Widget somewhere on your Theme that does not have a pre-
defined Widget Area, you will need some programming knowledge and should follow the
instructions on the Widgets API.

Using Text Widgets

The Text Widget is one of the most commonly used WordPress Widgets that comes with
every WordPress installation. It allows users to add text, video, images, custom lists, and
more to their WordPress sites.

To use the WordPress Text Widget:

Ÿ Go to Appearance > Customize in the WordPress Administration Screens and click the
Widget menu in the Theme Customizer. Or Go to Appearance > Widgets in the
WordPress Administration Screens.
Ÿ Open the sidebar to which you wish to add the Text Widget.
Ÿ Find the Text Widget in the list of Widgets.
Ÿ Click and drag the Widget to the spot you wish it to appear.

To open and edit the Text Widget:

Ÿ Click the down arrow to the right of the Text Widget title.
Ÿ Set the Text Widget Title (optional).
Ÿ Add the text or HTML code to the box or edit what is currently there.
Ÿ Choose the option to Automatically add paragraphs to wrap each block of text in an
HTML paragraph tag (recommended for text).
Ÿ Click Save to save the Text Widget.
Ÿ Click Close to close the Text Widget.
Ÿ Switch tabs in your browser and preview the results and make changes if necessary.
The Text Widget can hold a variety of HTML, XHTML, and multimedia links and players
such as video and object embed.

Styling the Text Widget

To specifically style the various default styles of the WordPress Text Widget, refer the
following example. Notice that Automatically add paragraphs option is enabled for Second
Text Widget.

<div id="widget-area" class="widget-area" role="complementary">

<aside id="text-1" class="widget widget_text"><h2 class="widget-title">Widget
Title for First Text Widget</h2>
<div class="textwidget">Text within the text widget area.</div>
</aside>
<aside id="text-2" class="widget widget_text"><h2 class="widget-title">Widget
Title for Second Text Widget</h2>
<div class="textwidget"><p>Text for second widget text area.</p></div>
</aside>
</div><!-- .widget-area -->

Adding Code to the Text Widget

Basic HTML, embeds, and JavaScript is added easily to the WordPress Text Widget. Most
embed codes from social sharing sites for multimedia will work in a WordPress Text
Widget. However, active code and programming languages such as PHP will not work as
the Widget will strip out the code it cannot display.

f. Website Backup Planning

How To Create a Website Backup Strategy

We’ve all heard it a million times before – backups are important. Still, the reality is that
even today, a website backup strategy remains one of the most overlooked and
underutilized precautions we can take to protect our vital data.

Why Are Backups So Important

Put simply, a good set of backups can save your website when absolutely everything else
has gone wrong. If a malicious attacker decides they want to wipe all your site files, or if
your web server has a catastrophic hard drive failure, all the damage can be easily undone
by restoring from your backups. The idea is simple. In order to make sure our data is safe,
you make a copy of it. If something happens to the original copy you can always use your
backup copy.

Simple right? Unfortunately, it isn’t that simple at all and there are a number of factors that
determine whether your backups will be useful, practical, and secure.

Worse than having no backup?

Working with client sites, I frequently see backups of their website being stored in the
public web directory (public_html, HTTP-docs). In my opinion, these backups are actually
worse than having no backups at all.
One of the things we stress here at Sucuri is the need to keep all the software on your
website up to date and fully patched (even if you are behind a website application firewall
with virtual patchings, like CloudProxy). Backups stored on the web server are a massive
potential security risk because they often contain old unpatched software with
vulnerabilities, and due to their publicly-accessible location, anyone can exploit them!

Smart Website Backups

If some backups are worse than having no backups at all, what is the correct backup
strategy? To be sure your backups have been made successfully and kept safe from
hackers or hardware failure, there are four key requirements:

1 – Location: Location, Location

Your backups should be stored offsite and not on the same server as your website. Storing
backups on the web server is a very bad idea because it is all too easy for the backup files
to be destroyed or infected with malware. If a malicious attacker has access to your web
space, they can easily infect or delete the backup copies as well as the live site. Not only
do off-site backups help protect your data from attackers but it also helps protect against
hardware failure. If your web server hard drive fails, you can easily lose all your data, live
site, and the backups.

When it comes to easy off-site backups there are a large number of options. Of course,
there is the Sucuri backup service which existing customers can take advantage of, but
there are also a plethora of WordPress and Joomla backup plugins that work in
conjunction with the big cloud providers such as Dropbox and Amazon.

2 – Automatic: For the People

Another very important feature of any backup system is that it should be completely
automated. If you can’t automate the backups then you can’t guarantee the backups will
get made. It’s all too easy for people to forget or get lazy when it comes to making backups,
especially when your site is fine and running well. If you must, make sure you schedule a
time to do it regularly.

Even so – you can’t guarantee that something will never go wrong, and while Sucuri
specializes in cleaning malware from website files and databases, sometimes malware
can be destructive, either writing over required custom files or just deleting them entirely.
In situations like this, it may not possible to restore the files unless an up-to-date backup is
available.

3 – Redundancy: Seeing Double

Schofield’s Second Law of Computing states that data doesn’t exist unless there are at
least two copies of it. This means that your backup strategy has to include redundancy, or
in other words, backups of your backups. I know that might sound like a hassle or over the
top but if you aren’t 100% sure the data will be there when you need it, what’s the point of
making backups in the first place?

Our customers can use the Sucuri website backup service, which is built with redundancy
in mind – using RAID 1 with backups duplicated in multiple locations.

4 – Testing: Is This Thing On?

The final task in establishing a secure and reliable backup process is to test to make sure
that the backup and restore actually works. Start with an empty web directory and then
make sure you can use those backups to get all your data back and the website back
online (with a test domain of course) using nothing but the files from the backup. You
would be surprised how many times people don’t test their backups… only to discover in a
time of need that their backups don’t actually work and are worthless.