Develop Reference

Google Tag Manager - Capture domain on first page load in variable

I have a situation where there is the same GTM container on six different domains. The user can potentially land on any of the six initially, but there are multiple user paths that can take them to one or more f the sites before making a purchase.
I need to know which website the user landed on first
I thought I could simply use a custom dimension set to page host, scoped to session. But in testing it looks like the last value is passed with the ecommm purchase tag vs the initial value set in the session.
So I am trying to use a custom javascript variable. I want to have it set an 'originSite' variable to the {{page hostname}} IF that variable was not previously set.
function () {
var originSite;
if (originSite == '' || originSite == null ) {
originSite = "{{Page Hostname}}"
return originSite
} else {
return originSite
}
}
But when I click over to another domain, this returns the new page hostname vs keeping it the same. So does declaring the var itself set this back to empty each time?
I also tried a DataLayer push that only fired once per session. But even with cross-domain set up for all the different sites, this is firing the first pageview of each domain. :(
Any assistance or suggestions would be appreciated...I'm struggling to solve this.

Re-declaring the variable is not the problem here, rather just a poor design. The problem is that JS context is wiped on page loads.
You want to preserve your variables explicitly if you want them to carry over through pageviews. The most common way to do so is via storing the values in cookies. People also use local storage, session storage, backend or even web sql for preservation.

Alternative to passing Data to JavaScript from PHP?

I have a fairly large Application and I'm currently trying to find a way around having to pass Data from PHP (User Tokens for 3rd Party API's and such) through the DOM. Currently I use data-* attributes on a single element and parse the Data from that, but it's pretty messy.
I've considered just making the contents of the element encoded JSON with all the config in, which would greatly improve the structure and effectiveness, but at the same time storing sensitive information in the DOM isn't ideal or secure whatsoever.
Getting the data via AJAX is also not so feasible, as the Application requires this information all the time, on any page - so running an AJAX request on every page load before allowing user input or control will be a pain for users and add load to my server.
Something I've considered is having an initial request for information, storing it in the Cache/localStorage along with a checksum of the data, and include the checksum for the up-to-date data in the DOM. So on every page load it'll compare the checksums and if they are different (JavaScript has out-of-date data stored in Cache/localStorage), it'll send another request.
I'd rather not have to go down this route, and I'd like to know if there are any better methods that you can think of. I can't find any alternative methods in other questions/Google, so any help is appreciated.

You could also create a php file and put the header as type javascript. Request this file as a normal javascript file. <script src="config.js.php"></script> (considering the filename is config.js.php) You can structure your javascript code and simply assign values dynamically.
For security, especially if login is required, this file can only be returned once the user is logged in or something. Otherwise you simply return a blank file.

You could also just emit the json you need in your template and assign it to a javascript global.
This would be especially easy if you were using a templating system that supports inheritance like twig. You could then do something like this in the base template for your application:
<script>
MyApp = {};
MyApp.cfg = {{cfg | tojson | safe}};
</script>
where cfg is a php dictionary in the templating context. Those filters aren't twig specific, but there to give you an idea.
It wouldn't be safe if you were storing sensitive information, but it would be easier than storing the info in local storage,

number of reading text in web page with javascript

how to found how many times a news(for example)are read in website?
<p> <!-- my news--></p>
var counter=0;
windows.onload=function() {
counter++;
}

You can't use a JavaScript variable to hold your counter. Each time your page loads this variable is reset to 0.
You need to store the information somewhere, such as a database or in a file on the server. You can't store information like this inside your code.
Look into MySQL databases and PHP.

Your own server's logs can tell you how many times a page has been loaded, and that's a far easier approach than using JavaScript. If you absolutely have to use JavaScript, you'll need to use Ajax (or something) to communicate the result to the server.
Really, Google Analytics is the right tool for this job.

How to achieve the role played by "public static variables of Java" in JavaScript or a webpage?

On my homepage I have to set a cookie using the name of the logged in user. The cookie set and get part has to be done in JS. On the subsequent sub pages I have to retrieve the cookie(username) using the set variable name.
How can I store the username/cookie name so that it is publicly accessible across all the pages? This username will obviously change with each new user and is not constant.
I have tried doing this using external JS file but in every new page the value is reset to default which I don't want.
The exact solution to my problem is like the work done by:
public static variable
in Java (not final). I want to achieve this in JS.

There is no such thing in Javascript unless you use a storage API (client side storage, or cookies, or something like that). The reason is that when you move from one page to another, it doesn't particularly matter to the browser. It wipes its slate and starts over, keeping explicitly stored data like cookies and such, and deleting everything else that is dynamically created. So the short of it is, if you want each page to know the name, you have to include the name in each page's code (manually or via script).

I don't quite know your application. In javascript you have function prototypes. In a function prototype you can declare 'static' members like so:
function C(params for constructor){
C.aStaticVariable = 5;
}
alert(C.aStaticVariable); //available everywhere

Can JavaScript survive a full HTTP Request Roundtrip?

Is it possible to have JavaScript (specifically, JavaScript variables and their content) survive full HTTP requests? I'd like to 'cache' / persist information client-side across page changes, without having to use hidden form fields or anything HTML related at all.
Is this possible?
Edit: Let me add a use case for what I mean.
Let's say I have a JavaScript array
called arrayOfPersons which I
loaded as part of page /HomePage,
and now it contains 1,000 objects
client-side.
Now the user switches the page and
loads an entirely new page /MyAccount into the
browser
My Goal: Still have the arrayOfPersons that I loaded on page /HomePage available after the user requested the entirely new page /MyAccount.
Hope that clarifies what I mean. Thank you!

Just to add to Nick's answer, different browsers support the idea of persistent storage in one form or another. There have been a bunch of efforts to normalize these for all browsers over the last year.
Here's one library that wraps around HTML 5's DOM Storage, Microsoft's UserData, Session Cookies and window.name (using JSON serialization as window.name can only store strings).
Here's another that focuses on window.name only (which actually works in Opera 9+, IE6+, Firefox 1.5+, Safari [3 I think).
Here's a jQuery plugin that uses a .swf (flash) file to offer the most cross-browser support (although it does support native solutions if you configure it to do so). I can't vouch for it but it should be mentioned for this jQuery-lovin' community.

Yes it is possible. Its a bit of a hack i used to maintain the page state(in client side) throughout the entire session.
Have a base page (like master), that never refreshes through out the session and it only got the iframe within it. And all your application pages will be loaded in to that frame..
Store your state info into that master page as JS objects. And you can access the master page (parent) javacript objects from your child page in a iframe. And it ll be maintained through the session in client side.
This is the simplest way. And it works pretty neat.

Found a useful one
JSOC: JavaScript Object Cache
The JSOC framework is a a pluggable,
extensible, open source client-side
caching framework for JavaScript.
JSOC offers Web developers a
straightforward way to perform common
caching techniques (add, replace,
remove, flush, etc.) inside any
JavaScript-enabled browser.
Since JSOC is a standalone JavaScript
module, incorporating JSOC into a Web
development project is a matter of
including a script reference, and
working with common caching methods.
Low-level methods are contained in the
JSOC JavaScript module so that
developers can focus on the Web
development task at hand.

Newer browsers support DOM storage which let you store arbitrary data that can persist between pages. You can also use a hidden Flash app to remember things. There are libraries like Dojo Storage which handle the detection for you, so you just save your data and it will use whatever is available.
It won't automatically save all your Javascript variables for the next page - you'll need to add an onunload handler to store what you want when the user leaves the page.

A frameset would give you a place to persist your javascript, but full page load... I think not.
Cookies might also be useful for "persisting" data, but this isn't what you asked.

if i understand you correctly, all you need is to add your own caching functions into onSubmit of all forms and onClick of all links, smth like:
var cachedpages;
$("A").onclick(function(){
url = $(this).attr('href'); // maybe hash?
if (cachedpages[url]) {
// replacing all html
} else {
$.get(url, function(data){
cachedpages[url] = data;
// replacing all html
});
}
return false;
});

One possibility is to use a frameset and keep the objects there, another to serialize them and persist the data via either of
window.name
document.cookie
location.search
document.cookie is the canonical way to store data between invocations of pages in the same domain and provides mechanisms to control access and lifetime.
If you use window.name, the data persists over the lifetime of the browser instance.
Using window.location is more tricky and you have to explicitly modify the links to send along the data (which can be easily done using event delegation).