I'm currently working on an in-house CMS and have come to a bit of a standstill. I'm trying to make it easy to paginate between pages of posts in a blog, and can't decide on how it should be tackled. The real problem only arises when I need to allow a user to choose how many results to display per page or the order to sort posts in.
My initial thought was to simply use a querystring: blog/?page=3&count=20&sort=date but I'm not sure whether this method will have adverse effects on SEO.
For example, is Google sensible enough to realise that blog/?page=3&count=20 is the same as blog/?count=20&page=3?
I then thought about using sessions, but again this does not solve the problem above, and possibly makes it worse as some users may not have cookies enabled.
Lastly, I'm already using mod_rewrite for some of the urls, would it be best to use a structure like this: blog/1/20/?
I could really do with some help/suggestions here, there doesn't seem to be a hard-and-fast way of paginating results.
Thanks in advance
As long as those query strings are present on the links on your site (via static, normal 'paging' links which are spiderable) there shouldn't be any adverse effects. If your paging happens via sessions, however, that could have an impact, as that's usually done via cookies or by a long query-string propagated session ID. As far as I know, the order of parameters does not matter, as long as they yield the same output from the server.
The simple GET query string paging method works nicely. Google does it too (e.g.: q=test&start=10&...), the point is to make sure everything is reachable via plain-vanilla anchors.
Avoid using querystrings if you plan your site to get crawled satisfactorily.
Instead, use mod_rewrite and queries like this:
blog/page:3/count:20/sort:date
That will make it more readable, while keeping querystrings out of the way.
Of course, you'll have to parse that before doing the actual query, but it's something fairly simple to do in PHP: using explode() you separate each part of the URI, then parse from there.
Consider not having the order of the parameters fixed, instead allow them to be swapped and omitted, which will give you more flexibility when building the links.
I have always done this with session variables that get set via ajax calls.
I set an onClick event for each column header, and wrap the contents of the page in a div, so I can replace it.
I don't want Google downloading 10 different versions of the same page anyway.
On your comment about session variables:
I then thought about using sessions, but again this does not solve the problem above, and possibly makes it worse as some users may not have cookies enabled.
Session variables are stored on the server and not the client, so disabling cookies does not affect session variables.
Session variables are probably the easiest and most reliable way to solve this problem if you want to avoid google duplication issues.
Related
Using the jQuery load function, i made it to where only the body of the website loads/changes. My header stays the same.
Rather than accessing your database, say, 50 times and requesting the same information on different pages, could I just risk a longer original loading time and include a php file that has everything i need stored in session variables for a user's account?
Are there any big security concerns for this or just any reason I am not seeing why this would be a bad idea?
I am finding myself accessing the same variables over and over again (like a unique id) on various php pages.
Sounds ok to me.
Consider if you need to synchronize and update the domain model (user account data) during access and want to resynch it to your client (view). What you describe however is common session behavior.
It sounds like you are doing it very low level, so you can go for this, without using a repository layer or dao or alike. Just read the date you need, be aware of concurrent access and ok.
For read only it is perfectly fine way of caching it.
It is a good idea imho. What else would you do besides a session, preferably via https.
Consider the security guidelines made here:
PHP Session Security
Yes, it is a bad idea:
Can a user alter the value of $_SESSION in PHP?
http://c2.com/cgi/wiki?GlobalVariablesAreBad
As the title says, is there another way to pass a variable from "current" page over to "next" (new HTTP request) page without using sessions/cookies/$_GET?
Well, I guess $_POST could be an option too, but the thing here is, that I want to pass this variable from already executed $_POST back to off-the-post environment page, but inbetween I'm having a redirect, to disallow reposting the same form.
In other words, basicly, I'm trying to "make" a seamless PRG, but sessions/cookies/$_GET is not an option.
And yes, I'm working with classes (hence the oop tag). Therefore maybe some kind of magic functions, or output control?
This has to work within PHP environment, no JavaScript or other non server side language.
I also have a bad feeling that it's impossible, but hopefully I'm wrong, and there is a solution.
Thanks in advance!
update no. 1
Basicly, I want to create a PRG with response.
Inside this $_POST I'm adding data to database. I want this response to hold information whether this database query has been successful or not. Kind of make this $_POST process almost invisible to the user. And yes, display a response with the result later on.
All of this happens in one method:
if($_POST){
// insertion
}else{
// display no-post environment, if response exists (therefore posted) display response too
}
Something like that...
Sessions is not an option because this is meant to be some kind of API.
update no. 2
Huh, let me rephrase the question a little. Well, it seems that I don't actually need to pass the variable over. What I want to do, is to have 2 different results after POST so on next page load I could know whether the actions in POST has been successful or not. So, what other options are out there without using sessions/cookies/$_GET to get this result?
Currently there is:
temporary database usage: a good option, but I'd like to see different options;
Since you're already using a database it seems like the easiest way to handle this would be to update some kind of temporary table with the information you want based on the post call, then on the page you're doing a header redirect to, read the information in that table. With the constraints you've placed on this (no GET, SESSION, Cookie or Javascript) you're not going to be able to maintain a variable when you redirect from one page to the next.
So leverage that database and take the work off of PHP. Initially I was going to suggest utilizing cURL but I don't think that will help here (though you may want to look it up if you're unfamiliar with it, as it might be what you're looking for)
HTTP is a stateless protocol; thus, there's not going to be an easy, built-in way to add state. That said, I think sessions are the best way to accomplish what you want to do. If what you're doing isn't in the browser, maybe try some sort of session key setup (like the Facebook platform uses).
I am syncing sessions between two different domains for Magento using a token passing technique with a remote iframe or img. I am about to implement it into Magento and was looking for some pointers.
I will have to do two things:
Every 5 mins, output an iframe or img with a remote SRC attribute for the second domain.
Q. Where is the best place to implement this? In the past I did storewide actions by overriding the renderLayout() method in Magento. Should I just do it by appended a block to the end of the page load? If I use a block, is it still keeping MVC?
I need to sync the session on the other domain when the script is called. I need to set the same cookie that Magento would set, that links to that session for the user.
Thinking about this, I think I am going to have to load Mage::app or whatever the call is that loads the Magento environment.
Q. Is there a lighter way of doing this?
Just for better understanding of what I am doing, here is a quick description of the flow.
User goes to Site A. If its time to sync the sessions, an IMG or IFRAME is outputted with SRC pointing to site-b.com/sessionSyncer?token=SHA1TOKEN
sessinSyncer validates the token and if so, creates a session and sends the cookie to the browser for the session. This should happen in a Magento manner
I am aware that Magento has the ability to pass session through the URL and generates the links to do so, but this is inadequate because the user must only switch sites using those special urls, plus the URL becomes ugly.
Thanks in advance!
Overriding renderLayout is overkill. Instead create a block that outputs your img tag and include it in the base theme, perhaps for the area before_body_end, that will safely place it on all pages.
Inventing your own token is also overkill since Magento is using the PHP session identifier and places it automatically for foreign domains. Your custom block might generate the URL with this:
$this->getUrl('OTHER/STORE/PATH', array('_store' => 'YOUR_STORE_CODE'))
If you think your script is going to need Mage::app() then you might as well use a controller which is a similar effort. On encountering a SID value the session will be updated behind the scenes, cookies set etc.
It using an iframe it doesn't need to output anything and if a small image can be static like this:
print "GIF89a\1\0\1\0\x80\0\0\xff\xff\xff\xff\xff\xff!\xf9\4\1\n\0\1\0,\0\0\0\0\1\0\1\0\0\2\2L\1\0;";
P.S.
When creating the URL of the foreign store without an SID use the _nosid parameter to force a clean URL.
Store sessions in DB and replicate database tables or entire databases it's much easier. You can configure that in your local.xml
<session_save><![CDATA[db]]></session_save>
UPDATE!!
I am sorry for this post, the code I had written for this prior to posting wasnt working and I had run out of ideas, only to then have a 5 minute break and came back to it only to realise I had accidently changed the $_GET to a $_SESSION without realising and thus rendering the script useless :(
Lesson learnt? to have breaks now and again and look through my code efficiently before wasting stockoverflow's users time :)
I am looking to script into a site a language function, the site will have 3 language options; english, korean and brazilian.
I have tried building this from scratch for the past day, first using javascript/jquery/ajax with php and secondly with simple php $_GET.
I was hoping to succeed with the former attempt as I dont really want to mess about with the URL as im using mod re-write atm and cant be bothered to mess about re coding the new URL.
So what I am hoping for is some help in picking the best way in which to create a language system, remember I would rather not use URL $_GET if at all possible.
I would also like the users choice to remain as they navigate the site using php sessions which I have tried to use but have come unstuck.
I have not placed any code in this post as atm I am looking for some tutorials or some guides on how to do this. I may add code later if there is no solution.
Thank you in advance
Dan.
IMHO you should put this into the URL. If you select the language depending on a setting in a cookie or session data, it's very confusing, because the same URL will produce different contents, which is very bad for example when proxies cache your page or search engines index them.
The usuall way is to put the language in the path of the URL instead of a GET parameter (http://www.example.com/en/, http://www.example.com/ko/, http://www.example.com/pt/ or http://www.example.com/pt-BR/).
You can store selected language in the cookies or session. If you have any problems - don't hesitate to ask.
I want to store the page location the user came from (on my site). I want to do that for this example: say someone sent a comment without being logged in. "process_comment.php" will process it and send a header(location:$_GET['prev_page']); Of course I'm gonna filter $_GET before sending it.
Should I use a session instead?
Thanks!
It is actually exactly the same. Both methods imply that the information is passed in the HTTP query, which can easily be forged. So you can't really trust one method more than the other.
That being said, as long as you don't rely on that information for something really important, you can admit that the referer can be trusted, because it's a little bit more complex to forge than a querystring parameter. At least for the average user.
The best solution, if you need to trust that information for something important, would be to store it on the server, as a session variable for instance. Each page would store its URL, after checking what the previous value was.
If you use $_SESSION, there will be trouble if the user has multiple windows/tabs open and does different things at once. There is nothing more annoying than being able to only have window of a site.
You could store the value in a SESSION variable and identify it by a short key. That key goes into the GET string. That way, you can keep your URLs clean, and you don't risk hitting the 1024 byte limit many servers have for GET parameters.
Well, the HTTP_REFERER can be stripped out by some clients.. I seem to remember some Norton Internet security products did that, probably others do too. So it is going to be more reliable for you to set the previous page in a session and use that for redirecting.
If you can use it, session is a safer option. Sending user back from GET or even headers will allow crafty people to possibly abuse any flaws in your code to possibly do nasty things.
The header itself may also be removed by some firewall software.
I don't think there is a problem with using GET in this case. You can't always depend on being able to retrieve the referrer from the browser.