Text Overwritten in txt file

pixie4bears

I have currently have a form that is filled out with subject and message and then submitted into a txt file which shows on top of the page. All text is overwritten when someone posts a new message. Any ideas on how to keep all text (sort of like an announcement page).

<?php
include("data.txt"); 
?>
\n;
<?php
$saving = $_REQUEST['saving'];
if ($saving == 1){
$data = $_POST['message'];
$subject = $_POST['subject'];
$file = "data.txt";

$fp = fopen($file, 'w') or die("Couldn't open $file for writing!");
fwrite($fp, $subject) or die("Couldn't write first value to file!");
fwrite($fp, $data) or die("Couldn't write second value to file!");

fclose($fp);

echo "Saved to $file successfully!";


}
?>

<html>
<body>
<?php
{
	echo "<form method='post' action='chat.php?saving=1'>
Subject: <input name='subject' type='text' /><br />
  Message:<br />
  <textarea name='message' rows='15' cols='40'>
  </textarea><br />
  <input type='submit'  />
  </form>";
  }
?>

</body>
</html>

Another issue is that I would like my output to be formatted so that the subject and message are on different lines so it is easy to read..and perhaps even the subject in bold. Your help is kindly appreciated. thanks!

djjjozsi

see the file_put_contents() in the php.net ... And use the FILE_APPEND flag.

Ashley_Sheridan

Change the flag you open the file with to an 'a' instead of a 'w':

fopen($file, 'a')

This opens the file up in append mode, so that the original contents are preserved.

dagon

and the obvious - this would be a lot easier using a data base.

Ashley_Sheridan

A database could be overkill for something like this. Don't forget using a database adds its own overheads as well, and for something as simple as this, it might not be necesary

dagon

I don't think its overkill at all, its what a db is designed for - storing and manipulating data.

While there may be 10 entries in the file now, what happens when there's 100? 1000?
What happens when the op wants to only show the first 10 ?

All easily handled with a db,with less resources - and difficult with a flat file.

Ashley_Sheridan

Clearly you've not heard of a flat file database

dagon

yes i have, you don't need to be rude, and you know its not the same thing.

Ashley_Sheridan

I'm not trying to be rude, really!

I just think, for this it might be overkill. It adds a lot of overhead to include a database when it's not needed, as you have all the file access with the overhead of a special connection.

A flat file is fine for the need here I think. Log files have been using this method for years, and it's working fine for them. It's only if you need to do lots of retrieval work that a larger database solution is needed.

dagon

Ashley Sheridan;10935946 wrote:
I'm not trying to be rude, really!

Ashley Sheridan;10935946 wrote:
I just think, for this it might be overkill. It adds a lot of overhead to include a database when it's not needed, as you have all the file access with the overhead of a special connection.

Wrong, a properly managed db will use less resources than a flat file.

Ashley Sheridan;10935946 wrote:
A flat file is fine for the need here I think. Log files have been using this method for years, and it's working fine for them. It's only if you need to do lots of retrieval work that a larger database solution is needed.

Because that's how its always been done in the past is a poor argument in this (or any) industry. A horse and cart worked fine to.

johanafm

dagon;10935949 wrote:
ok
Because that's how its always been done in the past is a poor argument in this (or any) industry. A horse and cart worked fine to.

On the other hand, just because it's new doesn't mean it's good.

However, in this case I agree with Dagon for a couple of reasons.

First off, it sounds like the file will grow over time, most likely beyond the point where you'd want to include all of its contents on that page.
Secondly, keeping the most recent update at the top of the page is generally a good idea, and that means you'd either have to read the whole file, then overwrite it with the new data prepended the latest post at the top of the file (doing the work once), or parse the file each time it's requested.
Finally, to present formatted data (title in bold or whatever), the flat file would either need to be parsed, or html code saved with each entry.

With a db, there'd be no problem with having more data than you want to show on one page.
There'd be no problem sorting in whatever way you want to.
There'd be no problem knowing what is title and what is body text.

However, what I might use a file for in the end is saving prefetched and formatted data from the db, that is caching the page as it will be shown. Whenever a new post is added to the db, overwrite the old file. The best of two worlds.

djjjozsi

i vote for the database version.

laserlight

Ashley Sheridan wrote:
I just think, for this it might be overkill. It adds a lot of overhead to include a database when it's not needed, as you have all the file access with the overhead of a special connection.

Embedded database engines like SQLite make this overhead very small for the advantages that a database engine brings to the table.

bradgrafelman

Ashley Sheridan wrote:
A flat file is fine for the need here I think.

The "need here" implies that you're thinking only of the present requirements/circumstances. What if your needs change in the future? Going a more complex/intricate route in the beginning (e.g. using a popular DBMS rather than creating your own), while possibly incurring a little more work on your part, leaves the door wide open for future expansion/modification to fit different needs.

Just my 2¢ worth! 🙂