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.
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 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.
My website allows visitors to search for homes (using PHP and MySql). After the search, they are presented with a list of matches which they can click on to see the detail page for that home. To see the next home, they currently have to click back, then click on the next home in the search results list they want to view.
I would like to make it so that once they have clicked on one home to view the details, they would have a "Next Home" and "Previous Home" link/button to use to navigate the results set without having to go back to the search results page.
I've seen this done, but can't get my head around how to do it. I assume you have to save the recordset from the initial search somewhere, and then recall it on the details page. And you'd have to know that you were looking at the xth home out of Y homes.
Can anyone give me a broad overview of how this would work? Do I save the initial search results in a temp MySQL table and pass that table name to the details page? Or use a session variable to hold the results set? Keep in mind that a visitor could make several different searches during their session.
Any assistance would be most appreciated,
Tom
When I've done this, I've saved the details of the current search in SESSION, and then requeried the database when I've needed to - so you can query it on the detail page to generate a Next and Previous link, and so on. I normally use a SESSION variable called 'parameters', and add the whole of the SQL WHERE statement to it.
If someone's making multiple searches, this will let them make one at a time - subsequent searches will over-write what's already in there. If your users are going to be making multiple searches at the same time using different parameters, you'll need to find a way to differentiate the parameters for each search. You can give each set a unique name by prefixing it with a call to uniqid, and you'll then need to make sure you pass the unique identifier to the detail page, so it can work out which set of parameters it needs to run.
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.
I have completely no idea where to start so I apologise about the lack of code presented to you.
My problem is - I have a page of information, ordered by ID (gathered from the database). These ID's are referenced from another page to which the user clicks on a link and it takes them to the page with the information on, how ever, there could be potentially hundreds of ID's on that page - So I need to reference each specific ID so when the user clicks, it will take them to the exact position of the ID.
I understand its something like localhost:8888/index.html#id3 etc..
But i'm struggling to understand how to reference for a PHP Variable.
Many thanks in advance.
You would use anchors, so for example, on the page where you list your information, attach an anchor to it such as #id1, then on your links page, you would place the #id1 at the end of the url results.html?#id3