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.
Related
This is probably a dumb question. I have a Web site that uses php and html with a bit of Javascript. I am trying to set it up so there are multiple landing pages. I think it would work if all the remaining .php files on the site were kept identical but there were separate index_a.php, index_b.php files, etc. The only problem is when the user clicks "Home" they of course get the root index.php. Is there a way to store the name (or some other indication) of what the user's landing page was for that session (using PHP session variables or I don't know what) and have the user directed to that page again when they click Home ?
Any help would be much appreciated (keeping in my mind I am a relative newby and any solution would need to be pretty simple and safe to load on a server). Any straightforward way way to do this ? It must be something that is fairly commonly required.
Short answer: yes
Smart answer: use a (mvc) framework of some kind which implements views and routes everything through a front controller.
Quick and dirty answer:
// anywhere
session_start();
$_SESSION['landing_page'] = 'landing-2.html';
// in your index.php
session_start();
include $_SESSION['landing_page'];
Note: if you use the code above, be sure the torn of the security gods will fall upon you.
I'm new to PHP and I'm curious as to how you generate pages on the fly?
I have a table of users that I'm pulling from my DB and displaying on my homepage and that I know I can pass their user ID as a POST variable to 'mysite.com/profilepage.php' and then have a query on that page that would pull all relevant information for that ID, but say I wanted the page to be 'mysite.com/user-profiles/john-doe.php' ?
Would this be done with a .htaccess file? Any help is greatly appreciated!
If you must have the page be called mysite.com/user-profiles/john-doe.php, you can use URL rewriting as mellamokb mentioned in the comment to change the URL to that.
But as far as PHP is concerned, the way to do this is to create a PHP page (I'm going to suggest user-profiles.php), and then pass usernames to it with either GET or POST. Assuming that you're only reading and that the information in question is public, GET seems fine and it's easier to explain here.
You access the relevant page (generated "on the fly" by PHP) by pointing your browser to user-profiles.php?username=John-Doe and including code like this in user-profiles.php:
if ( isset($_GET['username']) )
{
$username = $_GET['username'];
// you now know the passed username
}
else
{
// some kind of error handling for when there is no username
}
You now know you have the relevant username within your PHP file, and can use it to create the page as you want it. You can also use URL rewriting to change user-profile.php?username=John-Doe to user-profiles/John-Doe if you like.
WARNING: Do not use $_GET if the page in question is either going to be modifying the database in any way, or if it's going to be getting private information from the database. It is not in any way secure. Please read up on PHP security before creating pages that do either of those things.
If you are new to PHP and havent looked at any frameworks, have a look at the agiletoolkit. It does some neat integration between jquery and php which will give you a nice look and feel to your pages. It also encourages you to use ModelViewController (MVC) to segregate the parts of your code that are for database access and functionality from those which are purely for web page layout.
The options for URL rewriting mentioned above are the same but when a user is logged in, you have access to the user information from $this->api->auth('xxx') where xxx is the column in the users table.
The framework takes a little bit of learning but so does PHP and it's easy to get into very bad habits writing PHP code which means as the websites get bigger, you will find it harder to maintain your code.
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'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.
I've got a website that has a form that the user can type in. I want it to be the replacement for a 3rd party website (Autotask) form with the same fields. Normally I'd just have the action in my form go to where the 3rd party's form points and then have all the same id/name values for my own fields, but there are several problems with this:
Autotask's forms aren't just simple muli-field forms. They import at least 15 Javascripts that make something magic and unidentifiable happen, and they are incredibly difficult to read and understand. So that causes two problems, one that the form takes a very long time to load (5 seconds or so for 4 fields), and two is that if Autotask changes anything at all I'll need to redo the whole form (very tedious and crapshoot-y, and I already have needed to do it twice).
In order to make the load time more transparent, I put my copy of the Autotask form within an iFrame. That way the rest of the website can load separately from the expensive number of scripts I've got to include with Autotask's logon process.
Ideally what I want to be able to do is to just have those 4 fields on my site with whatever name and configuration I want, then send that POST data to my own PHP script, which will automatically (and transparently) submit that data directly through Autotask's forms in the proper fields. If I need to make the id/name match, that's okay. I can use HTML, Javascript, and PHP on this site.
EDIT:
Autotask has built-in GET handlers for their logins. You'll notice that you have a client ID at the login (it will be the "ci" variable in the URL). If you send a GET request with the client ID there and variables for "username" and "password," then it Autotask's login page will immediately forward you to the client page, given a successful login.
I think a lot of people would advise against this in general, as you're kind of hacking the functionality of someone else's app. In this case I only advise against it because they (Autotask) have an outward facing API already. http://www.autotask.com/press/news_and_press_releases/071006.htm I think that you'd be better off just utilizing it and developing something that functions pretty well within the constraints of their system.
one really round-about way of doing it is have your page load a form with some generic id/names. have a php script that scrapes their page for the correct id/names, and the ajax them into your forms.
That way you avoid having the load time of iframing their content in, or scraping their page on your initial page load and they change the id/names you'll always have it up to date.
I could write up a big post that explains on this, but really I think this is a perfect time to let someone else's words do the work.
Autotask's forms aren't just simple muli-field forms. They import at least 15 Javascripts that make something magic and unidentifiable happen, and they are incredibly difficult to read and understand.
Sounds like anti-spam measures to me? If so, then they will probably change over time.
So: follow NateDSaint's advice!
As a follow-up, it turns out that with Autotask they have GET handlers so you can just send information via GET. Problem solved.