Main menu

Branding

GavernWP makes accessible options allowing for theme’s branding. Branding options are divided into two groups:

  • theme’s branding
  • administration panel branding

Thanks to theme’s branding options, a user may specify:

  • specify page’s logo
  • specify theme’s footer content
  • decide about displaying a framework logo under page’s footer
  • specify page’s favicon

More information about branding options for a theme can be found in an entry devoted to a “Theme branding” tab in an administration panel.

Administration panel branding options allow to define:

  • a logo displayed next to a theme’s name in an administration panel sidebar
  • a logo visible over a log in form to an administration panel

More about branding options for an administration panel can be found in an entry devoted to “Back-end branding”  in an administration panel.

Widget rules

Widget rules is a mechanism which introduces a completely new way to manage widgets on a website. Thanks to it, it is possible to specify widget features such as:

  • displaying on subpages chosen,
  • displaying on devices chosen,
  • displaying for a group of users chosen,
  • displaying with a widget style use chosen.

After switching on widget rules in theme’s advanced settings, under each widget, the following options should be displayed:

widgets1

The most extensive options are those connected with a widget visibility on subpages chosen – after choosing an option to show a widget on pages chosen (or an option not showing a widget on pages chosen), such a panel will appear:

widgets2

Then, you have to choose a page’s type to add, e.g. Category, and then give category ID:

widgets3

After clicking “Add page” button, a page will appear on a list of pages chosen on which in our case a widget will be displayed:

widgets4

Of course, it is possible to add more pages:

widgets5

To make it clearer, , each page’s type is displayed with a different color. A page added can be removed by clicking a removing icon placed on the right side of each page.

In this way, you may set a widget so as to be shown on pages chosen or to be shown on all pages except the chosen ones.

Recent Updates bring new features. An option of displaying a widget on chosen pages has now twelve options:

  • Homepage
  • Page
  • Post
  • Category
  • Tag
  • Archive
  • Author
  • Page Template (Contact, Gallery, Login, Latest, Tagcloud etc.)
  • Taxonomy (to group things together)

    meetgavern_wp_widget_rules_new1

  • Post type (Other than default e.g. products from shop plugin)
  • Search page
  • 404 page

Generally, widgets are shown on all pages.

An option of displaying a widget on devices chosen has five options to choose:

  • All devices – a widget will be displayed everytwhere – on every device
  • Desktop – a widget will be displayed only when neither a tablet.css file nor a mobile.css is loaded
  • Tablets – a widget displays only when a tablet.css file will be loaded and, at the same time, a mobile.css file will not be loaded
  • Smartphones – a widget will be displayed only when a mobile.css file will be loaded
  • Tablets/Smartphones – a widget will be displayed when at least one file will be loaded: tablet.css or mobile.css.

Thanks to these settings, it is possible to limit significantly the amount of content displayed on devices with small screens.

An option of displaying widget for a chosen groups of users has four options to choose:

  • All users – a widget will be displayed to all users
  • Only guests – a widget will be displayed to not logged in users
  • Only registered users – a widget will be displayed to logged in users only
  • Only administrator – a widget will be displayed to administrators only

Thanks to this option, it is possible e.g. to display messages specified by using widgets for a group of users chosen.

The last optio from widget rules is an option for choosing a widget style – it causes appending to a widget main container an additional class giving styling specified by a user.

Widget styles are defined in widget.styles.json file and in CSS code – in this case in css/wp.extensions.css.

Custom Page Styles

GavernWP makes accessible a few own styles of subpages. Thanks to them, it is possible to use WordPress possiblitities better  and adjusting pages to themes chosen.

All additional subpages styles are placed in a main catalog in template.*.php files. GavernWP has the following subpages:

  • template.archive.php – an archive page, in includes a list of recent posts, categories and a list of links to monthly archives.
  • template.contact.php – a page with a contact form which allows to send an email to an email address specified in a WordPress configuration.
  • template.fullwidth.php – a page’s layout without a sidebar.
  • template.gallery.php – a page generating an animated gallery of images with a mechanism of attachments available in WordPress – it is enough to assign attachments to such a page that they will show as slides in a gallery. It is recommened to choose images with the same size.
  • template.latest.php - a page generating a list of recent posts (with full post content).
  • template.login.php – a page generating a login form for users – after logging in, it displays information about his/her username and a button to log out.
  • template.tagcloud.php – a page generating a tag cloud of our website.

Main CSS styles of subpages are in a css/stuff.css file. However, you have to remember that some more extensive files of subpages may additionally load CSS and JavaScript files from css/templates/ and js/templates/.

In order to load additional files in this way, it is enough to specify the second parameter of a gk_load function (see: code of requesting a gk_load function in a template.gallery.php file).

Comments Features

GavernWP has support for comments with a division into threads. Thanks to it, discussions made in comments under a post given are clearer.

All options connected with comments configuration can be set by using standard options in a WordPress administration panel (Settings > Discussion). Threads in comments are switched on thanks to “Enable threaded (nested) comments” and specifying maximal depth of nested comments in threads.

There are two files responsible for generating HTML code of comments, namely:

  • comments.php – it includes a code which generates a comments list and a form of adding comments.
  • gavern/helpers/helper.layout.fragments.php – in gavern_comment_template function, there is a code responsible for generating a code of a comment given.

CSS code responsible for a style of comments and a form of adding comments is in css/wp.css file.

 

Meet Gavern has also two new options connected with comments, available in Advanced theme settings:

  • Add target blank to comments links – if this option is enabled, then every link in the comments text will open in new browser tab.
  • Autolinking in comments – if this option is enabled, then every link in the comments text will be automatically changed into hyperlink

Theme CSS

Theme’s CSS code is divided into a few files, loaded in order specified. All these files are in css catalog. You have to remember that order of these files is very important and its change may cause unpredictable changes of theme’s look because of using moving from general styling to detailed styling in CSS code.

The list of CSS files used in a theme is presented below (order according to recommended order of loading these files):

  1. normalize.css – CSS code unifying page’s elements styling in all browsers
  2. template.css – the most important CSS file responsible for page’s layout styling , basic typography, widget styling, etc.
  3. wp.css – CSS rules which are responsible for WordPress elements styling, e.g. a comments form , comments themselves or posts elements.
  4. shortcodes.*.css (optional) – a group of CSS files responsible for typography elements styling inserting to posts with Shortcodes.
  5. stuff.css – it includes styling of additional theme’s elements sucha s breadcrumbs or font-size switcher.
  6. wp.extensions.css – CSS rules connected with styling of standard widgets available with WordPress.
  7. extensions.css (optional) – a CSS file which you have to add yourself in the case when you want to style additional widgets. In the case of small changes in widget styling, we recommend to use override.css file instead of this file.
  8. tablet.css – CSS rules used while displaying a page on tablet devices.
  9. mobile.css – CSS rules used while displaying  a page on smartfon devices.
  10. ie*.css – a file or a group of CSS files used for correcting page’s look in an Internet Explorer browser.
  11. style*.css – a file or a group of CSS files used for changing coloring or general style of a theme – they are loaded automatically by a mechanism responsible for theme’s coloring.
  12. error.css - CSS rules used while displaying a error page.
  13. rtl.css -  CSS rules for language written in a Right-To-Left (RTL) direction.
  14. font-awesome.css - The full suite of Retina ready pictographic icons, e.g. for widget titles.
  15. override.css (optional) – you may add your own rules in this file which will overwrite existing rules in previous files – a perfect solution for theme modification without modifying the remaining CSS files.

Additionally, CSS code used in a theme itself, you will also find in a templates catalog where there are CSS files loaded on chosen styles of subpages, e.g. needed for correct work of a gallery.

Theme structure

Each theme’s subpage in GavernWP is created and based on one file from theme’s main catalog, e.g. single.php and at least four additional files from layouts catalog:

  • header.php – this file includes starting page’s structure i.e. a head section and the whole headline with elements such as: logo, main menu, etc.
  • before.php – there are all widget positions included in this file which are before page’s main content.
  • after.php – this file is an equivalent of before.php file but with one difference – it includes widget positions which are after page’s main content.
  • footer.php – similarly to header.php file, it includes a starting page’s structure as footer.php includes the ending page’s structure, i.e. a footer and and elements below.

The above files with a file given from a main catalog, create a basic structure of each page. The remaining elements are generated by additional files or functions. The majority of of such files can be found in layouts catalog; e.g. files with names content.post.*.php, include constituents of each post. . Using these files allowed to restrict the amount of code in theme’s main files and simplify its modification as change e.g. an entry footer requires modification of one or two files only.

Functions used for generating additional information displayed in posts are in gavern/helpers/helpers.layout.fragments.php file.

Social API

Thanks to Social API, adding buttons to an entry for sharing posts in the most popular social network services is very easy.

At the moment, Social API supports four services:

  • Facebook
  • Google+
  • Twitter
  • Pinterest

Buttons for sharing are generally added under an entry. All contact data needed for sharing are loaded from entry content or from OpenGraph metatags.

Thanks to extensive configuration options, it is possible to adjust buttons look in accordance with available configuration parameters.

The most important thing is that the work of Social API can be limited to specific posts or switch off some posts from its work.

Open Search support

Open Search is a technology which allows to create your own browsing engine used by a browser. Thanks to it, e.g. in a Firefox browser, a user may define a new browser after entering our website based on GavernWP framework. Because of it, in the case of more extensive websites, e.g. data catalogs, searching is much easier.

Switching on support for Open Search requires switching on one option in an administration panel in a tab of advanced settings. All other operations are made with GavernWP.

Responsive Layout

GavernWP makes possible to create themes based on Responsive Web Design. That’s why, it has two additional CSS styles:

  • tablet.css
  • mobile.css

Thanks to options available in an administration panel, it is possible to specify when these styles will be loaded.

Two column layout (if a column is switched on) is loaded when tablet.css file is not loaded.

At the moment of reaching maximum width for tablet.css file, page’s layout is changed into one column and the column itself is placed before or after page’s main content.

Additionally, in widget positions like top or bottom1/2/3, modules from three column layout are changed into one column  layout.

After loading mobile.css file there is one column layout used everywhere.

A very important improvement is a possibility of specifying whether a module will be loaded in tablet or mobile mode. More information can be found in Widget Rules entry.

Color Styles

GavernWP has an extensive mechanism allowing to create additional theme styles. We may distinguish two main groups of styles in this mechanism:

  • style family
  • styles included in style family given

The whole configuration is included in styles.json file:

[{
"family": "color",
"family_desc": "Theme color",
"family_tooltip": "You can select one of the theme colors",
"styles": [
{
"name": "Color I",
"value": "color1",
"file": "style1.css"
},
{
"name": "Color II",
"value": "color2",
"file": "style2.css"
}
]
}]

As you can see, it includes color style family which has two styles, namely: Color I and Color II.

In order to create new style family or a style for style family given, it is enough to create a next object in styles.json file and then create CSS files connected with a family given – in the case of color family, these are style1.css and style2.css files.

GavernWP will load CSS files of a style given in a head section – chosen in an administration panel or, if there is a tool for choosing user’s styles switched on, they will be loaded based on a Cookie file storing data about a style used by a user.

You have to remember that for each style family there is at least one CSS file loaded. Therefore, creating coexisting style families like:

  • dark styles and light styles
  • blue styles and green styles

is incorrect because at least one CSS style from each family will be loaded immediately. So the correct one is creating style families responsible for some elements of website styling, e.g. a separate family responsible for website coloring (colors) and a separate one for website background (patterns).

Generally, you have to care about particular style families in order not to overwrite one another.

Weblinks

Links Úteis

Share

Facebook