A customer wants a button that says "Relate" that would be kind of like the Like button in Facebook. It would show how many people clicked the button inside an article. Is there an easier way to do this besides creating a table in MySQL and use PHP?
I suppose you could use a CGI script written in bash that read/writes a plain text file that stores the click count. But one way or another you're going to have to have some kind of server-side handling and data storage. Doesn't have to be PHP/MySQL, but you'll have to use SOMETHING.
If you want to use data gathered across multiple sessions by multiple people, you're going to need to store that data. Whether you store it using databases, textfiles, or carve it in a tree is up to you.
Yep, instead of creating a new table, just add a column likes INTEGER(11) to articles table. Whenever someone clicks the "relate" button just add count by one.
You may also want to disable button after user has clicked it. You may want to store the info liked:article_id in cookie to make sure user do not adds fake "relates", unless he clears cookie. But tracking logged in user is different (but more appropriate) game.
Related
I'm looking for a way to create a page with items on it where each item has a button which can be clicked to "like" or "choose" the item. The website would then remember the choices and input them to a form on another page. Is there anyway of doing this?
At first glance if we are talking about a registered user, i would create fields in the database for the user's input and store its value everytime he makes a selection. Then its only a matter of putting those values wherever you want.
You have several choices. If it is persistent data, I'd suggest a database like MySQL. If you don't have access to that, then Google for "flat file database" and you'll find some great ideas.
If the data is persistent, but not a big deal if it gets deleted or spoofed, you can use cookies.
If the data is fleeting (it goes away at the end of the visit), then use sessions.
The best way to do is storing each result in a SESSION and reusing it in other form.
Scenario No 1
On page1.php I use php with MySQL to get a product's data to the page. When a user wants to proceed to page, 2 he clicks on a button.
On page2.php there is also some info about the product, mainly for checkout purposes. For this data to be displayed I make use of the ID of the product so page2.php is actually page2.php?id=123. Therefore, using again PHP and MySQL I get the data I need.
Scenario No 2
On page1.php I use php with MySQL to get a product's data to the page. The needed values for page2.php are stored in sessions. When a user wants to proceed to page 2, he clicks on a button.
On page2.php now, the information about the product is shown using sessions. This time page2.php is actually page2.php that it is shown on the address bar.
I prefer doing this with scenario 1. The user will be able to copy/paste or send through a button the page to a friend for direct access. I don't think that one more hit to the db is a problem.
What is your opinion ?
I would agree that scenario 1 is better. You should use a session for its intended purpose, carrying state of a particular user, not misuse it as some form of caching mechanims in my opinion.
That's why you use the database in the first place - to have efficient access to your data. Why try to build a cache around the thing that should actually improve the efficiency if used?
If access ever becomes a bottleneck and you really need to look into caching, then there are still better mechanisms than to use your session for this purpose.
No. 1 is definitely the better approach. The second approach would only make sense if the product is attached to the user's session (for instance, when going through an order wizard). And even then, it's still better to just attach the product ID to the session, and fetch the product information from the database on each new page.
I need to build a registration system which requires the collection of large data (many fields) from the user registering which is then inserted into a couple of tables in a database.
I don't really want to display a very long form to the user for the purposes of better UX.
This system will not run online, it is just a web app to run on the desktop.
I need help, pointers, references, etc on how I can better organize the registration process to make it more user friendly.
This How to encourage a user to fill in long application forms? has been helpful so far
As long as you don't mind requiring your user has Javascript, I would use AJAX. Let's say that you have 50 fields that you can logically combine into 4 different sets - the first may be about the person asking for name, email, etc., while the next set asks for historical information or employment information - like on an application.
Make one form for each set, and then present a new user with the first. When he completes the first page, instead of a "Submit" or "Register" button, use an AJAX call and a "Next" button to get the info and switch to the next page of the form with the next set of fields. You could use the AJAX calls to hold the information in a temp table in your database, and then, once the entire process is complete, you can write it to your member/users table.
You could do like other surveys or checkouts do and add a "title" for each page of the form above the form fields so that as a user moves through registration, they can monitor their own progress.
I'd recommend checking out the Amazon checkout, or really any multi-page survey (you may even be able to set one up yourself on Survey Monkey) to see how a large number of form fields can be broken down logically in a user friendly way.
Hope it helps.
Check out this link: http://www.smashingmagazine.com/2011/05/05/innovative-techniques-to-simplify-signups-and-logins/
It's talking about login- and registration-forms and how to make them more user-friendly. A suggestion which is also included in this article is as follows:
At registration don't ask the user to many questions. Only the basic data like their name for example. Then ask him about more detailed data when the user logs in the first time. This way the registration won't take too long.
Maybe this helps you out :)
This is inside a PHP website form.
An example is like:
First page:
-Username:
-Password
Second page:
-Email
-[Checkbox]
Thirdpage:
-Contact Details
-Address
Fourth page:
Review all of the above forms in hard copy but with a back and forward command so that the user does not loose any information when switching between these pages.
Please post.
You could use cookies and do your own sessions with MySQL too. I like doing it like that because the data is easier to access if necessary.
Or you can pass the previous variables to the next page though hidden form elements.. but that can get messy.
You Have to use session. I like Zend_Session.
If you want users to be able to come back later and complete the form (assuming you have some kind of login system, or a way to recognize users), you could still save the data into a database. Make another table, temp_submissions. Keep data in it until the user completes the form and commits the data they send. Once committed, clear the data out of the temp_submissions folder and insert it into the "permanent" table. It may not be practical in this case, or total overkill, but it's an alternative to sessions and cookies.
I want to allow users as well as me(the admin) to delete data in mysql.
I used to have remove.php that would get $_GETs from whatever that needed to be deleted such as... remove.php?action=post&posting_id=2. But I learned that anyone can simply abuse it and delete all my data.
So what's the safest way for users and me to delete information without getting all crazy and hard? I am only a beginner :)
I'm not sure if I can use POSTs because there is no forms and the data isn't changing.
Is sessions good? Or would there be too many with postings, user information, comments, etc.
Ex: James wants to delete one of his postings(it is posting_id=5). So he clicks the remove link and that takes him to remove.php?action=post&posting_id=5.
EDIT: Alright, so now I am a little confused. While I can't be 100% secure, how do I do this with $_POSTs?
SOO I should use GETs to get all the data to remove.php, THEN have a confirmation submit button and when users click on it, it put all the data into POSTs and delete from the dbc?
Deleting records is a kind of a scary practice. If you or someone makes a mistake there's no real recourse to resolve the issue. Expunged records are very hard to resurrect.
Instead of deleting records, you could add an "active" bit (e.g. Boolean) column that is toggled off when users "delete" records. Essentially your users would be suspending records by toggling them off and the records would be saved in case mistakes or abuse but appear "deleted" to the user. To make this work with your other queries, just add a where clause of active = 1.
You could then have a utility script that's run at some specific date interval that would clean out deprecated, past dated records. You'd also need some type of timestamp for this type of maintenance.
Just a thought. Take if for what it's worth.
I'll echo gurun8 in preferring to 'mark' records as deleted, instead of actually removing data. And then obviously, you'll need to check that the authenticated user has permission to delete the post.
However, it seems very important to mention that $_GET is not safe even with authentication because of cross-site request forgery.
Imagine if Amazon adding things to your cart based on a GET request. All I'd have to do is put an image on my page with that URL, and everyone who visited that page and logged into Amazon will have products added automatically.
To match your example, I don't like Jame's post, so i put an image on my site like this:
<img src='http://example.com/remove.php?action=post&posting_id=5'>
And I send him a link to my page, and ask him to check it out, hoping that at the time he's logged in to your site. Because, of course, he clicked that little 'keep me logged in' button.
So you are right to be concerned about using GET. If you don't want to litter pages with forms, then confirm the action by POST.
Well you have to start by authenticating the users with a login script.
If you want the simplest solution possible, then I'd suggest protecting the directory in which you have remove.php with a simple .htaccess username and password.
If different users have different rights for deleting database entries, then you probably should create a PHP login script and use PHP session.
Bonk me if I'm stupid, but I searched for quite some time for a simple PHP login tutorial that could be placed on a real site (doesn't use session_register(), uses mysql_real_escape_string(), htmlspecialchars() etc) and I simply couldn't find one!
Probably this one comes the closest, you just have to replace session_register() variables with $_SESSION ones for it to work without register_globals (default in PHP5).