view.php not working
Permalink
Hi,
I'm working on building out my site blog and realized that my view.php file is not working. Here is the code for the view file:
Here is the URL for the blog page:http://concrete.lifestylerevolutionstx.com/index.php/blog/.... It is picking up the styles of default.php. At this moment in the development process, I am using the default page type for the index/home page.
I'm working on building out my site blog and realized that my view.php file is not working. Here is the code for the view file:
<?php defined('C5_EXECUTE') or die("Access Denied."); include('elements/header.php'); ?> <body> <div class="contain-to-grid sticky"> <nav class="top-bar"> <section class="top-bar-section"> <?php $a = new GlobalArea('Logo and Name'); $a->display(); ?> <!-- Left Nav Section --> <?php $a = new Area('Header Nav'); $a->display($c); ?>
Viewing 15 lines of 36 lines. View entire code block.
Here is the URL for the blog page:http://concrete.lifestylerevolutionstx.com/index.php/blog/.... It is picking up the styles of default.php. At this moment in the development process, I am using the default page type for the index/home page.
Just to add to that, the view.php is used as a kind of wrapper for single pages, probably explained a little better here by Mkly:
http://www.concrete5.org/community/forums/usage/view.php-and-defaul...
http://www.concrete5.org/community/forums/usage/view.php-and-defaul...
It appears you are including your <html> and <body> tags in your default.php and your view.php files as well as your header.php and footer.php files,
If you have these tags already in your header and footer files, do not add them again to your other template files..
I see from the url you posted that you are also duplicating the DOCTYPE and <head> tags?
If you have these tags already in your header and footer files, do not add them again to your other template files..
I see from the url you posted that you are also duplicating the DOCTYPE and <head> tags?
Good catch. You're right, I duplicated the html tag and some other opening document tags in the header and the page-type document. I removed these from the page-type documents and kept them in the header. However, it seems this wasn't the (main) problem. The page is still showing default instead of view. Do you happen to see any other issues? I included the updated code for view.php in my response to Vidall. Thank you very much for your input!
Hi, Yes it will still use default.php, view is used as a wrapper for "single pages" which are pages like the login page, they are not actually used by your theme to render pages that appear in your site.
For further explanation on the role of view.php and "single pages" have a read of this part of the developer docs:
http://www.concrete5.org/documentation/developers/pages/single-page...
http://www.concrete5.org/documentation/developers/pages/single-page...
So would having this line of code inside of a container div create a problem? Also, I have the menu on each page rather than in the header file because I need to be able to include certain page-type-specific style sheets and scripts in the header, so I need the </head> tag to be in the page type document itself. I've done the same with the footer. Do you think having these elements on the page itself are a problem?
I put the <head> tag and site-wide scripts and stylesheets in header, and updated the rest of the header/nav code in the page as follows, per the comment from @weyboat. The updated code for view.php is as follows:
Thanks for your help!
I put the <head> tag and site-wide scripts and stylesheets in header, and updated the rest of the header/nav code in the page as follows, per the comment from @weyboat. The updated code for view.php is as follows:
<?php defined('C5_EXECUTE') or die("Access Denied."); include('elements/header.php'); ?> <!-- if this page included special CSS/JS, the references would go here --> </head> <body> <div class="contain-to-grid sticky"> <nav class="top-bar"> <section class="top-bar-section"> <?php $a = new GlobalArea('Logo and Name'); $a->display(); ?> <!-- Left Nav Section --> <?php $a = new Area('Header Nav');
Viewing 15 lines of 38 lines. View entire code block.
Thanks for your help!
I normally have:
At the top of a template and this at the bottom:
$this->inc('elements/header.php'); ?>
At the top of a template and this at the bottom:
<?php $this->inc('elements/footer.php'); ?>
You still have closing </body> and </html> tags at the bottom of your view.php file,
I am assuming you also have those tags in your footer.php as well?
I am assuming you also have those tags in your footer.php as well?
No, they're not in the footer file. I have them in the page-type documents so I can better control the order in which some of my jQuery plugins initialize. To be honest, I'm not sure if this is necessary, but I do have a couple of plugins that probably put a heavy load on the browser, so I assumed it was important to be able to put these after some of the more lightweight JS that is included globally in the footer file.
Guys, I think the point is being missed here a little, view.php is never going to be used in the OP's blog, that is not how view.php works its not a page type as such.
EDIT: as stated below there was no intention to "mislead" anyone, at time of writing the above I personally had no idea pro-blog was being used, I was simply going on what the official C5 documentation was telling me.
EDIT: as stated below there was no intention to "mislead" anyone, at time of writing the above I personally had no idea pro-blog was being used, I was simply going on what the official C5 documentation was telling me.
You're correct of course @Vidall,
But the op needs to understand how the elements of a page are created so his pages display correctly,
Using his view.php file as an example will hopefully help him to understand how it all comes together...
But the op needs to understand how the elements of a page are created so his pages display correctly,
Using his view.php file as an example will hopefully help him to understand how it all comes together...
Using the view.php as an example will only serve to confuse things because any changes made to view.php file will not show up on his site. The blog page is using default.php to render the page, NOT view.php
UPDATE: RadiantWeb corrects me below. ProBlog is using view.php
UPDATE: RadiantWeb corrects me below. ProBlog is using view.php
I forgot to mention that I'm using ProBlog, which actually does use view.php for the blog. Should have mentioned this earlier!
OK... a couple of serious problems caused by taking a fully functioning HTML template and converting it to C5.
Here's some of the HEAD code:
First, notice that jQuery is being called on the last line which is a no-no because concrete5 already includes jQuery.
Second, the 'reset-min.css' stylesheet is the last css called. Any 'reset' css should be called first or else it trumps the css in your theme.
Here's some of the HEAD code:
<link rel="stylesheet" href="/files/cache/css/C5-LR/css/main.css"> <link rel="stylesheet" href="/files/cache/css/C5-LR/css/typography.css"> <link rel="stylesheet" href="/files/cache/css/C5-LR/css/foundation.css"> <link rel="stylesheet" href="/themes/C5-LR/css/fontface.css"> <link rel="stylesheet" href="/themes/C5-LR/css/general_foundicons.css"> <link rel="stylesheet" type="text/css" href="/themes/C5-LR/assets/css/livetweets.css"> <link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/2.8.2r1/build/reset/reset-min.css"> <!--[if lt IE 9]> <script src="/themes/C5-LR/assets/js/html5.js"></script> <![endif]--> <script src="/themes/C5-LR/js/vendor/custom.modernizr.js"></script> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
First, notice that jQuery is being called on the last line which is a no-no because concrete5 already includes jQuery.
Second, the 'reset-min.css' stylesheet is the last css called. Any 'reset' css should be called first or else it trumps the css in your theme.
For those of that don't know. When a Package installs a new pagetype, and the current theme does not have that pagetype, view.php IS used. NOT default.php.
This is because it is assumed that a package needing a pagetype is in fact either a theme itself or an application. This is intended behavior.
View.php should STRICTLY be:
- header
- body contain & print inner content
- footer
That's it.
Just want to clear that up. ProBlog WILL use your themes view.php if it does NOT have a pb_post page_type included.
I will try to reply later tonight with more detailed outline when I get back.
Out on vacation with family atm.
ChadStrat
This is because it is assumed that a package needing a pagetype is in fact either a theme itself or an application. This is intended behavior.
View.php should STRICTLY be:
- header
- body contain & print inner content
- footer
That's it.
Just want to clear that up. ProBlog WILL use your themes view.php if it does NOT have a pb_post page_type included.
I will try to reply later tonight with more detailed outline when I get back.
Out on vacation with family atm.
ChadStrat
Thanks for pointing out those errors, mhawke! I didn't realize that C5 automatically includes the jQuery library. Good to know! And good catch on the reset. Rookie mistake on my part (:
Page is still showing default.php instead of view.php, but who knows what other errors this fix will help me avoid. Much appreciated!
Page is still showing default.php instead of view.php, but who knows what other errors this fix will help me avoid. Much appreciated!
As I mentioned in your support ticket, there are only two possible ways this could be the case:
1) your theme actually had/has a pb_post page_type file. Simply work with that design if this is the case.
2) you had manually created a pb_post page_type via the C5 page_types dashboard page before installing ProBlog, thus forcing the use of your default.php file. If this is the case...delete it, and reinstall ProBlog.
I want to emphasize here, as some have made misleading statements, a package installed page_type WILL revert to your theme's file of the same name, or it's view.php. NOT default.php.
default.php is only used as a page_type template when generated from the dashboard page_type manager and no theme page_type of the same name can be found.
My suspicion is #2 is the case here.
To find out for sure, you can simply go to your dashboard page_types area, and look at the pb_post file package association. It should say "Pro Blog".
If it doesn't, delete it and reinstall ProBlog. Then check the dashboard page_types pb_post association again to be sure.
At that point, PB should be using your view.php.
Hope this helps.
ChadStrat
1) your theme actually had/has a pb_post page_type file. Simply work with that design if this is the case.
2) you had manually created a pb_post page_type via the C5 page_types dashboard page before installing ProBlog, thus forcing the use of your default.php file. If this is the case...delete it, and reinstall ProBlog.
I want to emphasize here, as some have made misleading statements, a package installed page_type WILL revert to your theme's file of the same name, or it's view.php. NOT default.php.
default.php is only used as a page_type template when generated from the dashboard page_type manager and no theme page_type of the same name can be found.
My suspicion is #2 is the case here.
To find out for sure, you can simply go to your dashboard page_types area, and look at the pb_post file package association. It should say "Pro Blog".
If it doesn't, delete it and reinstall ProBlog. Then check the dashboard page_types pb_post association again to be sure.
At that point, PB should be using your view.php.
Hope this helps.
ChadStrat
I'd also like to add, respective to ProBlog, there is important page_type controller data needed from the package. So it is important that you set up your site to properly be treating it as an application, and not as a standard theme page_type.
An "application" can be more than just single pages. They can have custom page_type controllers that are critical to their respective functionality. And so it is important that we define here in this conversation not just the what, but also the WHY is it that way???
Package installed page_types revert to view.php instead of default.php if there is not page_type of the same name within the current theme because it is assumed that said package has a reason and/or practical controller level need for that page_type.
I hope this helps clarify for others the important distinction of application level control of page_types.
Not trying to be a know-it-all, just clearing some finer points up. :-)
ChadStrat
An "application" can be more than just single pages. They can have custom page_type controllers that are critical to their respective functionality. And so it is important that we define here in this conversation not just the what, but also the WHY is it that way???
Package installed page_types revert to view.php instead of default.php if there is not page_type of the same name within the current theme because it is assumed that said package has a reason and/or practical controller level need for that page_type.
I hope this helps clarify for others the important distinction of application level control of page_types.
Not trying to be a know-it-all, just clearing some finer points up. :-)
ChadStrat
Thanks for your input, Chad. I tried your recommendations, and don't think it is either of those issues. This is a theme I built myself, so there definitely wasn't a pb_post page_type prior to installing the package. It probably wouldn't be the second one either, because I installed the package before going through the documentation for setting it up. Also, I did as you recommended and deleted the pb_post page_type (which was named "ProBlog Post"), then uninstalled and reinstalled the package, but the page is still utilizing default.php.
I messaged you FTP and admin access credentials per your request on my support ticket.
Thanks!
I messaged you FTP and admin access credentials per your request on my support ticket.
Thanks!
couple issues:
#1 - you didn't have the Blog post set to use pb_post page_type.
#2 - I styled pb_post page_type for you. a simple, sidebar layout that your view.php will wrap around. This will feel like a big "ahhhhhh, I get it now.." when you see it. Honestly, your markup is really complex....so it's no wonder you got yourself confused.
#3 - you need to go to your pb_post page_type defaults and add 4x prolog_list blocks to the the sidebar, and then change their custom block views to "tag","category"....ect. then make sure you click on each one and "push to children". I couldn't do this, only admins can do this. Also add the guestbook & push to children. (or enable Disqus integration in the ProBlog Dashboard settings area.)
After that, just make double sure you select ProBlog Post as the page_type when you add new posts. You can also set this as the default page_type in your ProBlog Dashboard settings area.
You should be all set after doing these.
ChadStrat
#1 - you didn't have the Blog post set to use pb_post page_type.
#2 - I styled pb_post page_type for you. a simple, sidebar layout that your view.php will wrap around. This will feel like a big "ahhhhhh, I get it now.." when you see it. Honestly, your markup is really complex....so it's no wonder you got yourself confused.
#3 - you need to go to your pb_post page_type defaults and add 4x prolog_list blocks to the the sidebar, and then change their custom block views to "tag","category"....ect. then make sure you click on each one and "push to children". I couldn't do this, only admins can do this. Also add the guestbook & push to children. (or enable Disqus integration in the ProBlog Dashboard settings area.)
After that, just make double sure you select ProBlog Post as the page_type when you add new posts. You can also set this as the default page_type in your ProBlog Dashboard settings area.
You should be all set after doing these.
ChadStrat
Thanks for the quick reply. Weird that you aren't able to use admin privileges, as I assigned them to your user. I went to the blog page and it is still showing the default.php page. Any idea why this would be?
What do you mean about my markup being complex? You mean because not all the header and footer elements are contained strictly in those documents?
Tbh, I didn't fully understand #3. Sorry :/. This is my first experience with C5, and I'm fairly new to CMSs in general. Can you elaborate a bit?
Thank you!
What do you mean about my markup being complex? You mean because not all the header and footer elements are contained strictly in those documents?
Tbh, I didn't fully understand #3. Sorry :/. This is my first experience with C5, and I'm fairly new to CMSs in general. Can you elaborate a bit?
Thank you!
take a look at your /blog page now. I set that page to pb_post page_type as well.
#3 - you go to your dashboard page_types area (just type 'page_types' in the search bar) and then click the "default"s button for the pb_post, and make sure the sidebar blocks are there and their custom views are set. looks like you got that though.
then, you will want to open up the actual pb_post.php file I edited for you in your root /page_types folder. take a look at how I got there useing your themes css divs.
ChadStrat
#3 - you go to your dashboard page_types area (just type 'page_types' in the search bar) and then click the "default"s button for the pb_post, and make sure the sidebar blocks are there and their custom views are set. looks like you got that though.
then, you will want to open up the actual pb_post.php file I edited for you in your root /page_types folder. take a look at how I got there useing your themes css divs.
ChadStrat
all you need in a view.php is the includes for your header and footer and this line of code: