schwim

It would be a good time to talk about what writing a PHP script consists mostly of, especially when new to it. Writing the code is actually the smallest portion of it all. You should be spending the majority of your time trying to break it and trying to exploit it. By breaking, as an example, you would try to input unexpected values in your form, leaving things empty, skipping processes, etc. You need to write code that recovers from things like this not just for the user's experience but for your protection. Exploitation is what's being discussed here. header injections, sql exploits, things like that can often be protected against just by using good code, good classes(like PHPMailer as an example, for mail capabilities) and utilizing built in features like var sanitation through PHP. It's cool if you don't understand what all this means yet but instead of writing an email form that can be exploited, you should be focusing on learning. Everyone being hammered by spam through your exploitable email form would thank you for it.

Since it was Personal Home Page and I'm still no good at it.

<td><img src="<?php echo $item["image"]; ?>" style="text-align:left; font-size:12px; font-family:TimeBurner;" class="cart-item-image" /><?php echo $item["name"]; ?></td> @benanamen is absolutely correct that your styles don't belong inline but I often do testing inline before moving it to my css file. If you're trying to add the style to your image, that's how you'd do it.

I would say for your needs, Wordpress would be most suitable. Joomla seems more suited toward forum community and massive cataloging type sites. Wordpress, on the other than, excels as serving informational pages out of the box. Of course, you can add extensions that provide forums, galleries, etc., etc. but it was born as a weblog software, so it's right up your alley. Another benefit of Wordpress is that there are literally thousands of themes for you to peruse and choose as a jumping off point for your project.

The site is a bit disingenuous. It's sort of like linux flavors; yes, there's thousands to choose from but most are abandonware, poorly coded and full of security holes and bugs. If you're into tinkering, that site would be a good starting point but if you actually want a CMS you can use out of the box, I'd stick with one of the well known offerings.

You would just retrieve role from the users table. If the role is user, forward to one page and if the role is admin, forward them to another. Additionally, you would need a role check on each page to ensure that the logged in user didn't manually visit a protected page.

Thank you very much for that. As a layman, I would have had no idea the scope of working with session storage and it's pitfalls.

The general rule is that you can never trust client input, so if you're thinking along that line of thinking and with your needs, it's going to be susceptible to exploitation attempts no matter what you do. They're either able to spoof session data, they can modify the form input carried over from a previous page or they simply find a way to move back a page when you didn't want them to. Since nothing was mentioned regarding why you wouldn't use SESSION in this case other than because PHP says so, I would still consider that a viable option for this example. I've used it for well over a decade and have never run into an issue that kept me from using it successfully in cases such as these. I would sanitize the input, store it and use it on the next page load, regardless of that page load is on the same page or a different one. It would require less coding and barring input from the others that are much more savvy than I at coding, I can't see a shortcoming to it.

Hi there Hansen, Your questions , while simple, comes down pretty much exclusively to how you like to learn something. My preference of digging in and learning a little bit at a time during a trial by fire via picking a small project or a tutorial found on the web and supplementing it by asking questions on a forum such as this may seem like folly to someone else that feels you need to read some books and take some courses. Looking at your site's code, it looks like you're just running a Wordpress site so most of what you're looking at would be done in web panel and when modifying it's PHP elements, would take a bit more circuitous route. Instead of modifying the PHP, there's some additional things to take into account being in the WP walled garden so learning how WP works and what it expects in code modules would be another thing to learn about. For your case in particular, I'd find out how your forms are being built, whether it's a Wordpress addon or something homegrown. Once you know that, you'll have a better idea of how to get started in modifying it.

If you want a more persistent login than solely relying on PHP sessions, save a random token to the db and store it in a cookie. If the user shows up in a different PHP session, check the token against the latest active stored in the db. If they differ, scrap all logins for that user and point them towards the login.

You didn't provide the form so there's no way to see what's being sent but you can do some print statements to see if that file is getting the data it expects: <?php ini_set('display_errors', 1); ini_set('display_startup_errors', 1); error_reporting(E_ALL); session_start(); require_once '../ayar/baglan.php'; if(isset($_POST['ekle'])) { print('POST data received'); $baslik = $_POST['baslik']; $icerik = $_POST['icerikici']; $yazar = $_POST['yazar']; $ekle = "insert into icerik (baslik,icerik,yazar) values ('$baslik','$icerik','$yazar')"; $sonuc = mysqli_query($veri,$ekle); } if($sonuc) { header("location:yonetim.php"); }else{ print('SQL not executed.); } ?>

This is interesting. What's the downside to utilizing SESSION to store data that isn't used elsewhere? Is it slower, prone to failure? I ask because I've used it in the past this way and have never run into a shortcoming that I had noticed. I hope this isn't seen as a derailment to the topic at hand, it's intended to remain relevant to the OP's post.

If you're using relative paths in engine.php and calling that file directly, moving it to a subdir will break the includes. In your example, if engine.php needed functions.php, in root it would look like include('./includes/functions.php'); the single dot meaning start in the current directory whereas, if it were in /process, it would look like include('../includes/functions.php'); the two dots meaning move up to the parent directory. Share your directory structures and include code for more relevant suggestions.

In my mind, if I weren't worried about exploiting SESSION vars(and in your usage, I wouldn't personally), I'd use SESSION as it would require less overhead and would result in less code. If you were looking to save for later use(like user leaving and returning later), then I'd look at using the db to store the values.

Depending on the complexity of the script in question, it may simply be a case of renaming some of the functions to the mysql version. https://dzone.com/articles/convert-mysql-to-mysqli