scootstah

You can't use PHP in HTML files. The simple option is this: <?php include 'header.php'; include 'page.php'; include 'footer.php';The middle include would probably dynamically include the page you requested, but you get the idea.

Then you didn't have a big enough site. Nobody here wrote the forum software. We don't have time to spend thousands of hours writing custom software for a free website. It is not possible to stop spam bots entirely, sorry.

No, it meant you are not going to prevent a browser from refreshing the page.

That is a redirect my friend.

That's fine, moving the application outside of the document root doesn't change that. You could either set a constant for the base application path and reference it any time you need that path, or if you're using proper OOP structure, you'd just tell your autoloader where to look.

Just forget about this idea right now. It's not going to happen.

Add the keywords to an array: $keywords = array(); while($rows2=@mysqli_fetch_array($result2)){ $keywords[] = htmlspecialchars($rows2['query'], ENT_QUOTES); }And then implode it:<meta name='keywords' content='<?php echo implode(',', $keywords);?>'>

The idea is that you store which topics they have viewed in the database. Within a given time frame, if a topic does not have a row in that "viewed" table, then it is new. Very simple, nothing complicated here. This is a feature that every forum package within the last decade or more has implemented, most of which in this very same way. That's just how it works. You could track it client-side if you wanted, but then you don't have persistence cross-device. At that point you have to decide what your end goal is.

You would use 775, and set the group owner to the web server user. Since you're using CentOS and you most probably have SELinux enabled, you have some additional steps to take.

You're missing the point entirely. Again, you're talking about tracking what someone didn't read.

How is it a "silly feature"? That is the way every forum package ever works.

I don't understand your question. If you don't want 777, then you would use chmod to change the permissions.

This forum has 166,826 members and 1,515,137 posts. It doesn't tell me how many topics. So worst case scenario, that's 252,764,245,162 rows, ha. But, it would be easy enough to keep that table pruned and at a reasonable size. There were 16,296 total topic views for this month. 314,000 for the year. So, yeah, it's completely manageable.

Why does it matter if they "know"? If you rewrite it gives false impressions. But, this is what you want: RewriteEngine on RewriteRule ^priv(.*)$ index.php?q=$1 RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ index.php?q=$1 [B,L,QSA]You can change how you want the parameters to appear to index.php. But for the record, can you expand on this? If you are routing things through index.php, then only needs to be visible to the public. The entirety of your application should live behind the document root. That is standard practice and the correct way to do things these days.

I've used a ton of different forum software over the years, and I can't think of one that works that way. If you do it that way, new posts will only be new until you refresh the page. Or, you have some kind of offset where it remains new for X minutes. Most forum software, like this one, will maintain state cross-device. So if I login on my PC and there are 10 new threads, and I read one, and then I login on my phone there will only be 9 new threads. You could prune the table when data gets so old if you desire. It's an expensive feature. EDIT: And I think you've got it backwards. You don't track what they haven't read, you track what they have explicitly read.

It's been a while since I have played with forum software, so I don't remember details off the top of my head. One way is you would have a "users" table and a "topics" table. Then you would have a "viewed_topics" table (or whatever you want to call it). "viewed_topics" would just have columns for the user id, topic id, and maybe a date or post id. When a user views the topic a row gets added to "viewed_topics". When a new post is created, all rows in "viewed_topics" get deleted. When displaying topics, you can just JOIN the "viewed_topics" table and determine if it is new or not by whether a row exists there or not.

You should configure Apache to restrict access to that directory, using "deny". order deny,allow deny from allYou can either put that in an .htaccess file inside the private directory, or make a <Directory></Directory> section in your site config.

There's no real super efficient way to tackle this. You basically have to have one write per read. When a user views a post, you store that in some way.

The code you posted gives us nothing. You have told us what you want to do, but have not told us what the problem is. Presumably you would get a "total quantity" by querying your database.

You need to return a 404 header when an invalid page is reached. That doesn't happen automatically, you have to do that from your routing logic.

I'm not sure what would have caused them to index those pages to start with. Maybe some other site linked to your site with those pages for some reason. In any case, now that they are indexed, they're likely to remain that way for a while. Are you returning a proper 404 header for those pages?

Did those pages exist at any point?

You don't need to filter HTML special characters when interacting with a database. $stmt->execute([':username' => $data['username']]);Where did $data['username'] come from?

You need to SELECT the user first, to make sure the information given is valid. Then you can perform the update.

https://rightsignature.com/ Why not use a service like this?