JQuery on masterpage doesn’t work in child pages ASP.NET

asp.netjquerymaster-pages

Ok, so this is my problem.

i have this on my master page inside <head runat="server">

<script src="js/cufon-georgia.js" type="text/javascript"></script>
<script src="js/cufon-yui.js" type="text/javascript"></script>
<script src="js/jquery-1.4.2.min.js" type="text/javascript"></script>
<script src="js/script.js" type="text/javascript"></script>

The master page is in the same folder were the js folder is.

I have one solution with one Folder named Website, inside this is the masterpage and the folders with the scripts and css's.

The index page is at the same level than the website folder.

The jquery is being used for desing. I know this because i ran the template on wamp to modify, and if i remove the jquery scripts the page gets "uglier".

So, when i did all the modifications i wanted, i created the masterpage and inserted all the HTML code inside. But the jquery is not working. the page stays "ugly".

The css is working tough. and its in the same level of the jquery files. only in a diferent folder.

Ive reasearched a lot and tryed everything i could find.

ResolveUrl

Tryed to load from the code-behind.

changed the level of the master page and index.aspx.

body onload

with and without type="text/javascript"

tryed change the path ../, ../../, ~/ (long shots, i know)

Im out of options, help?

(im sorry if there is already an anwser, i couldn't find it…)

Best Answer

Proper way to use JQuery when using MasterPages in ASP.NET?

found the answer where, scriptmanager,

not the ideal solution, everytime we need to change one script we need to change in all pages, but it works...

Related Solutions

Jquery – Proper way to use JQuery when using MasterPages in ASP.NET

You would declare your main jQuery scripts within the master page, as you would normally:

<head runat="server">
  <link href="/Content/Interlude.css" rel="Stylesheet" type="text/css" />
  <script type="text/javascript" src="/Scripts/jquery-1.3.2.min.js"></script>
  <asp:ContentPlaceHolder ID="head" runat="server">
  </asp:ContentPlaceHolder>
</head>

And then any page specific JS files could be loaded within the Content controls that reference the Head ContentPlaceholder.

However, a better option would be to look into the ScriptManager and ScriptManagerProxy controls - these can provide you with a lot more control over the way your JS files are served to the client.

So you would place a ScriptManager control in you master page, and add a reference to the jQuery core code in that:

<body>
  <form id="form1" runat="server">
    <asp:ScriptManager ID="ScriptManager1" runat="server">
      <Scripts>
        <asp:ScriptReference Path="/Scripts/jquery-1.3.2.min.js" />
      </Scripts>
    </asp:ScriptManager>

Then, in your page that requires some custom JS files, or a jQuery plugin, you can have:

<asp:Content ID="bodyContent" ContentPlaceholderID="body">
  <asp:ScriptManagerProxy ID="ScriptManagerProxy1" runat="server">
      <Scripts>
        <asp:ScriptReference Path="/Scripts/jquery.fancybox-1.2.1.pack.js" />
      </Scripts>
  </asp:ScriptManagerProxy>

The ScriptManager allows you to do things like control where on the page scripts are rendered with LoadScriptsBeforeUI (or better yet, after by setting it to False).

Html – What’s the key difference between HTML 4 and HTML 5

HTML5 has several goals which differentiate it from HTML4.

Consistency in Handling Malformed Documents

The primary one is consistent, defined error handling. As you know, HTML purposely supports 'tag soup', or the ability to write malformed code and have it corrected into a valid document. The problem is that the rules for doing this aren't written down anywhere. When a new browser vendor wants to enter the market, they just have to test malformed documents in various browsers (especially IE) and reverse-engineer their error handling. If they don't, then many pages won't display correctly (estimates place roughly 90% of pages on the net as being at least somewhat malformed).

So, HTML5 is attempting to discover and codify this error handling, so that browser developers can all standardize and greatly reduce the time and money required to display things consistently. As well, long in the future after HTML has died as a document format, historians may still want to read our documents, and having a completely defined parsing algorithm will greatly aid this.

Better Web Application Features

The secondary goal of HTML5 is to develop the ability of the browser to be an application platform, via HTML, CSS, and Javascript. Many elements have been added directly to the language that are currently (in HTML4) Flash or JS-based hacks, such as <canvas>, <video>, and <audio>. Useful things such as Local Storage (a js-accessible browser-built-in key-value database, for storing information beyond what cookies can hold), new input types such as date for which the browser can expose easy user interface (so that we don't have to use our js-based calendar date-pickers), and browser-supported form validation will make developing web applications much simpler for the developers, and make them much faster for the users (since many things will be supported natively, rather than hacked in via javascript).

Improved Element Semantics

There are many other smaller efforts taking place in HTML5, such as better-defined semantic roles for existing elements (<strong> and <em> now actually mean something different, and even <b> and <i> have vague semantics that should work well when parsing legacy documents) and adding new elements with useful semantics - <article>, <section>, <header>, <aside>, and <nav> should replace the majority of <div>s used on a web page, making your pages a bit more semantic, but more importantly, easier to read. No more painful scanning to see just what that random </div> is closing - instead you'll have an obvious </header>, or </article>, making the structure of your document much more intuitive.