Jacques1

No, because when the browser accesses the URL “https://yoursite.com:80/”, then it actually tries to connect to your server over TLS on port 80. If your server doesn't support TLS on port 80, the connection immediately fails. The Apache rewrite engine cannot do anything about that. It cannot travel back in time. You have to fix the application. Find out which component adds port 80 to the URLs and change that. The port shouldn't be there anyway.

Can you be a bit more specific than “doesn't work”? We're not clairvoyant. Does the application crash? Do you always see the dialog? Do you never see the dialog? Is the cookie set in the browser? You're using a short PHP tag at the bottom: <? This should be avoided, because it requires a special setting in the PHP configuration. Use standard tags at all times. You should also consider setting and checking the cookie with JavaScript to avoid this kind of PHPHTMLJavaScript spaghetti code altogether.

Then use the ID from the URL. Not from the database. The URL. As in: $id = mysqli->real_escape_string($_GET['tour_id']);

Then obviously $row['id'] is not what you want (wherever it comes from). Why are you not using the ID from the URL?

Passing the ID via the URL is perfectly fine. I'm talking about your query. You said there's a problem when you add a WHERE clause with the ID, so I'm interesting in what the ID actually says: $id = mysqli_real_escape ...; // inspect the content of $id var_dump($id); You can also just echo the ID. Anything that puts it onto your screen. I don't think this is “jargon”.

Unfortunately, we're not clairvoyant (even though that would definitely be useful for a lot of questions). So what does $id actually say? Is it what you think it is? Where does it come from? Oddly, you seem to take it from the result set of some other query when it should come from the URL paramaters according to your description. Besides that: You say you prefer mysqli, but you have not really bothered to learn it. mysqli supports prepared statements, there's absolutely no reason to rely on obsolete and fragile manual escaping. There's also no reason to check the number of rows before the fetch loop when the fetch loop itself already does that. You don't seem to have any error checking. And you should not mix the procedural mysqli API with the object-oriented API. Pick one and stick with it. This kind of shows why we recommend against mysqli. It's obviously too complicated for the average programmer.

Yes, yes and yes. I don't instantiate an interface. I call the send() method of an object, and that object is an instance of a class which implements the MailSubmissionAgent interface. For example: <?php // create an instance of a class which implement MailSubmissionAgent $mailSubmissionAgent = new PHPMailSubmissionAgent(); // create a registration object, passing the mail instance to the constructor $userRegistration = new StandardUserRegistration($mailSubmissionAgent); // now the registration object can use the mail object $userRegistration->register(...);

No. Again: Object-oriented programming is about objects. Objects are entities like a user, an e-mail or a database. They're not actions. So when your class names start with verbs, there's something wrong. You should not create a new object for every tiny task. Then you essentially end up with procedural code where functions are masquerading as objects. You need identify sensible entities and represent those with objects. For example, the entity responsible for sending e-mails would be a mail submission agent. So you create an interface and a class for a mail submission agent: <?php interface MailSubmissionAgent { /** * Sends an e-mail to a single address * * @param $from string the sender address * @param $to string the receiver address * @param $subject string the mail subject * @param $body string the mail body */ public function send($from, $to, $subject, $body); } <?php class SMTPMailSubmissionAgent implements MailSubmissionAgent { private $host; private $port; private $username; private $password; public function __construct($host, $port, $username, $password) { $this->host = $host; $this->port = $port; $this->username = $username; $this->password = $password; } public function send($from, $to, $subject, $body) { // TODO: Implement send() method with PHPMailer or any other library. } } Whenever a class needs to send e-mails, it uses some implementation of MailSubmissionAgent (like the STMP one): class StandardUserRegistration implements UserRegistration { private $mailSubmissionAgent; public function __construct(MailSubmissionAgent $mailSubmissionAgent) { $this->mailSubmissionAgent = $mailSubmissionAgent; } public function register($username, $password, $emailAddress) { // ... $this->mailSubmissionAgent->send('info@mysite.com', $emailAddress, 'Your registration', '...'); // ... } } The point of having two objects is that the details of sending an e-mail are completely up to the MailSubmissionAgent and have no bearing whatsoever on the user registration. You can change the mail class, you can add new mail classes, you can delete existing ones. At no point do you have to touch the registration procedure. And that kinda makes sense. The same can be done with the database. Why should the registration procedure depend on the storage system you happen to use? This is a completely unrelated task which should be managed by a separate entity. It's like a company where the jobs are strictly separated. Creating the GUI is up to a designer, planning and maintaining the database is up to a DBA, writing code is up to a programmer. Everybody performs one specific task, and the exact details are their problem. The project manager doesn't care whether the programmer uses PhpStorm or Netbeans to write the code. They just want the result.

Yes, because a method named like the class is the constructor in older PHP versions and many other languages like Java. Class names should also be nouns, not verbs, because they represent objects, not actions. And repeating the information from the class in a method is redundant. It's fairly obvious that BasicEmail::send() will send a basic e-mail. Using BasicEmail::sendBasicEmail() adds no clarity, just clutter. The user registration should not have an e-mail method. It may be the case that some implementations send e-mails around during the registration process, but it makes no sense to have this method as part of the external registration API. It also means somebody else (who?) is responsible for triggering the e-mails. “ProcessEmail” also suffers from the verb problem. Object-oriented programming is in fact about objects. In this case, you could either have a mail submission agent as an object. Or an e-mail itself. Like I said above, the MySQL-specific features should not be part of the registration workflow, because those aspects aren't related in any way. Generating tokens or sending e-mails has nothing to do with whether you use MySQL, MongoDB or plain files to store your data. Passing objects to other objects can be implemented with depency injection.

I wouldn't make that assumption. And I don't think this is what benanamen meant.

Because your interface is not generic. The documentation specifically says it's for user registration, and the register() method has parameters for personal data. None of this would work for, say, registering a company. It's perfectly reasonable to have an interface for user registrations, but then the name should say that. Alternatively, you could in fact write a super-generic interface for any kind of registration, but this will look very differently. Yes. A class, an interface, maybe a group of classes. Anything that manages the database-specific tasks. If it's an associative array, yes. It could also be some other object representing just the user data, but that's probably overkill.

What are you seeing on the screen when the mail has been sent and no redirect happens? Or more importantly, what does the page source look like? The code looks strange, to say the least. Are the missing PHP tags around the mail code a copy-and-paste error? Why are you printing error messages on the screen? This is a terrible idea on a public site, and it will indeed break header() calls. And why do you use output buffering?

By the way: When you have so much trouble understanding the result set, print it. Do you have phpmyadmin or some other administration tool? Execute the query with an example ID and look at the result.

You keep trying to select columns that don't exist. There is no “avg” in the result set, just “AVG(price)”. If you want “avg”, you need to create an alias: AVG(price) AS avg

The names are very confusing. “Registration” sounds like this represents any kind of registration, not a user registration in particular. At the same time, “UserRegistration” sounds like a very generic implementation of a user registration which supports arbitrary storage engines, data structures and whatnot, but it's actually an ultra-specific representation of your current setup (MySQL, PDO, a table named users with particular columns etc.). The interface should be name UserRegistration, because that's what it is. Then the class should name indicate the implementation specifics. The purpose of the interface/class is too broad and too unspecific. It performs all kinds of unrelated actions like generating tokens, storing the data, sending out e-mails etc. If just one of those components change, you have to rewrite the whole class. At the same time, the method does not, for example, do any kind of validation, which is appearently supposed to happen somewhere else. You should split the vague task of a user registration into smaller, specific tasks. For example, the exact storage implementation has nothing to do with the registration workflow, so it should be put into a separate database-specific component. The parameters of register() are too specialized. What if you want to store additonal data like the user location? Then you have to change the whole interface as well as every single implementing class. You can avoid this if you use more generic parameters like $username, $password and $additional_data. I think the main problem right now is the lack of abstraction and modularity (which is normal for your first OOP designs). You've essentially taken the procedural code from classical PHP scripts and put it into methods. This works, but it doesn't take advantage of the strenghts of OOP. It might make sense to start with smaller tasks. Building an entire OOP web application from scratch is tough and requires a deep understanding of design patterns as well as a lot of experience. It's not something you would do as your very first project.

With attempts like this, you're just making a fool of yourself. And the queries are so hopelessly wrong that you'll sooner or later have to write them all over again. So you have shell access to your server containing the PHP application, right? And the application obviously contains the database credentials. Extract them, connect to the database and start digging. If the database is publicly reachable, you can even use your favorite admin GUI on your PC.

Um, what? You obviously have some form of server access, so what exactly prevents you from actually learning the database structure?

This is your fifth(!) reply, and you still haven't managed to provide any relevant information. All you do is keep repeating that the .php URL works fine. Then maybe you should give up the whole SEO stuff and go back to classical URLs.

One last time: How -- does -- the -- full -- URL -- of -- the -- delete -- action -- look -- like? When you click on the link, you end up with a URL (which should contain the three parameters). I want that URL. Not the cart URL. The final URL which is supposed to trigger the action. If you can't see the URL due to redirects, use the developer tools of your browser. Secondly, the Apache documentation says that you need the QSA flag to make URL parameters survive the rewrites. Are you doing that?

Read the code. The script expects three URL parameters: del, rid, and pos. If the parameters aren't present, nothing happens. That's simple logic.

So what happened to the URL parameters? Then security vulnerabilities and defects aren't a concern, of course.

Many things can be done, but this is clearly a job for a programmer, not something we can answer in this forum. I can move your thread to the job section, if you wish.

This is far too vague. How does the full SEO URL look like? How is it resolved? Which parameter are you receiving in the script? var_dump($_GET); Besides that, using GET requests to change data violates the HTTP standard and leads to security vulnerabilities. For example, I can delete products from the cart of any user simply by making them visit a page with an image while they're logged in: <img src="http://yoursite.com/cart.php?rid=x&del=1&pos=y" alt=""> The browser makes a GET request to the URL in an attempt to load the image, and that alone is enough to trigger the action. This is a rather harmless case, but if you use this pattern consistently, you're definitely in trouble. You need to make POST requests with an anti-CSRF token.

The name doesn't suggest anything about the implementation. In fact, there's something wrong if it does. In interface specifies methods. It doesn't say how or by whom they're implemented. There can be many different implementations, and that's the whole point.

If technical discussions hurt your feelings, maybe you should avoid them in the future.