What question do you have?

The forums are the best place to look, if the Documentation section doesn't have what you're looking for.

This howto has some suggestions:
http://www.concrete5.org/documentation/how-tos/editors/getting-help...

You have posted quite a few questions and some have not been answered, not many, sorry for that. Maybe the reason is that sometimes things get overlooked, buried or just lost in the C5 process.

Please do not lose heart.

Reply to your own post (bump) and maybe someone will pick up on it.

For someone who seems to know English, your spelling of medium is abnormal... but don't give up on this medeum our new friend! I will say I agree that the C5 forums are unfortunately a bit sparse in visitors but I don't it's beyond hope I feel more people will join and soon responses will be faster.

It's the holiday season. Lots of us are intentionally turning off the devices and spending time with our families. Yes, things seem a little quiet right now but don't give up.

@goldhat, please don't taint your otherwise well-intended answers by pointing out typos. He who is without sin, etc.

@mhawke I didn't realize his use of medeum was a typo, it was the same word spelt the same way twice in a row... seemed more like slang.

Wow! All this great response has renewed my faith in C5. It's like knocking on the door of a dark house in an abandoned town and finding out that this is where the party's at. Thank you all so much for inviting me in. My post wasn't meant to be derogatory in nature but I couldn't help that my frustration started to show in it. This post is probably longer than it should be but it is an explanation of my thought process while I approach this project so that I may be corrected on anything that may be getting me into trouble. While I am not completely new to Concrete5, I am for the first time challenging myself to try to do things in c5 according to the way c5 is constructed.

I thought I had two separate issues but after working out the problem of c5 loading my block's view.js before the two Jquery add-ons, it now looks like both issues are related.

I started writing a three page process that a client would use to sign up for my service on a dedicated server. I created the first page that the subscriber would use to select their new service's configuration by using the HTML block provided in c5 to wrap my markup and Javascript. This page doesn't have a lot of HTML in the block but it is heavily driven with Js. I had it working just fine with my code wrapped up in the HTML block.

When I started the 2nd page of this process I decided that it was time to start using the power of Concrete5 by creating this form in a custom block and let c5 do all the housekeeping. I created the second in the series of forms as a custom block. It was wonderful. It's such a better approach to developing in c5 that I decided to go back to the first form, removing it from the HTML wrapper block, and make it it's own stand alone block. That's when my problems started. I removed the js from the markup, placed it in the block's view.js file, and put the HTML in the view.php.

In this first form, I use a cookie to save the state of the form to the client's computer so that if they leave the page and return, the form is still as they left it. I heavily use getElementById() to control the form's elements. My problem child is the use of getElementsByTagName('input') in my initialization function, purchaseLoaded() to retrieve a set of six check boxes as an array. In this function, I use the following two lines;
'Slots = document.getElementById("slots");'
'SlotsInput = Slots.getElementsByTagName("input");'
The second line is throwing an error of "typeError: Slots is null".
As you can see in my code below, I added an alert() to test if the form was even loaded at this point which it was not. It returned that the input array was '0' in length. It should have reported '6'. I believe, at this point, Concrete5 hasn't finished sending all of the page's content before the client's browser (my browser) thinks it is finished loading. At this point let me say that I am using the latest Firefox running in Ubuntu 12.04. I have cleared both the browser's and c5's caches and it didn't help.

I also am experiencing the same thing with $.cookie("CartData") in the same initilize function called when $(window).load() triggers. With a little effort, I do now have the Jquery cookie add-on loading after Jquery and before my view.js script in the header. (At least that's what Firebug is showing me.) The Jquery.cookie script is not being found by the browser and throwing 'TypeError: $.cookie is not a function'.

I had to "Micky Mouse" where the script loads from in order to have the scripts load in a proper sequence. I placed all three scripts in the root js folder in sequence to get them loaded properly. I shouldn't have had to do that. I want the two Jquery add-ons that I'm using to load from my header file (or an appropriate place) to make them available to all pages. When c5 loads the scripts for blocks added to a page, c5 inserts their scripts into the <head> element before loading any scripts added from the header file. This, to me, seems to be Bas-Ackwards from the way things should load in order to maintain a proper relationship with the way they are used by the elements on a page.

One other item, and this is a quirky observation. If a script is removed from a folder or moved somewhere else and you forget to remove the script load line from your header, c5 will still load the file from the cache even though it no longer exists. It will have you scratching your head while looking for the file that is being loaded in error.

I'm not clear on what parts of this you solved already but if you're still have issues with the JS not loading consistently or in the right order you might find this helpfulhttps://www.concrete5.org/community/forums/customizing_c5/c5-bug-or-...

All those getElementById and other non-jquery functions could be rewritten, not sure if that is vital or solves any current problems but it make it all easier to read simplify it.

Hi Thomas,
To be honest I am not sure I understand everything you are explaining but I am going to try to comment on what I think I understand:

Concrete5 generates forms (pure PHP) before loading the js scripts but then it depends on how you set it up.

For instance, if your view.js calls a function before the page is loaded you might have problems.

From what I can see, your script is loaded in the header and doesn't wait for the whole page to be loaded to start looking for input fields.

To make it simple: If the script is set to wait for the page to finish loading before executing then it doesn't matter if it loads before or after your form. On the other hand if the script executes as soon as it is loaded then you have to make sure it is loaded after your form in the page.

What you are doing is putting your script in view.js. That's one proper way of doing it but it doesn't give you much control over loading.
Another way is to use Concrete5 html helper to load your script manually either in the header or in the footer. Typically it's better in the footer to make sure your elements are in place before the script loads and executes.

One thing I'm confused about is that you are writing pure javascript but then you are talking abut your jquery script. Are you using both?

A bit like @mnakalay says. Either use only direct javascript access to the dom, or use jQuery for everything. Using a mix of both just confuses things.

As you originally did, you could just keep the script in script tags at the end of your html block, or add it in script tags to your view.php for the form.

Also, to make sure it does not get run until everything is ready, put the whole script inside a jQuery ready handler. That will both make sure it waits until the dom is ready with all script resources loaded and because the ready handler also makes a closure will prevent any conflict with global names.

Hi again y'all. Thanks again for your responses.

I should have included all my code as an attachment like I originally intended but it was too much to upload. So, I just tagged in a snippet of my initializing function which doesn't show the whole picture. I will try to upload my view.js file again.

My initialization script is being called at the finish of the DOM load with the use of Jquery's $(window).load(purchaseLoaded() so that everything for the window is loaded before firing. $(document).ready() fires as soon as the DOM is loaded.

I'm sure that my success when I bundled this form up in the HTML block is because I included my script after my HTML in view.php. Now that I have separated the two into their respective files, it's up to c5 to load them into their proper sequence. I know there must be an absolute proper place to put these files so that they load in order but what I have done so far isn't working for me except for my "Micky Mouse" approach. The biggest question I have for the c5 developers is where should site wide script add-in files be placed and where is the proper place to call them to load into the header so that they load with c5's default script loads and before anything else is loaded. There has to be a mention of this somewhere in c5's massive documentation but I haven't been able to find it.

As for my issue, I could probably make it work for me again by putting the js code back in line after the HTML but there has to be a proper way to do this.

I was wondering if the block's controller has a method that I could use that would guarantee c5 has finished loading the block before the method is called?

In summation, What isn't working;
1) My form doesn't seem to be loaded before my Javascript looks for it.
2) Even though I have Jquery.cookie loaded in the <head> section, my initializing script doesn't find that either.

I have this working now but the work-arounds that I had to use, I should not have had to.

First of all, c5 auto-loads scripts out of sequence so I am using my block's controller to load my scripts in the right order but this block is really not the correct place for loading Global scripts.
public function on_page_view() {
$html = Loader::helper('html');
$this->addHeaderItem($html->javascript('jquery.cookie.js'));
$this->addHeaderItem($html->javascript('jquery.formatCurrency-1.4.0.min.js'));
$this->addHeaderItem($html->javascript('view.js'));
}

Then I placed part of my Initialization script at the bottom of my view.php to ensure that this block was loaded before Initialization took place.
<script type="text/javascript">
$( window ).load(function() {
IniitializeForm();
ReadCookie();
updateTotal();
FinishedLoading = true;
});
</script>
This is not what I would consider a good solution to my issues. It just allows my block to work.

I'm wondering why you feel it's not a good solution. The design and function of every block is different and so they each require a different architecture and you have structured yours to meet your needs.

Sounds like you got it working but you're not happy with using the on_page_view(). I'm fairly new to C5 so I'm not sure why on_page_view() would be better or worse a place to load JS compared to other options.

Recently I made a package that installs a live chat service (purechat.com). And PureChat provides a JS snippet that needs to go in the header or footer of every page of the site. So I ended up using the package controller function on_start, and the C5 event on_page_view. Using that event you can define a function to have called, so now on every single page of the site my function defined in the event runs, and in there I add the JS snippet using addFooterItem. Is this the best way... I don't know, but it worked and it is quite easy to implement, and if you needed to prevent the JS from being just on certain pages, you can work with the $c object passed through the event function.

I'm not sure if your block is going inside a package, but putting it in a package is fairly simple to tackle and you could drop your block into it and then you have access to the package controller.

This is my first attempt at creating blocks. This is for my own use, so I am not packaging it. I don't like that I'm putting my 'on_page_view()' in the block's controller to load my global scripts and moving the view.js file from auto-loading to loading from the controller. I would rather place the addHeaderItems in something like a controller for my theme or my header object and let the view.js auto-load like it should, but as I have found so far, there are no controllers for themes or header elements. Controllers exist on the pageType and block levels.

I also don't like that I had to put my JS Initialization snippet at the bottom of my block HTML in order for the block to be loaded into the DOM before calling it.

Don't miss-understand my attitude to all of this. I have committed myself to c5 as my platform to build on because of it's architecture being so much better for developing with than the other CMSes out there. I just haven't been able to find the correct way of doing things yet with c5 that addresses proper structure and also loads all components of my project into the page in proper sequence. I have just signed up for the Developer Training Classes offered by the c5 team. Maybe, this will give me the answers that I am looking for.

Well actually if you want to load global script that are not linked to a single block but should be present on several pages, you only need to load your scripts from your theme header.

Best practice would want you to have header and footer in separate files in your theme. All you need to do is load your script from your theme's header file like in any normal website.

Indeed loading a script from a block should only apply when the script is only required by that block.

Actually, I have 2 scripts already loading from my header, my main.css and the theme's topography.css files. Unfortunately, they're getting loaded last. So far this hasen't been a problem since I have done all my styling up until now in the main.css. This means that any local styling that I do in my view.css will not override any general stylings which is the whole concept behind CSS. When I learn how to do this correctly, I will have to move these also. This is why I wish I had controllers associated with the theme's element files.

@ThomasJ
You don't need to call the typography.css file from your header, The typography file is only used by the tinyMCE rich text editor and tinyMCE will look for the typography.css file in your themes root (the same place as your default.php and view.php templates) whenever it needs it!

Vary interesting. I didn't know that it auto-loads. I have been putting it in my header from day one because in my first attempt to crate a site with c5, the themes that c5 supplies with it has them linked from the header elements and I have been just following the example thinking that the typography.css was applied to all the theme's text elements. I'll check that out later.

If typography.css is included in your theme then those rules will apply to tinyMCE AND your site as well. When weyboat say that 'typography is only used by tinyMCE' he kind of means it the other way around... tinyMCE only looks at typography.css for it's internal styling. It's all very confusing ;->

Something needs to be the final arbitrator on a CSS rule and I prefer the theme's css to be that judge. I have, on occasion, needed to put the odd !important on my block's view.css but I'm just being lazy. What I should do is wrap my block in a < div class="my-block-name">.. < /div > and properly target the rules in my view.css to apply only to my block's elements. IMHO, the way concrete5 loads them right now is correct in that 90% of my block's elements will carry the style from my theme's css and only those elements I properly target in my view.css will be styled differently. I think if these assets were loaded the other way around, the sites would be a mess and we'd all have to chase down which block's css is creaming our site.

Putting all my styling in the theme's main.css and targeting page and block differences is basically what I have been doing up until now. Now that I'm trying to learn the correct way of using c5, I have to start thinking about programming granularly as with the way c5 is designed. So far though, My experience is that anything auto-loaded by concrete5 will appear in the header first, before the linked in scripts are loaded. Therefore any auto-loaded view.js or .css happens well before the theme's main.css preventing the local styles from Cascading properly. Your experience is not the same as mine, so I know that I am still doing things wrong. Perhaps the classes I am signed up for starting this Friday will straighten my head out.

When working with clients, I have found that the more experience they have building pages with 'traditional' website building tools such as Dreamweaver, Frontpage or just writing HTML with Notepad, the longer it takes them to get their head around concrete5. You sometimes need to let go of all that experience before you can truly 'get' concrete5.

Try this technique to target your block's css very specifically:

Throw this into the view.php of a test block :


and this into the view.css :



By using tight ID's like this to target your rules, it shouldn't matter what order your css gets called in the browser.

This is how I have been coding my main.css up until now. But to have to extend this technique into the view.js file defeates the whole purpose of the way Cascading Style Sheets are supposed to work.

Right now I am digging through the the page loading sequence to try to assertain why c5 loads out of sequence. Right now, I am looking at Header_Required.php's call to $this->controller->outputHeaderItems(). I am trying to identify what controller that $this->controller represents that contains the method outputHeaderItems().

It's not 'out of sequence'. It's by design. The consequences of flipping the sequence will be bad but go ahead and see for yourself. Every block that hasn't scoped it's css can overwrite your main.css.

Besides, if you put all your block's css into your main.css then this 'bloated' css file will be loaded on pages that will never contain that block.

You're right and you're right.

I haven't thought about other's blocks that I may use that are poorly constructed. I will have to think about that.

The reason I want to establish my technique of properly cascading file loads is to get away from wrighting one bloated main.css file. I will think about your suggestion of sectioning off the cascading sheet's functions with a local referancing <div> tag to hard limit the scope of all styles.

Quite often I 'retrofit' existing blocks by adding a wrapper DIV so I can target the css. In my opinion, a wrapper class should be mandatory for all packaged add-ons in the marketplace but that won't help us with the existing ones.

Also, in what order would you like all the myriad css and js files to load. Alphabetically? By DOM order? If it's by DOM order then as soon as you move a block to a different editable area, the page loads these files in a different order. The answer is always for developers to wrap their blocks properly and target their css accurately so their style rules don't bleed.

In a perfect world where every accepted package adheres to a standard protocol, I would expect the load order of supporting files to be the same as the hierarchy of the collections that they support. the main.css and .js along with other scripts that support the theme overall, be loaded first. Then, any variations that support specific page types to be loaded next. Last, scripts that load with blocks would load last.

By the way, How does c5 manage the view file loads when there are multiple blocks being used on the same page.

Never mind, they each are located in seperate folders so there's no conflict.

I now see your point. Multiple CSS files with conflicting entries will still create problems if not properly targeted and limited in scope using prefix tags.

On the other hand, My main concern now is properly sequencing the JS file loads while still maintaining proper c5 etiquette. These have to be loaded in order because of their dependencies.

The core team needs to build a system for the real world and with hacks like me building blocks, the system better be as accommodating as possible! I guarantee that if this were a proprietary system with all the blocks being built in-house, the architecture would be MUCH different. I'm sure that both Andrew and Franz are painfully aware of all the compromises they have made compared to the 'ideal'. These compromises allow the ecosystem to be built by relative novices.

the controller is concrete\core\libraries\controller.php but it calls the function from another library concrete\core\libraries\view.php

Thank you very much. That's a hard one to find. I can't seem to find a starting place for the hunt.

problem fixed :)

This post by vagesgirl is a SPAM that takes you to a commercial website and all the links work.

That is not true !!!

i am trying to find a solutions to a problem i am having!!!

if you don't want to help...don't

Actually it is true that all links seem to work just fine. Could you tell us more?

Vegasgirl,
I would truly like to apologize for my comment. What I saw was a fully functioning fully loaded e-commerce website and got the wrong impression based on just a link and no other information. Please accept this old man's apology.

Hi Thomas, this happens to be a legit question from one of my clients. You hurt her with your remark.

The website she is pointing to is NOT a commercial website where you can buy something whatsoever.

Please do your research before you attack people on this forum.

She is new to concrete5 and this community - please treat her with respect!

Thank you!

I'm sorry but I went to the site following the link and what I found is a fully operational e-commerce website and didn't see any link on the page that resembled "my recommend this page" box. If she gave us some detailed information so we would know what we were looking at and looking for other than just a link to commercial website, it wouldn't look so much like a spam. I get literally hundreds of spams a day and I've tried everything to slow them down so I have little respect for spammers. Again, I am deeply sorry for my comment. I first looked for a link to privately report spam on the forums but couldn't find one. I would have reported it quietly if there was a method to do so.

Lastly, I would like to help if I could see anything that needs help.

By the way; I went back to the website and took yet another close look. True, at 3rd look, I see there is no actual e-commerce being performed on this site but it is a fully functional Commercial enterprise promoting business.

I accept your apology ...thank you very much!!! means the world. I wish you to have a great day !!

the good news my brilliant programmer Alex solved the problem :)

Don't worry. There is a 'Report as Spam' link available to members who have reached 'Community Leader' status. We report spam all the time and this one didn't look like spam to those folks charged with this responsibility.

thank you for clarifying. I was able to solve the issue by implementing proper og tags and double checking the linkedin and facebook plugin codes - all working fine now :-)

Nice to meet all of you

Thank you Alex my hero