Using Mysql to store articles as Wordpress does - php

I am looking for a way to store article in database in the same format as it would appear on the website. Could anyone here kindly explain how to store the entire article in database and later display the same on web? I suppose I need some mechanism to accomplish this. But I couldn't find any solution for the past 4 days despite extensive searching all over. Please help.

Storing html in a database is easy enough, but trying to store whole webpages is not the right way to do it...
Many WYSIWYG editors send html through for you to store, depending on your requirements typically you would store these in a VARCHAR to TEXT column in your (MySQL) database.
Simply insert the data into your database with a normal INSERT statement.

Related

Is there a way to store multiple records rather than using multiple rows in MySQL?

I would like to make full use out of MySQL for the purpose of a (web) application I have developed for a chiropractor.
So far I have been storing in a single row for [every year] for what are called progress notes. The table structure looks something like this (progress_note_id, patient_id, date (Y-0-0), progress_note). When the client wishes to append for the year of the current progress notes, he simply clicks at the top of a textarea (html), which I use TinyMCE JavaScript library, to make a new entry date along with the shorthand notes to go at the beginning of the column (progress_note). So far its been working ok, if there are 900+ clients (est.) there could potentially be 1300+ progress notes, for each year since the beginning of the application (2018).
Now the client wishes to be able to see previous progress notes (history), but is unable to modify any previous notes, while still be able to write new ones. The solution I have come up with is to use XML inside the textarea, and use PHP to decipher the new notes from the old ones.
My problem however is if I should have to convert my entire table from a yearly to a daily, that it could take up a lot of time and energy to convert multiple notes into each single rows, (est. 10x) Which could end up being 13,000+ rows. I realize that no matter what method I choose to do is going to be a lot of work. Another way around this perhaps I found was to use XML column type in MySQL to potentially store multiple records, and if I wish to append it, all I would need is PHP to interpret the entire XML and add a new child node, to the beginning. Each progress note is 255 - 500 chars. And in worst case scenario, if the patient was to be 52 times a year (1 for every week), there shouldn't be a large enough overhead.
Is this the correct way to solving this problem? I do wish to keep with MySQL DB and I realize that MySQL is not an intended for XML. And for some clarification, what I hope to accomplish is the same thing I intended to do with current progress notes, but with XML. I believe in ascending order (newer -> oldest).
<xml_result>
<progress_note>
<date>2020-08-16</date>
<content></content>
</progress_note>
<xml_result>
Thank-you for any of your time and for any suggestions.
Firstly, 13000+ is not a problem for mysql. In most case for web application, mysql can handle more than 10m+ records for a single instance with a good performance.
Secondly, you can use either XML or JSON format in a text field and handle the decoding in your application.

Is it ok to get keywords and description from database?

This isn't really a coding question, but I wanted to ask about what is more efficient and what should I use.
I am making a tutorials website, and each tutorial is brought up onto a page "blog.php" on which all data comes from the database. Now I have two ways I can fill in the meta keywords tag and meta description tag.
I was thinking of making 2 new columns in the blogs table, keywords, and description, and the meta tags would be filled up correspondingly from the database, and the database would get the keywords and description from user input (whover wrote the blog). I know how I would do this but is this efficient? Because I heard search engines have a harder time reading stuff from the database, so I wanted to make sure.
So I can use that OR do you recommend that I use JQuery to get text from the title tag and use that type of stuff? It would be really great because I was hoping to use PHP to make it dynamic, but if I should use Jquery and javascript then please tell which is better!
Thanks!
Search engines never read stuff from the database.
They read only HTML generated by your script.
Storing keywords and description in database is all right.
The only thing you have to change in your setup is database design.
There shouldn't be keywords field in the blog table. Instead of that there should be keywords table and keywords_blog lookup table to link between keywords and tutorials.
Search engines don't read from your database, only you do! What search engines have sometimes struggled with is dyanmic pages, i.e. a page like blog.php where the content changes via the query string, so blog.php?id=1 etc.
What many people do in this situation is use human readable URLs along with rewriting etc so your URLs might be
/blog/what-i-did-today
/blog/why-x-sucks
or similar. This would all be server by blog.php (or index.php or whatever) and then you can easily allow your bloggers to add their own keywords and descriptions via your database.
But do you really need to write your own? There is a ton of software out there that you can just download and install that does this already. Do you need to re-invent the wheel?

Multiple xml feeds, sql match

I'm developing a store which gets its product info from lots of xml feed, I'll have maybe 3000 products in my database. I'll do it using a cronjob.
What I'd like to do is write posts, lets say a general post about picking the best TV set for yor family. Then I'd make a mysql match whitch should take the posts title and content and match it to the thousands of products in my database and retrieve the closest match to display on my post.
I'm thinking of this becouse having alot of xml with different nods, categories would be very hard for me to propely filter them using php.
Now, do you think thats a good ideea? content, performace wise?
Do you think mysql match could do it? Maybe use some other method?
Should I store all the product info like price, description, reviews in a single table field and use it for the mysql match?
Is there a better way I can do this?
Any ideea is very appreciated, I need to sort this out, make a plan before I start coding and waiting time.
What you are trying to do is awful with pure XML.
I strongly suggest you to leave this task to your Database in this case MySQL, basically your 3rd point.
With MyISAM table you can set up the full text search if you need a bit more complex query based on affinity.

HTML Table row edit/Delete

I have an HTML table with contents, I would like to have an feature of Edit/Delete to that table. How do I do it with PHP?
I actually think that this sounds more like a job for JavaScript, which can edit/remove rows on-the-fly and with much less code. (Implement some AJAX too, and you can edit/remove rows in database too).
But if you insist on using PHP, you might just want to add some GET parameters to the Edit/Delete links that would delete or edit those rows.
Well, there is a pure PHP way to do it, and then there is a combination of Javascript and PHP. You must use PHP one way or another if you want your changes to the database to be permanent as that is your gateway to communicating with the database (as far as I know you cannot do that with Javascript as that is client-based and runs entirely in your web browser).
If using just PHP, you must generate HTML documents for each change. E.g., you click on one cell in the table and that gets you to a new HTML page where the field is editable through an input element; or you can list all fields at once for that row and edit them all at the same time. The fields are then posted in a form to a PHP page which will take the new values and update the database (or insert new values or however you wish it to behave). Here's a tutorial for how to do this:
http://www.freewebmasterhelp.com/tutorials/phpmysql/1
You can also mix in some Javascript which allows a more interactive interface to modifying the values in a cell. However, this obviously requires more code and may be overkill for what you're trying to do. Nonetheless, here is a link which demonstrates just that and also shows the code:
http://www.java2s.com/Code/JavaScript/GUI-Components/Editabletablecell.htm
Hope this is what you're looking for.
EDIT:
Forgot that you also wished to delete content in the table. That is also explained in the first link.
If you intend to work with databases, and it seems like you have little understanding of how they work, pick up a good book like: SQL - The Complete Reference. When you have enough knowledge of SQL, look at PHP's PDO extension: http://php.net/manual/en/book.pdo.php

Is saving enormous user information into a MySQL table good if one wants to display it for later use?

I have a file named discussion.php, where a form is located. In this form, a user will enter information, and the information will be posted to savedisc.php. Below is the code for discussion.php:
<form action='savedisc.php' method='post'>
<p>What would you like to discuss?</p>
<textarea name='message' rows='15' cols='40'></textarea>
<input type='submit' value='Submit' />
</form>
Once the user hits the submit button, the text that the user had typed should be saved via savedisc.php. I.e. I will connect to the database, and save what the user had typed in textarea.
Now to display the information that the user had typed in the textarea, I will connect to the database in another file, and show the appropriate content.
Some of my questions are: Should I not save it in the database? Because later on I might have enormous amounts of data in my tables. Is there another way to display information submitted by a user without the use of saving to the database? Or am I doing OKAY? For example, the question I am about to post right now, is it actually saved in a database?
Thank you.
Yes! Databases are good at storing large quantities of data, so you're fine!
As long as you do proper validation of data*, go right ahead!
* - Look up mysql_real_escape_string
MySQL is perfectly capable to handle tables with several gigabytes of data. I doubt this will ever be a problem.
The alternative being to store the data in flat files, it's clearly better to use MySQL for this purpose.
Databases are meant to store large amount of data and handle large amount of transactions. So, definitely yes.
But if you're thinking of optimizing your database and save some resources, you can store the data the user just entered and show it without requesting it again from the database, like when you ask a question and it shows it to you again on Stack Overflow, you'd have one less transaction.
So, for example in your savedisc.php
<?php
$message = $_POST['message'];
StoreInDB($message); // some function to store data
echo $message; // this is useful when you want to immediately
// show the user the information they entered
?>
yes, that's an entirely appropriate use of a database. An exception might be if If the size of each piece of text is very large, like 10 or 50 or 150kb, in which case you might consider storing it as files and storing file metadata in the database.
Most CMSes use a database backend to store the actual text and markup for their stories; large sites such as the New York Times and the Washington Post use databases to store their stories, so that they can be searched and cross-referenced as necessary. While it is possible to do all of that as files in a filesystem, modern databases are optimized for these sorts of operations.
One thing you'll need to do is to choose the type of table and datatype to use for storing your data. MySQL provides several storage engines for creating tables (InnoDB and MyISAM are the most popular). As for data types, CHAR and VARCHAR are good for relatively small amounts of text, with TEXT being suitable for large amounts of text. (If you're storing raw binary data, like images, instead of text, then you'll be more interested in BINARY, VARBINARY, and BLOB).
Each storage engine and datatype will provide different trade-offs for performance and functionality, but for relatively small and simple applications, MyISAM and either VARCHAR or TEXT will be a good choice for your needs.

Categories