WP Disable Comments

Advertisements

Support: Minamaze theme “more” font color

I needed to change the font color of the red text in the red “read more” box on my static blog page.   The theme has links unmarked, not clearly marked, so I had changed links to red.  Therefore, the text in the  “read more” boxes was red, on a red background.

I had great luck and received a successful solution quickly in the Minamaze Theme support forum.

Minamaze
[resolved] Next to change font color in Read More boxes (3 posts)

Toni
Member
Posted 3 hours ago #

I had fixed this in other areas, but now I’m using a static blog page:

I need the Read More font to be white or not red, on the static blog page. (I had to make the links visible site wide, so they are all red.)

http://toni-esl.com/blog/

Thank you

CrouchingBruin
Member
Posted 2 hours ago #

Add this to the end of your child theme’s style.css file:
.blog #content .more-link {
color: white;
}

Toni
Member
Posted 11 seconds ago #
Edit

Fantastic!!
Works perfectly. Thank you so very much for your help and for responding so quickly.

Cheers!

Support: Minamaze theme “more” font color was originally published on WP.org Struggles – The Site

W3C QA – Quality Tips for Webmasters

About these Tips

Short, simple bits of knowledge for better Web design, authoring, and use, on quality issues related to W3C technologies such as HTML, CSS, HTTP.

List of Quality Tips

Source: W3C QA – Quality Tips for Webmasters

Add Masonry, Grid Layouts To Your WordPress Site With Just CSS – WPMU DEV

Add Masonry, Grid Layouts To Your WordPress Site With Just CSS – WPMU DEV.

Ever wanted to jazz up how your posts are displayed on your WordPress home page and archives?

What if you could display your posts using the masonry (Pinterest) approach or maybe a grid layout, all just by adding a snippet of CSS?

No plugins, shortcodes, template changes, assigning pages as the home page. Just pure CSS.

Masonry image next to CSS for column-counts
Masonry and grid layouts are all possible with pure CSS, no markup changes

Before We Start…

These solutions are based purely on CSS and so, not surprisingly, they rely heavily on the HTML mark-up on your site to work without modification.

The CSS used has been designed (and tested) with the default themes. This means that the CSS has a couple of expectations:

  1. Classes exist on the body element that describe the type of page (e.g. home, blog, archive, search)
  2. Post lists are collections of article elements, complete with header wrapped in a div with the id of content

If you use a default theme then you will be able to use the CSS without modification. Even if you don’t, you might find that your theme uses similar enough markup that you can still use the CSS as is. For example, the Eighties theme uses virtually the same markup as the default themes.

If your theme doesn’t use the same markup – the easiest way to tell is to check the page source for the classes and ids referenced in the CSS – then you can still use the CSS, you’ll just have to change the classes and the ids to match your markup.

Choosing Where To Apply The Styling

You may decide that you only want to apply your chosen styling to certain pages.

WordPress makes this really easy as it applies page-specific classes to the body element such as blog, home, archive and search, so you simply need to code your CSS for each of the relevant classes.

For example, if you want to apply the styling to just the home page then your CSS will look something like:

1
body.blog article { styles go here... }

To apply the styling to the home page and the archive (category) pages:

1
body.blog article, body.archive article { styles go here... }

To apply the styling to just the search results:

1
body.blog search { styles go here... }

Again, this does depend on your theme following WordPress’ theming recommendations.

Browser Compatibility

Being CSS3, these techniques are not going to work across all platforms and browsers.

I have tested and confirm that they work on the latest versions of Chrome and Safari (both on OS X) and on iOS (5+). The various CSS websites also suggest that IE10 will also have no problems.

Outside of these browsers (including IE9), your mileage will vary but it’s worth remembering that the fallback is your current styling, so visitors using older browsers will simply not notice any difference.

If you find the styles work successfully on a platform not mentioned (particularly Windows), then let us know in the comments.

Enough of the disclaimers, then, let’s look at how to spruce up your post listings.

Giving Your Posts The Pinterest Masonry Look

Screenshot of post listing with masonry CSS applied
Popularized by Pinterest, masonry works great with posts of differing heights

There are plenty of WordPress themes and a handful of plugins that display posts in a Pinterest-style masonry format. But with CSS3, you can simply add some additional styles to your WordPress site and get the same effect.

This solution, inspired by Rahul Arora’s post on W3Bits, is based on CSS3’s support for the column property. This property will split content across the defined number of columns and whilst its creation was likely inspired more by the idea of flowing text across columns newspaper-style, it’s just as useful for a masonry layout.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
/* Masonry Custom CSS  */

/* Masonry container */
body.blog div#content, body.archive div#content {
-moz-column-count: 4;
-webkit-column-count: 4;
column-count: 4;
-moz-column-gap: 1em;
-webkit-column-gap: 1em;
column-gap: 1em;
}

/* Masonry bricks or child elements */

body.blog article, body.archive article {
background-color: #eee;
display: inline-block;
margin: 0 0 1em;
padding: 1em;
width: 100%;
}

body.archive .archive-header, body.blog .paging-navigation, body.archive .paging-navigation {
background-color: #ffffff;
-webkit-column-span: all;
column-span: all;
}

In the default layouts, posts are output as article elements wrapped in a div with a id of content.

The CSS:

1. Sets the number of columns on the #content wrapper using the column-countproperty – in this case 4. It also sets the column-gap. You’ll notice the use of -moz-and -webkit- for Firefox and Safari.

2. Turns the article elements into the bricks, using inline-block and setting a width to 100%.

3. Ensures that the page header and the navigation sits in its own “row” by specifying that these elements span all columns

Just to keep things tidy you might also consider adding the following:

1
2
3
4
5
6
7
8
9
10
/* Some ad hoc CSS useful for many themes */
body.archive .site-content,
body.blog .site-content {
margin: 1em;
}

h1, h2, h3, h4, h5, h6, a {
-ms-word-wrap: break-word;
word-wrap: break-word;
}

This just puts a margin around the content and ensures that long words in titles don’t throw out the formatting (useful for any theme, not just here).

Making It Responsive

One disadvantage with a column approach is that it quickly degrades as the screen size gets smaller.

What we want to do is to manipulate the number of columns so that the article elements get a sensible amount of screen real estate to maintain the bricks’ integrity and visual appeal. So, let’s add some media queries to change the number of columns based on the screen size:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
@media only screen and (max-width : 1024px) {

body.blog div#content, body.archive div#content { /* Masonry container */
-moz-column-count: 3;
-webkit-column-count: 3;
column-count: 3;
}
}

@media only screen and (max-device-width : 1024px) and (orientation : portrait) {

body.blog div#content, body.archive div#content { /* Masonry container */
-moz-column-count: 2;
-webkit-column-count: 2;
column-count: 2;
}
}

@media only screen and (max-width : 768px) {

body.blog div#content, body.archive div#content { /* Masonry container */
-moz-column-count: 2;
-webkit-column-count: 2;
column-count: 2;
}
}

@media only screen and (max-width : 480px) {

body.blog div#content, body.archive div#content { /* Masonry container */
-moz-column-count: 1;
-webkit-column-count: 1;
column-count: 1;
}
}

As you can see, we only need to change the column-count property (and its derivatives) for each query.

These 4 breakpoints, 3 of which will work across all platforms (simply resize your browser window to see them take affect) and 1 which is specifically for a tablet in portrait mode.

Here’s the masonry styling on an iPad and iPhone:

Screen shots of masonry layout on an iPhone (1 column) and iPad in portrait mode (2 columns)
Making the number of columns respond to screen size is easy

You can (and should), of course, go further and add more style to the bricks to improve the visual appeal but just 3 CSS statements to turn your post listings into a masonry wall is pretty impressive!

Laying Out Posts In A Grid

Screenshot of post listings using grid styling
Grids bring order and uniformity to your post lists

If you like more uniformity and order than masonry provides, then you might be interested in laying out your posts in a grid.

Grids are very, very easy to implement but definitely work best when the featured images are all the same size, otherwise you can end up with plenty of whitespace padding out the shorter “cells”.

This time the CSS is even shorter, simply relying on styling the article elements:

1
2
3
4
5
6
7
8
9
/* Grid Layout Custom CSS */
body.blog article, body.archive article {
width: 32.5%;
display: inline-block;
vertical-align: top;
text-align: left;
margin-bottom: 10px;
position: relative;
}

That’s all that’s absolutely necessary. Again, we are making use of inline-block and ensuring that the article content (title, featured image, excerpt) are vertically aligned.

The important property is the width as this determines the number of “columns”. I’ve used 32.5% as the initial value (using 33% can lead to premature wrapping) which will provide for 3 columns. Obviously, if you wanted 4 columns then you’d use 24.5%, 5 columns 19.5%, etc.

Adding Responsive-ness

Just like our masonry styling, grids are going to need to be responsive if they are to maintain their effectiveness.

As it is the width property that determines the number of columns then that’s the property that will be changed in the various media queries.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
@media only screen and (max-device-width : 1024px) and (orientation : portrait) {

body.blog article, body.archive article {
width: 49%;
}
}

@media only screen and (max-width : 768px) {

body.blog article, body.archive article {
width: 49%;
}
}

@media only screen and (max-width : 480px) {

body.blog article, body.archive article {
width: 100%;
}
}

Just 3 queries this time as I only started with 3 columns. If you decide to start with more columns then you may well want to add a breakpoint of max-width: 1024px to set the width to 32.5% (3 columns).

This will result in:

  1. 2 columns on a tablet in portrait mode
  2. 2 columns when the screen size is a maximum width of 768px
  3. 1 column when the screen size is a maximum width of 480px

These breakpoints will cover both tablets and smartphones and resizing of the browser window.

Here’s the grid layout on an iPad and iPhone:

Grid layout on an iPad in both portrait and landscape
Just a couple of media queries ensures that the grid responds to changing screen size

Grids, a bit more orderly than masonry but really do require consistency and rigour when it comes to featured image size to be at their most effective.

How To Get The Custom CSS Into Your Site

There are a number of options when it comes to injecting your chosen custom CSS into your WordPress site. If your theme doesn’t include the ability to add custom CSS, then your choices are:

  • Child Theme – create a child theme and add the CSS to the stylesheet
  • Plugin – add your chosen styling to a new CSS file and create a plugin that uses thewp-enqueue-style function, perhaps conditionally based on the page being generated, to enqueue the new file
  • Edit the current theme’s stylesheet – don’t, really, just don’t
  • Use a custom CSS plugin – there are a number of plugins that will allow you to add custom CSS to your site via the WordPress admin interface (the aptly named Simple Custom CSS plugin is one such plugin)

I like using the Custom CSS plugin. It’s quick and easy to set up, makes testing a breeze and is equally quick and easy to remove the CSS from your WordPress site (clear the editor or uninstall the plugin).

CSS, The Pathway To WordPress Zen

The wonderful CSS Zen Garden has been proving for many years that the look and feel of a site can be substantially altered without a single change to the markup but by changing the CSS.

Whilst not anywhere near the same level, these two techniques prove that changing the look and feel of your WordPress site is also entirely possible without needing to alter templates, using shortcodes or developing child themes.

Just a little bit of CSS.

Do you have a favorite CSS snippet that you’ve used on your WordPress site? Share it in the comments below.

via Add Masonry, Grid Layouts To Your WordPress Site With Just CSS – WPMU DEV.

The Complete Guide To Custom Post Types

The Complete Guide To Custom Post Types.

WORDPRESSThe Complete Guide To Custom Post Types

WordPress has been gaining a foothold in the general content management system (CMS) game for a few years now, but the real breakthrough was the custom post type mechanism which allows for the creation of a wide variety of content. Let’s take a look at how this came to be and all the options that this great functionality offers.

Some of the custom post types you can create in WordPress.
Some of the custom post types you can create in WordPress.

What It Used To Be Like

In practice, custom post types have been around for a long time, more specifically since February 17, 2005, when WordPress 1.5 added support for static pages, creating the post_type database field.

The wp_insert_post() function has been around since WordPress 1.0, so when the post_type field was implemented in 1.5, you could simply set the post_type value when inserting a post. Of course, creating and managing custom post types required much more than that, but the amount of coding needed became less and less as WordPress functions became more and more flexible.

By version 2.8, the register_post_type() function and some other helpful things were added to the nightly builds, and when 2.9 came out, the functions became available to everyone. At this point, extensive coding and hacks were not needed to make WordPress a full blown CMS; you could use plenty of great built-in functions to make WordPress do your bidding.

What WordPress Can Do For You Now

A custom post type is nothing more than a regular post with a differentpost_type value in the database. The post type of regular posts is post, pages use page, attachments use attachment and so on. You can now create your own to indicate the type of content created. You could create custom post types for books, movies, reviews, products and so on.

If created correctly, you can achieve the following with a few lines of code:

  • The custom post type will show up in the back end as a separate menu item with its own post list and “add new” page
  • Navigating to http://mysite.com/customposttype/ will take you to the archive page for the post type. This is akin to visiting the front page for latest posts from the “post” post type.
  • Categories and tags can be made available to the custom post type, or you can create custom taxonomies.

Apart from these, you can modify countless options, such as where the custom post type should be placed in the menu, should it be searchable, which user level can access it, should it be hierarchical, custom rewrite rules, etc.

Different types of content have different data requirements. For regular posts, you’ll want to specify the author, category, date and so on. For a “book” custom post type, ideally you’d like to have the option to specify the book’s author, the page count, genre, publisher and other book-specific data. Using custom meta boxes, this is easily achieved and managed as well.

Custom meta boxes enable you to add additional boxes to the edit screen of a post. They usually use custom fields, so you could just use custom fields as well, but by separating out some custom fields as meta boxes, you can create a much smoother and usable admin.

Working With Custom Post Types

To effectively create and use custom post types, you’ll need to be familiar with the following:

  • Creating custom post types,
  • Creating custom taxonomies,
  • Creating custom meta boxes.

Creating Custom Post Types

First on our agenda is creating the post type itself. Ideally you should create a plugin when working with custom post types, but if you don’t know how, or just need a quick test, you can use the functions.php file in your theme.

function my_custom_post_product() {
  $args = array();
  register_post_type( 'product', $args ); 
}
add_action( 'init', 'my_custom_post_product' );

In its simplest form, it will create a post type which has almost no customization. It won’t be public, it won’t show up in the admin, interaction messages will be the same as posts (“post saved,” “post updated,” etc.) and so on. To tailor our new post type to our needs, I’ll go through some of the more frequently-used options and add them to the previously empty $args array.

function my_custom_post_product() {
  $labels = array(
    'name'               => _x( 'Products', 'post type general name' ),
    'singular_name'      => _x( 'Product', 'post type singular name' ),
    'add_new'            => _x( 'Add New', 'book' ),
    'add_new_item'       => __( 'Add New Product' ),
    'edit_item'          => __( 'Edit Product' ),
    'new_item'           => __( 'New Product' ),
    'all_items'          => __( 'All Products' ),
    'view_item'          => __( 'View Product' ),
    'search_items'       => __( 'Search Products' ),
    'not_found'          => __( 'No products found' ),
    'not_found_in_trash' => __( 'No products found in the Trash' ), 
    'parent_item_colon'  => '',
    'menu_name'          => 'Products'
  );
  $args = array(
    'labels'        => $labels,
    'description'   => 'Holds our products and product specific data',
    'public'        => true,
    'menu_position' => 5,
    'supports'      => array( 'title', 'editor', 'thumbnail', 'excerpt', 'comments' ),
    'has_archive'   => true,
  );
  register_post_type( 'product', $args ); 
}
add_action( 'init', 'my_custom_post_product' );
  • labels
    The labels option should be an array defining the different labels that a custom post type can have. I have separated this out above just to make the arguments for registering a post type clearer.
  • description
    A short explanation of our custom post type; what it does and why we’re using it.
  • public
    This option controls a bunch of things in one go. Setting this to true will set a bunch of other options (all to do with visibility) to true. For example, it is possible to have the custom post type visible but not queryable. More on this later.
  • menu_position
    Defines the position of the custom post type menu in the back end. Setting it to “5” places it below the “posts” menu; the higher you set it, the lower the menu will be placed.
  • supports
    This option sets up the default WordPress controls that are available in the edit screen for the custom post type. By default, only the title field and editor are shown. If you want to add support for comments, revisions, post formats and such you will need to specify them here. For a full list take a look at the arguments section in the Codex.
  • has_archive
    If set to true, rewrite rules will be created for you, enabling a post type archive at http://mysite.com/posttype/ (by default)

A custom post type in the menu.
A custom post type in the menu.

After setting this up, you should see the menu entry for the custom post type. You should be able to add posts, view the post list in the admin and also visit the published posts on the website.

As I mentioned there are a lot of things you can modify when creating a post type. I suggest looking at the arguments list in the Codex for a full description of each option and the possible values.

CUSTOM INTERACTION MESSAGES

WordPress generates a number of messages triggered by user actions. Updating, publishing, searching, etc., in the back end all lead to messages which — by default — are tailored to regular posts. You can change the text of these messages easily by using thepost_updated_messages hook.

function my_updated_messages( $messages ) {
  global $post, $post_ID;
  $messages['product'] = array(
    0 => '', 
    1 => sprintf( __('Product updated. <a href="%s">View product</a>'), esc_url( get_permalink($post_ID) ) ),
    2 => __('Custom field updated.'),
    3 => __('Custom field deleted.'),
    4 => __('Product updated.'),
    5 => isset($_GET['revision']) ? sprintf( __('Product restored to revision from %s'), wp_post_revision_title( (int) $_GET['revision'], false ) ) : false,
    6 => sprintf( __('Product published. <a href="%s">View product</a>'), esc_url( get_permalink($post_ID) ) ),
    7 => __('Product saved.'),
    8 => sprintf( __('Product submitted. <a target="_blank" href="%s">Preview product</a>'), esc_url( add_query_arg( 'preview', 'true', get_permalink($post_ID) ) ) ),
    9 => sprintf( __('Product scheduled for: <strong>%1$s</strong>. <a target="_blank" href="%2$s">Preview product</a>'), date_i18n( __( 'M j, Y @ G:i' ), strtotime( $post->post_date ) ), esc_url( get_permalink($post_ID) ) ),
    10 => sprintf( __('Product draft updated. <a target="_blank" href="%s">Preview product</a>'), esc_url( add_query_arg( 'preview', 'true', get_permalink($post_ID) ) ) ),
  );
  return $messages;
}
add_filter( 'post_updated_messages', 'my_updated_messages' );

A custom message after saving a product.
A custom message after saving a product.

As you can see, this is not the most user-friendly method of managing messages. An associative array would be far better; we could see what each message is for without having to read the actual message.

Notice that you can change the messages for all custom post types using this single function. The $messages array holds the messages for all post types, so you can modify them all here. I personally create a function for each post type just so I can group the post type creation and the custom messages together easily.

CONTEXTUAL HELP

A feature I rarely see implemented is the customized contextual help. As a user, I’ve never actually used this feature myself, but I’m sure that many people do; in any case, it’s nice to provide some hand-holding for less experienced users.

The contextual help feature is a descending tab which can be seen in the top right of pages where available. Let’s take a look at how the contents can be changed.

function my_contextual_help( $contextual_help, $screen_id, $screen ) { 
  if ( 'product' == $screen->id ) {

    $contextual_help = '<h2>Products</h2>
    <p>Products show the details of the items that we sell on the website. You can see a list of them on this page in reverse chronological order - the latest one we added is first.</p> 
    <p>You can view/edit the details of each product by clicking on its name, or you can perform bulk actions using the dropdown menu and selecting multiple items.</p>';

  } elseif ( 'edit-product' == $screen->id ) {

    $contextual_help = '<h2>Editing products</h2>
    <p>This page allows you to view/modify product details. Please make sure to fill out the available boxes with the appropriate details (product image, price, brand) and <strong>not</strong> add these details to the product description.</p>';

  }
  return $contextual_help;
}
add_action( 'contextual_help', 'my_contextual_help', 10, 3 );

This is also a bit difficult because you have to know the ID of the screen you are on. If you print out the contents of the $screen variable, you should be able to determine the ID easily. This is also a function you can use to modify the contextual help of all custom post types at once, but I personally recommend grouping this together with the previous two blocks and only using it for one custom post type at a time.

OVERVIEW

To quickly recap, we used three functions to create a “complete” custom post type. We used register_post_type() to create the post type itself and two hooks — contextual_help and post_updated_messages — to create helpful guidance and relevant messages respectively.

Custom Taxonomies

Your regular blog posts use categories and tags to create an organization structure. However, the same organization doesn’t necessarily make sense for custom post types. Your blog posts could be about your “Life,” your “Thoughts” or your “Dreams.” These are obviously not appropriate for products.

This is the problem that drove developers to create custom taxonomies. You can create a separate taxonomy named “Product Categories” to house categories you only use for products. Kevin Leary wrote a great article about custom taxonomies in WordPress which I highly recommend, so I will only go into minor detail here.

function my_taxonomies_product() {
  $args = array();
  register_taxonomy( 'product_category', 'product' $args );
}

add_action( 'init', 'my_taxonomies_product', 0 );

Similarly to custom post types, you can create a taxonomy very easily, but you need to work at it a bit to tailor it to your needs. Custom taxonomies behave a bit better out of the box as they are public by default, so the above is actually enough to tie this taxonomy to the product posts. Let’s look at a customized example.

function my_taxonomies_product() {
  $labels = array(
    'name'              => _x( 'Product Categories', 'taxonomy general name' ),
    'singular_name'     => _x( 'Product Category', 'taxonomy singular name' ),
    'search_items'      => __( 'Search Product Categories' ),
    'all_items'         => __( 'All Product Categories' ),
    'parent_item'       => __( 'Parent Product Category' ),
    'parent_item_colon' => __( 'Parent Product Category:' ),
    'edit_item'         => __( 'Edit Product Category' ), 
    'update_item'       => __( 'Update Product Category' ),
    'add_new_item'      => __( 'Add New Product Category' ),
    'new_item_name'     => __( 'New Product Category' ),
    'menu_name'         => __( 'Product Categories' ),
  );
  $args = array(
    'labels' => $labels,
    'hierarchical' => true,
  );
  register_taxonomy( 'product_category', 'product', $args );
}
add_action( 'init', 'my_taxonomies_product', 0 );

As you can see, not much has changed. We added some labels and set the hierarchical option to true. This enables “category style” taxonomies. When set to false (this is the default), your taxonomy will be like the default tags.

There are a few other power options available which you can read about in Leary’s article, or you can go to the Codex entry onregister_taxonomy().

The Product Categories custom taxonomy.
The Product Categories custom taxonomy.

Post Meta Boxes

Meta boxes are the draggable boxes you see in the WordPress edit screen for a post. There are numerous built-in meta boxes like the publishing controls, the taxonomies, the author box, etc., but you can create some for yourself.

Meta boxes tend to be used to manage custom field data in a much more user-friendly way than the built-in custom fields box does. Since you put the controls in place, you can add client-side error checking and many other fancy things.

Justin Tadlock wrote the all-encompassing custom meta box article here on Smashing Magazine, which is a great in-depth article on the subject. I recommend reading it for the full picture, but I’ll get you started here.

Creating a meta box requires three steps:

  • Define the box itself,
  • Define the content of the meta box,
  • Define how the data from the box is handled.

DEFINING THE META BOX

add_action( 'add_meta_boxes', 'product_price_box' );
function product_price_box() {
    add_meta_box( 
        'product_price_box',
        __( 'Product Price', 'myplugin_textdomain' ),
        'product_price_box_content',
        'product',
        'side',
        'high'
    );
}

The code above creates the meta box with the following parameters (in the order given):

  • The unique identifier for the meta box (it does not have to match the function name),
  • The title of the meta box (visible to users),
  • The function which will display the contents of the box,
  • The post type the meta box belongs to,
  • The placement of the meta box,
  • The priority of the meta box (determines “how high” it is placed).

DEFINING THE CONTENT OF THE META BOX

function product_price_box_content( $post ) {
  wp_nonce_field( plugin_basename( __FILE__ ), 'product_price_box_content_nonce' );
  echo '<label for="product_price"></label>';
  echo '<input type="text" id="product_price" name="product_price" placeholder="enter a price" />';
}

This is a simple box which only contains the price, so we have created a label and an input to manage it. A nonce field is also present, which adds security to the data submission.

HANDLING SUBMITTED DATA

In most cases, you will want to save the data as a custom field, but you are by no means restricted to this method. You could use the input to make a third party API call, to generate an XML file or whatever you like. The most common use is saving custom post data, so let’s take a look at how that is done.

add_action( 'save_post', 'product_price_box_save' );
function product_price_box_save( $post_id ) {

  if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) 
  return;

  if ( !wp_verify_nonce( $_POST['product_price_box_content_nonce'], plugin_basename( __FILE__ ) ) )
  return;

  if ( 'page' == $_POST['post_type'] ) {
    if ( !current_user_can( 'edit_page', $post_id ) )
    return;
  } else {
    if ( !current_user_can( 'edit_post', $post_id ) )
    return;
  }
  $product_price = $_POST['product_price'];
  update_post_meta( $post_id, 'product_price', $product_price );
}

The biggest part of this function is all about safety. First of all, if an autosave is being performed, nothing happens because the user hasn’t actually submitted the form. Then the nonce is checked, followed by permission checking. If these are all passed, we take our data and add it to the post using the update_post_meta() function.

An example of a meta box for an apartment post type.
An example of a meta box for an apartment post type.

Displaying Your Content

While there a plenty of nuances to all of the above, you should be familiar with the basics. All that is left is to actually use the data we now have and show things to the user. This involves showing posts — perhaps from various custom post types and taxonomies — and using our post metadata.

DISPLAYING POSTS

If you’ve created a post type with the has_archive parameter set to “true,” WordPress will list your posts on the post type’s archive page. If your post type is called “books,” you can simply go tohttp://mysite.com/books/ and you’ll see your post list.

This page uses archive-[post_type].php for the display if it exists (archive-books.php in our case). If it doesn’t exist, it will use archive.phpand if that doesn’t exist it will use index.php.

Another way to display custom post type content is to use a custom query with the WP_Query class. To display posts from a certain post type and custom taxonomy, you could do something like this:

<?php
    $args = array(
      'post_type' => 'product',
      'tax_query' => array(
        array(
          'taxonomy' => 'product_category',
          'field' => 'slug',
          'terms' => 'boardgames'
        )
      )
    );
    $products = new WP_Query( $args );
    if( $products->have_posts() ) {
      while( $products->have_posts() ) {
        $products->the_post();
        ?>
          <h1><?php the_title() ?></h1>
          <div class='content'>
            <?php the_content() ?>
          </div>
        <?php
      }
    }
    else {
      echo 'Oh ohm no products!';
    }
  ?>

DISPLAYING METADATA

Metadata can be retrieved easily using the get_post_meta() function. In our example above, we saved a post meta field named product_price. We can retrieve the value of this field for a given post using the following code:

<?php
  // If we are in a loop we can get the post ID easily
  $price = get_post_meta( get_the_ID(), 'product_price', true );

  // To get the price of a random product we will need to know the ID
  $price = get_post_meta( $product_id, 'product_price', true );
?>

Final Words

As you can see, creating a CMS is pretty easy due to the modular nature of WordPress controls and functions. The methods outlined here can be used extremely well to create customized admins for nearly anything you can think of.

Since defining the content of meta boxes is completely up to you, you have the power to create additional features for your controls, making you or your clients very happy.

You can take this one step further with custom admin pages and completely custom content, but that’s a story for another day.

Image source of picture on front page.

(cp)

Hallo, my name is Daniel 🙂 I build plugins, themes and apps – then proceed to write or talk about them. I’m the editor for the WordPress section here on Smashing Magazine and I contribute to various other online sites. When not coding or writing you’ll find me playing board games or running with my dog. Drop me a line on Twitter or visit my personal website.

via The Complete Guide To Custom Post Types.

How to Find the Location of Your php.ini File

From https://www.ostraining.com/blog/coding/phpini-file/

A critical file you often need to manage is the php.ini file. It controls many import aspects of what you can and can not do with your site, including the size of files that you can upload.

Different hosts use different schemes for storing and accessing files and so you’ll need to research where your php.ini file.

This tutorial will show you how to find the location of the file on any server.

Step 1. Create a script to display your php information

You’ll need to create a very simple php script and place it in your home directory. Using a script editor or a plain text editor (not a word processor) create file called phpinfo.php with this code:

<?php phpinfo(); ?>

That’s all you need. Just one single line. Save the file and call it phpinfo.php.

Upload this file to the public_html directory or whatever your main HTML directory is called.

In your browser address bar, access the file by typing in: http://yourdomain.com/phpinfo.php

You’ll get a complete list of all your php settings. In the phpinfo.php page you can see:

  • the PHP version at the top of the file.
  • the location of your php.ini file

If you scroll down the page, and you can find the current version of MySQL. and php settings like safe_mode and register_globals and much much more.

This will work on your local computer using XAMPP or WAMP as well. This is what my XAMPP installation looks like.

GoDaddy Servers Are a Special Case

go to the original post for Go Daddy, link below:

via How to Find the Location of Your php.ini File.

Jan Mulder Word Game Scripts

My Scripts

The scripts below work with the most basic browsers. Special attention has been paid to cross browser/platform compatability. These scripts have been tested in Internet Explorer 4.x-6, Opera 5.x-6, Netscape 4.x – 7 and Mozilla.

– go to the links below to download each:

  My Scripts

via Jan Mulder.

via Jan Mulder.