This is the documentation for concrete5 version 5.6 and earlier. View Current Documentation

One of the most common mistakes in "tweeking" your new concrete5 site, is to incorrectly modify a package or block css.

concrete5 has made a super easy way to handle this out of the box.

Before we dive into styling a block, we need to cover two topics that are related to what we are doing. The concrete5 directory structure and the block file structure.

The concrete5 File Structure

One of the first questions concrete5 noobs ask when installing it is "why are the exact same folders in the concrete folder, and then also in the root folder?".

The concrete5 file structure is designed to offer total flexibility on how you style and expand your site, and still maintain easy updatability without overwriting all your hard work.

A single page would be a great example. You can actually just create a new "login.php" file and drop that into your root "single_pages" folder, and bam...your new page is enacted on the site, and you are in no danger of overwriting it when you update.

The concrete5 Block Structure

There is a lot that can go on in a block file structure. But lets just cover the basics.

The bare-min required files are as such: db.xml (for versioning), view.php, add.php, edit.php , and controller.php.

Various developers may include all kinds of other file types, folders, templates...ect. But what you want to hone in on when wanting to make some aesthetic changes to a given block, is any file with the prefix "view". That, in most cases, will be view.php and view.css. You may also see a view.js.

Adding Page Owner Information

Lets do a quick example of how to create a custom content block template, and add some page owner information to be shown along with that content post.

First, if you haven't read my last article on working with user vars and displaying them on the front end, you may want to read that here: http://stratisdesign.com/stratisdesign/blog/programming/hello-user-with-c5-user-vars/

Create your new template folder structure

This is where the magic happens.

Going back earlier in this article, we want to avoid at all cost modifying in any way the existing content block if we can help it. Again, were we to do this, as soon as we update our core install, we would lose our modifications.

The Core content block can be found in ROOT->concrete->blocks->content

First, we are going to take advantage of the duplicated folder structure in the ROOT of your install and use the blank blocks folder. Lets create the following folders:

ROOT->blocks->content->templates->owner_vars

So we created a folder for the content block, a folder for templates related to it, and lastly a folder that represents the name of your custom view. In this case, I am naming this view "owner_vars", which is translated automatically in the custom view list in the front end as "Owner Vars".

Second, copy the view.php, view.css, and/or view.js from the core content block folder, and then paste those into your new owner_vars folder.

Technically, you now have a new view ready to go! That's it!

But we are going to take this a step further and add some stuff to our new view.

Adding some owner vars

Lets presume that you read through my last tutorial and know how to go add a custom user var in the backend. If you wanted to, you could add other user vars and associate them to collections/pages. But for now, we are going to focus on just the avatar and the owner info to be added to the top or bottom of our content item.

So lets edit that view.php file within our new owner_vars template of our content block.

Things are a little different in how you approach grabbing your user info within page versioning than simply using the $user object.

We will still use the UserInfo method, but first, we need to grab the author user ID so that we know who we are looking for other than the currently viewing user.

To do this, we will need to call on some globally loading "knowns" that load with every page, however, not the easiest to understand and work with. I will do my best ;-)

First, we load in the page collection as a globally accessible var "$c".

$c = Page::getCurrentPage(); 

Next, we are going to snag the user author ID from the collection page object. This is a built in function within the page model. If you scan through that file (ROOT->concrete->models->page.php) you can see all the functions and what they need as inputs that can be called on the $c (collection) object.

$uID = $c->getCollectionUserID();

Now we are going to grab our UserInfo object so that we can snag the avatar.

$ui = UserInfo::getByID($uID); 

Next we load the avatar helper.

$av=Loader::helper('concrete/avatar');

And last, print out our vars with an if statement on the avatar so that we don't blow up our page if the user does not have one. And then also, a simple call to the uName var from the UserInfo object.

if($ui->hasAvatar()){
    echo '<img src="'.$av->getImagePath($ui,false).'" alt="" />';
}
echo $ui->getUserName();

Now, it may be advisable(depends on your server) to add your global "BASE_URL" and even append that with the global "DIR_REL" vars in front of the getImagePath if your site is within a sub directory like so:

if($ui->hasAvatar()){
    echo '<img src="'.BASE_URL. DIR_REL.$av->getImagePath($ui,false).'" alt="" />';
}
echo $ui->getUserName();

All done!

So there you go. You created a new view of the content block, and you added some author info in front of or after the content within that view.

And the best part is...you are hassle free when updating your core install!

Loading Conversation