view.css not been pulled in automatically for an add.php operation. Anybody know what could be wrong?

Permalink
I have a view.css in my block directory. All well and good.

The documentation here says...

"The following named items will be automatically added to a page's header, if the block in question has been added to that page:

view.css
view.js"

After adding a block, sure enough, the view.css is pulled in and used by the edit operation (using edit.php).

I've created a new page and am trying to add a new instance of a block but the view.css is not being pulled in like it is for edit.php.

Anybody have a clue as to why not?

If that is normal behaviour for an add operation what is the best way to apply CSS to the add form that shows up (which is really just edit.php being included into the add.php file)?

Thanks.

Carlos

 
jordanlev replied on at Permalink Reply
jordanlev
As far as I know, view.css and view.js are only included in the view of the block (view.php) -- not add.php or edit.php. Not sure why it's showing up for either of those.

When I need to include css in the add/edit dialog, I unfortunately have to resort to including an inline <style> tag in the add.php/edit.php file (which is not W3C valid, but does work in every browser).
You might try calling $this->addHeaderItem() in the block controller's add() and edit() functions, but that might not work (if those functions are called after header items are outputted by the system).

Wish I knew a better way (there may be one, I just don't know what it is).
carlos123 replied on at Permalink Reply
Thanks for the input Jordan.

view.css is most definitely pulled in by C5 for an edit.php. And for an add.php as well as view.php.

I have one page that uses a bunch of the block in question. I can add, edit, and view the blocks just fine with the appropriate CSS.

I go to add that same block on a new page and no go.

Only the edit.php has the css pulled in on that page for some strange reason. It's not just that block though. Other blocks I have created...same thing. They are missing their CSS.

I may have messed something up in my database as I have been making a lot of changes to the database directly (moving content around between blocks within the database, etc.).

I'll play around with it some more in the next couple of days by installing C5 fresh in a directory, installing the block in question there fresh, and then will try to add, edit, and view something using that block.

I will then do a comparison of the two versions of the database to see if I might be able to uncover why the CSS is missing at times from my present C5 installation.

I'll report back here if I find out anything that solves my problem.

Thanks again.

Carlos
carlos123 replied on at Permalink Reply 1 Attachment
Hmmm...I decided to work on this tonight some.

Installed Concrete5 5.4.1.1 into a fresh directory (actually just copied a fresh install directory that I have over and continued from there). Included brand spanking new database.

I then copied one custom block over, installed it through the Dashboard, and then created a new page and added an instance of the block to it.

When I pressed the Add button I got the following error indicated in the attached image file (I could not copy the error from off the browser screen for some reason).

Continuing to work this out...

Carlos
carlos123 replied on at Permalink Reply
Okay...I'm back in business.

Enabled pretty URL's.
Added an .htaccess file (fresh install did not have one).
Disabled cacheing and also cleared the cache.

Weird. This problem could point to something in C5 that needs to be fixed as not having an .htaccess file should not cause an error like this.

Too busy to chase this error down myself.

Back to working out the lack of CSS problem...

Carlos
carlos123 replied on at Permalink Reply
Hi Jordan,

I've had sufficient time to play around with it now and I can confirm and absolutely so that any view.css in a block directory IS included for all edit, add, or view operations of the block.

This was determined from a fresh and clean install of Concrete5 on my localhost copy of Apache running with a fresh database.

So there was nothing from existing site to corrupt what was happening.

The block in question is a very simple block that simply allows one to enter a Page Title which the block encases in a particular CSS class for all edit and add's and in a particular CSS ID for the view.

The CSS inside my view.css that I used for testing was...

/*
 * This CSS file is automatically included for all the following operations...
 *
 * - edit block
 * - add block
 * - view block
 */
.field {
  width: 400px;
  background-color: cyan;
  }
#page_title {
  background-color: pink;
  }


As to why the CSS is only showing up for an edit but not an add on my existing client site...I have no clue. If no one has anything to add to this...I'll have to look around some more to figure out what happened to make my site act differently from a fresh install in that regard.

Carlos
carlos123 replied on at Permalink Reply
I figured it out Jordan if you are still following this thread.

The problem was that I was using an ID in the view.php file that was different than the CSS class that I was using in the edit.php (and by including it) into the add.php files.

Part of the problem was that the CSS in my view.css was targeting the ID and not the CSS class for the edit and the add.

Another problem is that the CSS selector referred to in the auto.js file simply did not exist (I had copied the auto.js file elsewhere and had forgotten to change the selector).

I fixed the above and things are back to working as expected where the view.css is being pulled in for all edit, add, and view block operations.

Thanks again for your input Jordan.

Carlos
jordanlev replied on at Permalink Reply
jordanlev
Well I'll be! Never new about the view.css being used in add/edit dialogs -- good to know.
carlos123 replied on at Permalink Reply
I feel...well...rather humbled that my little meanderings into all things C5 should enlighten you on anything Jordan (given your renowed prowess in such) but...well...there you go :).

Carlos
carlos123 replied on at Permalink Reply
I misspoke about having fixed this.

Now the view.css is not loading the first time a new block is used. After the first time no problem (which led me to think it was fixed).

I think I did fix the weird error I was getting though in that I added "Loader::block('library_file');" just before the class definition in the block's controller.php file.

The HTML standard block had that line so I added it to mine and the problem went away. Have no clue why.

Anyway trying to track down why view.css is not loading on the first use of a block, and only the first use, after a new install of it.

This whole thing has been, as usual, an absolute pain in the butt trying to figure out what is what and where is what (sigh).

Using a fresh Concrete5 install.

Carlos
Shotster replied on at Permalink Reply
Shotster
> Now the view.css is not loading the first time a new block is used.

To my knowledge, view.css is loaded only for a block's view - not for add or edit. What might be happening is the following...

In the "add" dialog when the first instance of a block is added to a page, the styles in view.css will not be applied because there is no such block on the page yet. Once you add that first block, view.css is then loaded. Thus, any subsequent "add" or "edit" dialogs will have access to the styles in view.css by virtue of it having been loaded by the instance of the block on the page - not by the add or edit dialogs explicitly.

Just a guess...

-Steve
carlos123 replied on at Permalink Reply
Hi Steve,

Yeah...I kinda surmised that might be happening because if I clear my browser cache, reload the page, and then try and add a block...the view.css is NOT loaded.

But if I add a new block after having previously added one (or maybe edited one)...the view.css is still in the browser cache (or somewhere I guess) such that a new add of a block that uses said view.css uses it.

This is awefully confusing.

Jordan...if you are still following this thread I must take back what I said, I think, about view.css being applied to add, edit, and view.

So if view.css is NOT pulled in for an add operation how does one CSS target their add form??

What I want to do is CSS control my add, edit, and views? I can't believe this is so difficult (if you ask me an MVC approach is absolutely a crazy way to program)!!!

Anybody?

Carlos
carlos123 replied on at Permalink Reply
I wonder if I should just scrap Concrete5's way of using MVC and just code a block myself in whatever way I want (and can understand)?

I mean instead of relying on C5 to pull in CSS at various times and in various ways and sometimes as if by magic...if it might not be easier for me to just hard code CSS stylesheets into my code wherever I want to have them and ignore how C5 does things (or not as the case may be).

Just good ol, CSS principles of how to use CSS files without all this MVC baloney.

Carlos
carlos123 replied on at Permalink Reply
Yup!

I split the CSS inside the view.css file, took out the parts that were for the add and edit and stuck them inline at the top of edit.php and yesiree....IT WORKS!

None of this MVC spaghetti.

Sheesh.

What ever happened to the simplicity of CSS, HTML, and PHP?? MVC is supposed to make things easier not ten times harder!

Oh well...thanks for your help guys.

I have it working and that's good enough for me to continue and finish off the one C5 project I have going on.

Carlos
Shotster replied on at Permalink Reply
Shotster
> I split the CSS inside the view.css file, took out the parts that were for the add and
> edit and stuck them inline at the top of edit.php and yesiree....IT WORKS!

Yeah, but as Jordan said, it's not valid. Style's don't belong outside a document's <head> tag.

-Steve
carlos123 replied on at Permalink Reply
Well...valid or not...I believe doing it that way works in every single browser that I know of and is much simpler than the contortions that C5 seems to require to get this to work.

Not to mention...that, if I am not mistaken, the code produced by C5 doesn't validate anyway which makes validation sort of a mute point if you ask me.

Don't get me wrong. I am all for validation where I can reasonably do it but between validation where I must contort things all over the place and overly complicate my life trying to do things C5's way and cutting out the complexity and doing things that just work...well...I chose the way that works.

Carlos
Shotster replied on at Permalink Reply
Shotster
> What I want to do is CSS control my add, edit, and views?

I do precisely that with my add-ons, as I like to style things a bit differently from the C5 default styling. Here's how I do it...

I create a stylesheet called "addedit.css" and place it in the block's folder. Then, I add the following function to my block's controller...

private function loadEditStyles() {
   $hh = Loader::helper('html');
   // Don't use getBlockTypeAssetsURL() b/c if user overrides a template, it will return the root block's URL, and we always want the package URL.
   $this->addHeaderItem($hh->css(DIR_REL.'/'.DIRNAME_PACKAGES .'/my_package_handle/blocks/'.$this->btHandle.'/addedit.css'));
}


Lastly, I invoke that function from the controller's add() and edit() functions. That's it.

Hope it helps,

-Steve
carlos123 replied on at Permalink Reply
Thanks Steve but in all frankness can you see how that overly complicates what should be a straightforward CSS and HTML thing?

I mean what could be simpler than adding the appropriate CSS into the edit.php file at the top inline?

Instead of all that loading the html helper, invoking it's methods, and then calling that function from within the add() or edit() public functions of the controller.php file.

No offense intended Steve...I mean your way is certainly more of a C5 way I guess but it's also a very good example of how MVC is complicating things to the wazzoo if you ask me for very little if any extra benefit in making the life of the developer simpler.

Even if one wants to put the CSS for the add and edit in external CSS files it is still simpler to call those CSS files into edit.php manually than doing it the C5 way.

When it comes to coding things I like clean and simple.

Carlos
Shotster replied on at Permalink Reply
Shotster
> I mean your way is certainly more of a C5 way

More than that, it conforms to the W3C standard. I've encountered issues before with using the <style> tag outside a document head. Those issues can be tricky to track down.

> Even if one wants to put the CSS for the add and edit in external CSS files it is still
> simpler to call those CSS files into edit.php manually than doing it the C5 way.

That would not be valid HTML either. You can put any tag willy nilly wherever you want and hope it all works. Browsers these days are actually quite tolerant of sloppy and invalid mark-up, so the odds are with you. I just prefer to do things the right way (and I'm not talking about C5 MVC; I'm talking about compliance with W3C standards.)

Regards,

-Steve
Shotster replied on at Permalink Reply
Shotster
> When it comes to coding things I like clean and simple.

What's "clean and simple" about duplicating (and thus having to maintain) the same styles in two different files AND violating well-published HTML standards. My approach is actually cleaner, more modular, and conforms to standards.

Whatever works, I reckon...

-Steve
jordanlev replied on at Permalink Reply
jordanlev
This is an enlightening discussion -- Steve, nice catch about the view.css file being loaded when the page is viewed and then sticking around for when the block is edited.

As for the W3C valid thing... well we've had the same discussion before in other contexts. I totally respect your opinion on it, but I'm with Carlos on this one -- for something as back-endy and already probably non-standard as the C5 editing interface, I think it makes more sense to just inline the styles in edit.php. For me there isn't any duplication because the styles are different than anything that would be in the view.css or theme css. That being said, I do appreciate you posting that code for how to do it via the controller -- but can you confirm that this actually works because my experience is that by the time add() and edit() are called, the header items have already been outputted and so it's too late to send anything else (I know this is true for the view() method -- maybe I'm confused about add() and edit()? ).
Shotster replied on at Permalink Reply
Shotster
> I totally respect your opinion on it, but I'm with Carlos on this one.

No worries. I'm not averse to hacks IF there isn't a better way to go about it. I see my approach as better for the reasons I cited, but not necessarily everyone will agree.

> I do appreciate you posting that code for how to do it via the
> controller -- but can you confirm that this actually works

Yes, it absotively posilutely works.

> because my experience is that by the time add() and edit() are called, the header
> items have already been outputted and so it's too late to send anything else (I know
> this is true for the view() method -- maybe I'm confused about add() and edit()? ).

In the context of an AJAX request (which is how both the add and edit dialogs are implemented in C5), the header items are injected into the document <head> via JS. Thus, it's not a server-side thing but rather a client-side thing. Works just fine.

-Steve
jordanlev replied on at Permalink Reply
jordanlev
This is great info to know -- thanks for the response.
carlos123 replied on at Permalink Reply
Hi Steve,

I don't quite understand the part about maintaining the CSS in two different files Steve.

If you mean having to maintain the CSS in a view.css AND that which I inline in edit.php...well...the thing is that you also have to maintain in two different files too Steve. The view.css and in your case an external CSS file that you pull in through the html helper.

By splitting the CSS out and bringing it closer to the HTML which it affects I actually make it easier to maintain and work with the code.

Incidentally I am normally with you 100% in terms of doing things a standard, valid way Steve.

It's just that I have gotten so sick and tired of trying to figure out what C5 is doing (and getting it wrong half the time) that I will settle for a violation of doing things the standard, valid way in this one case. To make my life as a web developer using C5 easier.

By the way...I couldn't help but notice as I thought about this...that the inline inside edit.php approach also saves HTTP calls in that external CSS files no longer have to be gotten apart from the HTML they affect.

Not saying that external CSS files are bad. Only that in this one case...inlining the CSS inside edit.php does have it's benefits.

In the end...like you said...whatever works. The end client doesn't care one whit about CSS anything so this is mainly something that makes my life easier is all.

Carlos
carlos123 replied on at Permalink Reply
You know now that I think about it...another approach is to pull in view.css into the add.php file at the top.

Through a regular CSS link like so...

<link rel="stylesheet" type="text/css" href="view.css" />


That's assuming one wants to keep all the CSS for the block together in one view.css file.

For the record...that's not standards compliant either for anyone reading this thread and evaluating these different methods but it will work with the minimum of fuss.

Carlos
carlos123 replied on at Permalink Reply
That particular CSS link won't work by the way.

For some reason C5 considers itself rendering the page from a couple of directories up from the block directory.

The CSS link that does work has to start down the directory tree from the /blocks directory.

Here is the code that does work...

<?php
defined('C5_EXECUTE') or die("Access Denied.");
?>
<link rel="stylesheet" type="text/css" href="/blocks/cgc_page_title/view.css" />
<?php
$this->inc('edit.php');
?>


For what it's worth.

Carlos

PS. Better yet...

<?php
defined('C5_EXECUTE') or die("Access Denied.");
echo '<link rel="stylesheet" type="text/css" href="/blocks/cgc_page_title/view.css" />';
$this->inc('edit.php');
?>
carlos123 replied on at Permalink Reply
Oh...for what it's worth one other tid bit.

Pulling in the view.css into the add.php file seems to automatically make it available to edit.php too!

I am not sure how that happens exactly but I think C5 just includes view.css in the head section on finding a block that needs viewing on a page.

When you edit the block...it apparently has view.css already cached or something.

A block cannot be edited unless it has...well been added first such that the view of that block (before an edit) always pulls in the view.css file (I think).

So attaching view.css to add.php seems to automatically take care of it being used by edit too.

So now all adds, edits, and views of my blocks will have the CSS I want to use included. Sweet.

Carlos
Shotster replied on at Permalink Reply
Shotster
> I don't quite understand the part about maintaining the CSS in two different
> files Steve.

I was just referring to having to put the same "editing" styles in both add.php and edit.php, but perhaps I misunderstood what you were saying.

> ...well...the thing is that you also have to maintain in two different files too Steve.

No, I don't. I use special styles STRICTLY for customizing the add and edit dialogs. I never use view.css. I always add the styles for the public-facing views to my main stylesheet (easier to maintain and reduces the number of HTTP requests). I also never have a need to use the same styles in the editing dialog AND the public view. After all, C5 provides a nice mechanism for creating custom view templates for any block, so a user may well override a block's default view. Assuming that a user will never deviate from the default view is, in my opinion, bad design. In fact, some of my add-ons encourage custom view template creation.

> It's just that I have gotten so sick and tired of trying to figure out what C5 is doing

I completely empathize with your situation and agree that there is a steep learning curve once you get beyond the basics of C5 development.

The only reason I offered up my solution is because, even though Jordan offered his solution (the one you eventually adopted) within a few hours of your original post, you were still experimenting 5 days later. Since I had "been there and done that", I thought I'd share my experience.

Anyway, I'm glad you resolved it. Be sure to mark Jordan's answer as best so as to help others searching the forums.

Regards,

-Steve