So I am a bit new to MYSQL and I've been learning allot more about relational databases but I am a bit stumped with one subject in mind. I notice allot of sites have things like domain.tld/variable. I understand how this works by using /?variable=name but most users would never use that. So how does one go about letting users pull content based on the principal listed?
Actually, that has nothing to do with databases.
When the url is accessed, url rewriting is used to change the url behind the scenes. While the user enters domain.com/data, the php script (or anything else) at domain.com?variable=data is opened.
Related
I'm looking for a PHP script that will allow me to easily manage 'MySql' tables. By managing I mean not their creation but the possibility of adding new records, modifying and deleting them.
It must be possible to specify for each user which tables he will have access to and with which modalities (insertion only, modification only, etc.).
For each user I will also have to specify whether he will be able to see all or some of the columns in the table and with which permissions.
Also I'll need to know who did what, a sort of global change LOG.
My idea was to have a back-end in which I specified the users and how to access the various tables/columns and a front-end for the users.
In the front-end users will be able to add/modify/delete records and data they are allowed and the ability to filter and/or sort the various records.
I know I could use some PHP frameworks or rely on CMS but I have to write a lot of code by hand and it seems hardly credible that such a product is not already available.
Does anyone know if there is something like this?
I had tried starting with PHP frameworks but implementing everything from scratch stopped me.
I expect there is already something available.
Thanks.
Davide.
I'm designing a website where users can upload comments on pages, and other users should see those comments. I reached the stage where I have the comments stored in a database, and I know the place they're supposed to go in the html, and I need to connect those two things somehow.
I'm using express and Node.js on the server side, and postgres on the db side.
As of when I'm asking this, it seems to me it's very bad practice to have the user access the database. So I think the server needs to access the database based on the user's request, modify the generalized html's showing of comments to now have the information of the specific comments, save that to a file, and send it to the user. To do this I was thinking of creating an "html generator function" on the server-side that takes in specific comment information and puts it in the generalized html, but that seems like it doesn't scale well and I'm concerned that storing the intermediate file would be inefficient.
Is that the correct approach? Can you tell me known ways of doing this that aren't so hacky?
If you suggest using php, isn't there a problem where php connects to a server and disconnects every time we use it? I would prefer if the server connected once when it booted and did all the fetching when needed instead of connecting every time. It seems to me like that would involve far less overhead (correct me if I'm wrong...)
See the comment of Amadan for the full solution. It's called a "template engine"
Edit:
I highly recommend learning React. I learned EJS and it's difficult to scale. React is infinitely easier to program with for just a little more investment. The old web is much less declarative (& EJS is much less too).
I am trying to find a way for a user to come to my site and fill in a form and when they submit the form a new webpage is made. I want to make it create a new webpage in an admin area so I can view what they have submitted without having to troll my databases. I am assuming this is possible because the concept is hardly new, but hours of scanning google has left me empty handed on any remotely close tutorial or anything of that nature. Perhaps I simply do not know how to word it, I am very new at forms but I am assuming this has something to do with the form action. Are there tutorials for this that someone can link me to or can someone give me a quick explanation? I can figure out the work for myself, I just need a point in the right direction. Thank you.
You're going to need to learn about 1) persistant storage (a database), 2) a server side programming language (HTML is purely for creating the structure of a web page), and ... I dunno, a lot more. I would suggest you actually look at a CMS (content management system) and see if that gets you where you want to go.
Databases don't interact with HTML in that way without some sort of application sitting between the site and the database. It doesn't have to be a PHP application, but something is going to have to store and get data from the db, and something is going to have to dynamically create these pages you want. And that's going to be some sort of programming language -- or a content management system like Drupal.
(Also, don't forget about security, support, etc. You write the app, you have to support it. =)
I'm hoping this isn't harder than it seems.
I want to create an HTML form with a few text boxes that will allow people to enter in some data and I want these changes to be saved to the form.
For example, if my html page says:
Name: [ ]
...I want someone to be able to click on the [] and enter their name, etc. and click SAVE
and then have the form say:
Name: "Name of Person"
If someone wants to update that, they can click on the person's name and change it and click SAVE and have the HTML form update itself.
How can I do this? I've looked everywhere and people are talking about HTML5 AND PHP. Is it really that complicated to make a simple page like this?
(In case I wasn't clear in my html I'm using the contenteditable="true" option. How can I save those changes?)
I think your question indicates that you don't already know that web pages (including forms) are "stateless", meaning that they do not "automatically" hold or store anything that you do with them. Sorry to disappoint, but as a beginner you will struggle to find "an easy" solution to this.
That is not to say it can't be done - you no doubt see it everywhere - but your level of knowledge misses the fact that you need to actually program the logic to determine how your form will "appear" to store the information and reproduce it on a later visit.
Here's a (really) brief summary:
When your form is used by your user, a couple of things have already taken place before they get to see the form:
the user has requested the page (typing a URL or clicking a link)
the web server has sent the requested page (that is; your website has sent the form)
The next thing that takes place is that your user enters some data on the form. This data is not stored anywhere - if you refresh the page the data is gone, because steps 1 and 2 happen again.
So to avoid this you can use a number of tools:
Javascript: this operates on the user's computer. You can use it to find out if something has been entred on a form, and store it in, for example, a cookie.
Then you will have to build some logic into your page that says, "if my user refreshes the page or comes back to this site at a later date, then look for the cookie. If it exists, then take it's values and pre-fill the form, before the user gets to see it."
Server Side Script: This logic can be built into your web server (using a server side script like PHP) so it actually runs in step 2.
Alternatively you can build it into a javascript function which fires when the page is actually received by your user. This would be a step 3.
A second alternative combines these two ideas (processing on the user side and processing on the webserver side) called AJAX, which basically means that the "discussion" between your javascript and PHP takes place "on the fly" when the data is entered or changed.
And lastly you might want to consider PHP Sessions to store data, and/or a mySQL database. Recently with the advent of modern browsers you now have the possibility to store the information in a local database available to your user's browser...
In all of these cases you will need to learn how these pieces talk to each other, how you retreive the information, and how you update your stateless and static form.
It isn't has straightforward as you might think...
You don't need HTML5. HTML4 is good enough :)
But you need some server side script that saves the changes (on the server side in e.g. a DB or XML file). To make it a better experience (if multiple users use the form at the same time) I suggest you use AJAX to save the changes and poll the server for updates.
This is not complicated (at least I don't think it is), but it seems to be a generation ahead of what you already know. And it could take quite a long time to get the structure in place before you can do this sort of thing without needing help.
There are some basic questions
Does the information need to stay saved when the user hits reload?
Does the information need to stay saved when the user clears cookies?
If the information can be blanked out next time they come back to your page, then it is simple.
Otherwise, we need a way to keep track of which user sees what information, so the guy in Texas does not see the information the guy in Chinatown typed in. Cookies are a common way to do this. You could save the information to the cookies if there is not too much information.
Otherwise, you need sever-side language. This is usually in PHP, but deciding what language has to do with why you want to learn in the first place? Are you wanting to work for a company later on? Do you have your own website?
Please comment to let me know more what is going on, and what the answers are to the two basic questions, and I will better be able to answer.
Usually, for most cases, there is a login name and password (or OpenID), and if cookies are cleared, the user logs in again, but this requires some work to set up a working login before you re-visit this question of how to store what they type.
Currently I'm working with an in house white label cms that we resell to multiple clients and it all runs from the same box/db.
I'm just looking at converting this to have an ecommerce version that we'll run alongside it.
I'm wondering whether there will be an issue keeping all the products/categories/orders in one db or whether it would be advisory to separate each instance of the site into its own db for this.
These white label instances will only be sold to smaller companies that probably wont have masses of traffic/products and are looking for a simple ecommerce site. Anything larger will definitely get its own hosting and db.
But for smaller scale stuff do you think a single db will be ok?
#Tim: Aye I agree completely, however as I'm working from an existing codebase all of the site specific filtering code is built in. All I need to do is add a couple of fields to each table and the backend will already take care of all that filter for me.
Also the codebase I'm working from is set up with multiple access levels, user(public), userAdmin(customer) and admin(me), and is built in suck a way that I can generate a new site from the admin portal. I then just need to upload new templates/css/js/images and the whole new site is created.
So theoretically it may be more work to have to separate out the ecommerce databases than it would be to leave it in one.
Hence the question, if there is likely to be issues with having multiple sites in one DB I'll split it out, but if it's not going to make too much odds I'll leave it as is...
In fact I think I just answered my own question, I'll implement it into the existing codebase and set it up to run on one db, with the knowledge that i can always install the whole codebase on another box and run a single site on it if I need to :)
Thanks for the quick reply
Having everything piled into a single DB is going to complicate your code considerably. Instead of it being a configuration difference (which DB to connect to), you're going to be peppering your code with filters based on the current customer. I would vote for separate DBs in a heartbeat. Even if you wind up with excessive load from all the small DBs, it should be easy to add a new DB server and point new sites to the DB on the new server.
I can't see the complications this would create in your code being worth it in the long run.