I want to track view count of a page from different page links, but not page reload or refresh.
I want to call this function when page viewed from various pages.
trackDifferentViewCount($Infos->user_id,'1','','1');
A "refresh" is yet another page request. It does not differ from a regular page view. To filter those out, you would need to remember the last page the user visited, and if that page is the same page, you do not count it as distinct visit. You can use the session or a cookie for this.
This does mean though that if a user closes the browser and loads the same page again later, it would still not count as distinct visit, even though it is. There's no 100% foolproof way to handle this.
Related
I have a couple of pages where the user can add and remove stuff in order to update the results. i.e. in a "ShoppingList"-page where the user can add/remove drinks in order to see what ingredients they need.
Each of these drinks is stored in a cookie, with PHP, so the user have the ability to navigate and explore the site, and then return without having to add the drinks again...
When the user do this, adds/removes drinks, the entire page is reloaded.
Drinks are added to a cookie immediately, before any html and stuff, then refreshed once again in order to build the php.mysql.query based on the values now stored in the cookie.
I think this is a lot of unnecesary reloading and stuff. It should be something more like just refreshing the actual content that needs to change, and not reloading everything else - Lots of unnecesary mysql requests just to add/remove a drink from the shoppinglist. And this of course slows site down..
Whenever the page is loaded, I need to check the cookie in order to present the correct results. Then, when a user adds/removes a drink, I would like to do this in the background (update the cookie and update the result). Hopefylly this could speed up the user experience.
I have a site up'n'running here - as a "prototype" : http://barkeeper.thomaskile.me/?side=handleliste (norwegian site, but google translate sort of gives you an idea of what it says. just tested it..)
This same thing goes for all three pages on my site so far..
Any suggestion on how to accomplish this? Is it som sort of jquery.AJAX-thing? If so. WHere do I start any sort of ajax-thing. Not sure how that works in practice when the user doesn't do anything (on page load)...
This is usually done by manipulating DOM.
Remove the element from one list and create it in another list.
Checkout jQuery - the javascript library.
I have run into a problem:
I have a page that will be processed many times a week by my customers and each time it will have a different identifier
example
compshop.php?Shopid=2252&sub=s
compshop.php?Shopid=2520&sub=se
compshop.php?Shopid=3152&sub=n
etc....
problem is if possible I don't want all of these to save to the persons history so every time they start typing my url these show as the primary result instead of my home page.
is there a way to stop this
I thought the cache meta tag would deal with this but it appears the cache tag is only for SE indexing
any ideas?
If you add a randomly generated parameter, it's extremely unlikely any page will be visited more than once, but your page can still be accessed by URL alone.
For example,
compshop.php?Shopid=2252&sub=s&t=69396872
compshop.php?Shopid=2520&sub=se&t=17094891
compshop.php?Shopid=3152&sub=n&t=79125863
It's not hiding the pages from the history, but it is mostly ensuring that the page is only entered into the history once, so your homepage should still show up first.
I think you're about out of luck unless you can send the parameters over POST instead of GET. As #PWHite just mentioned you could append a random value to the parameters as well to make sure that even the same Shopid/sub would show as "different" pages in the history, thus putting your home page at the top of the list in terms of # of visits.
The scenario (all happening within the administration area/backend):
From the listing page, the user clicks a link to view an article (on the backend).
From the article view page, the user clicks a link to edit that article.
In the article edit page, form is submitted to the current uri.
If validation succeeds or user cancels, user is redirected to the article view page.
From the article view page, the user click a 'back' link to return to the listing page.
List <--> View <--> Edit
Right now, I'm only able to track referring url from a previous page. In the edit form, I'm using a hidden field to maintain referral to the view page, lest it be changed during failed form POST submission to itself and user remains in the edit page.
Problem is that when the user returns to the view page from edit, the 'back' link to the listing page is now linked to the edit page.
FYI,
The listing page url is dynamic as the user should return to the listing on the same page and sort order (stored in query strings); therefore a fixed url is out of the question.
In the past, I've tried using sessions (e.g. SESSION['view_to_list_ref'] SESSION['edit_to_view_ref']), but it messed up with multiple tabs.
I could transition between view/edit via ajax, but I'm hoping to keep the app simple and ajaxless at this point of time.
I'm using PHP + Kohana 3.2 Framework
The only solution I can think of is to have the list page url encoded and appended to the 'view article' link via query string. This way, the location of the listing page is preserved even while in the edit page; as the referring url back to view page would also contain the listing page url in the query string. However I don't really like the idea of 'dirtying' the url with long parameter values (encoded or not).
I'm really hoping there is a more elegant solution to this problem of generally tracking multiple levels of page referrals; not just specifically to solving the scenario I've mentioned.
EDIT: Oh and the solution should be able to support multiple tabs performing the same scenario.
You could track the pages by using a unique identifying code in a PHP session, a temporary variable, and using a temporary database table that tracks page loads by these temporary values.
The database structure might be:
+-------------+-------------------+---------------------+
| Unique ID | Page Referral | Time of page load |
+-------------+-------------------+---------------------+
Tracking time of page load would allow you to selectively wipe loads older than X minutes, and keep the table relatively small.
Anyway, this would allow you to keep as many levels as you'd like, and if you wanted to add an auto incrementing counter field, or your own counter field, you could even keep a simple to use number system that tracks page loads, though I believe the time of page load would suffice for that scenario.
Lets say I have a Page with a List (list.php).
I click on a row on that list to Edit that record. I go to a edit.php Page.
I have 3 buttons on that edit.php page. Save, Apply, Cancel
Save button - Saves the Record and returns to the (list.php) Page
Apply button - Saves Record but stays on the same page (edit.php)
Cancel button - No save, just return to the (list.php) Page
But now image if I can access for edit that item on a different page. How do I return to that calling page?
Do I add a parameter(code) to the URL? something like a Page Origination Code?
Do I save the previous page URL in a session? (bad, they can right click open another page and that would be saved to session url)
Am just curious to how others return to a previous page after a SAVE.
you can the server variable $_SERVER['HTTP_referrer'].
They are other ways also you can store in session the current page and use is processing page.
Adding a parameter to the URL is the only reliable though quote ugly way.
That's why such an in-place editions nowadays often being implemented using AJAX, and this very site is a perfect example.
However, there are different cases.
Login page is imperfect example for example, as you always have a form instead of just a link, and thus you can always store the current page in a hidden form field.
Another approach is possible if you are using some sort of front controller, and all requests actually being directed to the single index.php file which runs appropriate script based on the URI.
in this latter case you will need no more than mere a redirect to the current page.
EXPLAINING WHAT I'M TRYING TO SOLVE:
I have a webpage (file_list.php) showing a list of files, and next to each file there is a button to delete it. When user press the DELETE button close to a certain file name, the browser goes to a script called delete_file.php that deletes the file and then it tells browser to go back to the file_list.php
delete_file.php uses a simple header("Location: file_list.php”); to go back to file_list.php
When browser goes back to file_list.php it reloads the page, but it DOES NOT scroll it back again to where the user was before. So let's say the user scrolled the files list and deleted the last file, when the browser shows again the page file_list.php it won't be scrolled to the bottom of the page again.
THE WORKAROUND I CAME OUT WITH:
I found a strange way to work around this, basically instead of using header("Location: file_list.php”); in delete_file.php I simply use a javascript call window.history.go(-1).
This workaround works perfectly when user is in session (simply using PHP session_start function): the browser RELOADS the file_list.php page and then scrolls it also back to where it was before.
But if the user is NOT in session the browser scrolls the page but IT DOES NOT RELOAD IT before, so the user would still see the file he deleted in the file list.
THE QUESTIONS
Do you know how to reproduce the behavior of the browser when goes back being in session even if we are not in session?
Do you know a way out of this, even another way of solving this matter?
Thanks!
I know I could use AJAX to delete the file so I would not have to go every time to delete_file.php, but this is not the answer.
You could emit anchors:
<a name="anchor1"/>filename_this
<a name="anchor2"/>filename_that
To delete filename_this, you pass the delete page filename_this and also anchor1. The delete page then redirects to file_list.php#anchor1
Note that the anchor names shouldn't map to the file names. That way when you delete the fifth file, the anchor is near the "new" fifth file (where the old one used to be).
Browsers generally remember where you were. If you go from page A to B, then go back (with the back button), you should arrive at the same place in page A.
When you use header('location: A.php');, you are instructing the browser to go forward to another page. It has never been there before, so it can't know what the scroll position was.
When you use history.go(-1), you are instructing the browser to click the back button, which is why your workaround works. You are likely emitting a no-cache header, which is why the browser is reloading the page. The effect here is the same as just reloading the page (without navigating). The trouble with this is that then the user can click the "forward" button, and arrive at your delete_file.php again (and may end up accidentally deleting another file).
Some ideas:
You can put a bunch of anchors on the page (one for each file), and redirect to the anchor that is closest to where the user clicked. So, if you deleted file 4, then redirect to file 3 header('file_list.php#file3');.
Compute the current scroll position in javascript, and store it in a cookie. When the page reloads, use javascript to scroll to where you were (making sure to only do this only once, it would be confusing to visit the page 3 days later and scroll to the middle for no particular reason).
You can also use AJAX to delete the file in the background. Here you are letting the browser deal with the scrolling. This might not be the answer you're looking for, but it's certainly a solution.
In my opinion, the best solution is the simplest: make your pages shorter. If your pages aren't long enough to scroll, then there's no problem.
How about submitting to an IFRAME? (no JS at all? you will not be able to hide the deleted entry...)
So to summarize, your steps are:
1) "a webpage (file_list.php) showing a list of files"
2) "delete_file.php that deletes the file and then it tells browser to go back to the file_list.php"
I'm assuming file_list.php only shows the current contents of the directory, which would obviously not include the file you just deleted. But you want file_list.php to somehow hint to the user something about the file they just deleted, like by jumping back to the position the file would normally be in the list had it still existed. There are probably several dozen ways to do this.
1) delete_file.php opens the url "/file_list.php#the_file_i_just_dele.ted". After you gather directory contents in an array, insert 'the_file_i_just_dele.ted' into that array, probably in alphabetical order or whatever. That array should have another boolean field: "deleted" => 1 | 0, which in case of the deleted file would be 1. While progressing through the array to echo the list, add a html anchor, which could simply be the filename, next to each list item. If 'deleted' is 1, don't echo the 'delete' button next to it. On page open, the page will jump straight to the 'the_file_i_just_dele.ted' anchor.
2) Use ajax.
3) Have a separate php library file for all your filesystem actions. file_list.php is the only page your client needs to see. On delete, file_list.php will post to itself with '#deleted' appended to the url, gather directory contents into an array, then delete the requested file, echo the array, and when your deleted file is encountered in the loop, disable or don't draw the 'delete' button and echo the 'deleted' html anchor right next to it. On page open, the client will automatically jump to the 'deleted' anchor.
4) Make a shopping cart and just not be concerned with this whole 'keeping track of where the user is on the previous page' problem. Have the user check off each file to be deleted. Use a cookie, DB, or session file to keep track of the cart contents if the "shopping" experience would span multiple directories and pages. User clicks a single 'delete' button at the bottom of the page. Add a 'checkout confirmation' page asking the user to confirm deletion of the listed files if you want to.
...etc...
You can also mix and match the solutions as you see fit.