$wpdb
-
Hi everyone!
I’m developing a plugin, and I’m almost done.
I have some issues though.When I add something to my database, it’s shown on my admin-dashboard. That part works fine and dandy! But! I want a “Delete” button to each “item”..
This is how i “Call” the items from my DB:
global $wpdb; $table_name = $wpdb->prefix."comment_reminder"; $cremindsql = $wpdb->get_results("SELECT * FROM $table_name ORDER BY id DESC");As I said, that part works great!
Now, I want to add a DELETE button – I just can’t figure out how I do this. I have this code for now:
$delblog = $wpdb->query("DELETE FROM $table_name WHERE id ='1');How can I make “WHERE id = ‘1’” to be automatic?
I mean, I have a button beside each item, not I need, somehow, to put an “id” to each button?How do I do this? š
Thanks
Kucko
-
Hi bcworkz!
Thanks!
I celebrated it with a full cheese pizza!Now, I’ve read something about an admin_referer. It could check the nonce, but how? … Every time I try to put in “check_admin_referer” – i get the error “Are you sure you want to do that” And can only press “Back” …
Sanitizing my input would be a good idea ..
I could check the URL and Blogname textfield..
Lets say “max 30 chars” and sanitize that ..Or do you have any other suggestions?
CheersAris
check_admin_referer() checks that the referer field is from within the wp-admin folder structure. If your form is from the plugins folder, that is why it’s failing. If your form is from wp-admin, then it’s possibly just some silly syntax error.
Limiting text length is good for limiting possible code injection, but no need to be too stingy on length. 30 chars for an url might be a little tight. Most importantly for urls is to reject characters that are illegal for urls, I’m not sure what they are though. Hard to restrict characters for arbitrary names though, but you might consider restricting characters that have special meaning in mySQL.
Each field will have different requirements, you sort of have to think like a hacker to know how to sanitize input. Hard to do if you’re not a hacker. Maybe research how SQL injection attacks are done?
The learning never ends, eh?
-bcHi bcworkz!!
I have, once again, “updated” my security on my plugin – now it checks if user can “manage options” before it calls the options page:
function my_plugin_options() { if ( !current_user_can( 'manage_options' ) ) { wp_die( __( 'You do not have sufficient permissions to access this page.' ) ); } ?>Hurray!
Now, I recieved a mail from the plugin reviewers, telling me following:Your options.php is calling wp-admin.php
require_once(“../../../wp-admin/admin.php”);
Really, you never need to include WP’s core code like that. The whole point of the hooks and functions is so you don’t š
Now, how can I do that???
I’ve looked everywhere…. š– Aris
Anytime a link requests a php file, it initiates a new process, which requires loading the WP environment. For example, examine the core files linked in the admin panel menu. Every one of them includes either wp-admin.php or wp-load.php, depending on the situation. If you do not do this, you cannot access any hooks and functions.
I can only think of two ways around this, but both end up loading the environment in the background so you don’t have to explicitly do it, but it still happens all the same. One is to link to an existing core file that accepts url parameters such as “action” which also provide hooks so you can handle custom actions. I can’t offer up an example, but they probably exist. Then the core file requires wp-admin.php instead of you. I don’t see the real difference.
The other way you don’t need to require wp-admin.php is to do an AJAX request. Again, the requiring of the wp-admin.php is done for you in the background by the AJAX post object. You simply hook the proper AJAX action. Once again, whether you load the environment or the AJAX post object does, it must happen, I don’t see the real difference.
Now if you were to simply include files unequivocally, I could see the objection. But require_once() sees to it the files are only loaded because they have not been loaded yet. If they are not loaded, there are no functions to call and no filters and actions to hook.
I hope this helps you understand this issue.
– bcBTW, if you decide to continue requiring wp-admin.php for your plugin which would be distributed, you should get the proper path to it through some function instead of the relative ../../../ just in case someone has some funky folder structure. See the core files linked in the admin panel for some examples.
Another post reminded me of a third way to not include wp-admin.php, the form could submit to it’s own page, which is what happens when the action parameter is an empty string. But what happens in the background is the WP index.php is called to find the correct page, which includes the wp-load.php page as one of it’s first tasks. So once again, it’s done for you in the background, but it’s done all the same, so I don’t see the real difference.
Hi bcworkz!
As you say, whether I include the core-file, or a function includes it, it really doesen’t make any difference?…
Well well…
I’ve got my files, and my structure is like this:pluginname.php (setting up connection to database etc.)
pluginname-admin.php (Creates a “optionspage” in the admin-section)
pluginname-dashboard.php (Creates a dashboardwidget, and outputs some results)
pluginname-delete.php (Handles the delete-link from “pluginname-admin.php”)
options.php (Handles the forminput from “pluginname-admin.php”)Now, the files that requires “admin.php” are:
– pluginname-delete.php
– options.phpThe other files does NOT include it.
And my “pluginname.php” are handling some MySQL queries aswell.But if I delete the “require_once” line in the files – let’s say in the delete-file, it outputs an error, due to “wp_verify_nonce” …
What should I do?
I really can’t think of anything anymore.. šIf you can, please give me some examples.
– Aris
Aris,
Those other files have hooks and functions to extend WP and are not called directly by the client, which is the model your reviewers are thinking of. When called directly by the client, something has to load the WP environment or WP will not work.
Honestly, you should politely thank your reviewers for their input but you are going to continue to use the current method of loading the WP environment. Because your data is separate from WP, but you need to use WP functions, and there are no filters or actions that meet your needs, you have no alternative but to load the environment this way. You’ve followed the good example set by WP core developers for handling settings forms submits. For example, the admin settings forms submit POST requests to wp-admin/options.php. The very first code line of that file is require_once(‘./admin.php’). You are comfortable following their good example.
I hate telling people that are trying to help me they essentially don’t know what they’re talking about, but it’s sometimes necessary. If it’s really important to appease them (Perhaps they’re paying for the project?), despite their misunderstanding of the concept, there is an alternative. You could use AJAX to handle the submits and deletes. All ajax requests go to admin-ajax.php, so your script files have no need to load the WP environment. (you can easily guess what one of the first things admin-ajax does)
Unfortunately, the Codex documentation for AJAX is weak. There’s adequate information on the ‘net, but it’s confusing to put all the parts together properly unless you have pretty good skills in both jQuery and PHP. Us mere mortals can still work it out, but it’s a struggle. It is a very important aspect to learn though, so worth the effort.
If (when?) you go down this path, I suggest you avoid the example in the Codex that uses inline code and figure out how to enqueue and localize external javascript files, it’s an overall superior approach IMO.
Good luck with whichever path you choose.
-bcHonestly, you should politely thank your reviewers for their input but you are going to continue to use the current method of loading the WP environment. Because your data is separate from WP, but you need to use WP functions, and there are no filters or actions that meet your needs, you have no alternative but to load the environment this way.
This is incorrect. There is never a correct case where a *plugin* should be doing any form of include with a “../..” sort of thing to load WordPress files.
Specifically, WordPress supports redefining the location of the wp-content folder, so you cannot be sure that ../../../whatever refers back to the main folder of the WordPress installation. Having the wp-content folder completely outside the WordPress core install is a supported case, and plugins need to support that case properly.
We do not allow plugins that do this sort of thing in the directory any longer. Some older plugins may still be doing it wrong, but one step at a time.
If you need to make direct HTTP calls to your plugin to get data, then using the admin-ajax.php file and the various AJAX hooks (as explained in AJAX in Plugins) will give you the ability to have WordPress load, load your plugin, and then let your plugin produce output. This gives a constant and correct URL by which you can access the system and have it load your plugin to produce whatever output you like (not necessarily just javascript oriented return data).
If you’re doing some kind of admin settings screen as this thread seems to be describing, then using the Settings API or simply registering your screen to make calls back to options.php is a better case. You don’t need PHP files that you call directly to perform WordPress related actions. WordPress loads plugins, not the other way around.
Otto, thank you for taking the time to respond. The comments I made back then were obviously naive, I’ve since educated myself on this issue and hopefully have been giving out better advice more recently.
I’m still not fully clear on what the real issue is, though I’ve identified alternative approaches such as AJAX. I completely agree
../../path references have no place in the WordPress environment. But what if one were to include wp-load.php usingsite_url()? It resolves the relocated wp-content issue, but it’s still conceptually poor as far as “WordPress loads plugins, not the other way around.”As you noted, alternatives are available in the OP’s case. But generally speaking, people are developing plugins that really are unrelated to WordPress core but need some minimal WordPress resources, say some user data. Sure, the data can be retrieved from the DB directly without involving WordPress at all. But we are seeing development from folks who are not the strongest PHP coders. It’s all too easy for them to include wp-load.php and call
wp_get_current_user(). Would that be so bad, assuming the ../../ structures are avoided?The
site_url()function gives you a URL. It doesn’t make any sense toincludea URL.And yes, including wp-load.php is always a bad idea, because, again, you have no valid way to retrieve the directory path (not the URL path) of the location of the wp-load.php file in order to include it.
If you need to make an HTTP request to your plugin from the browser, then you should be making an HTTP request to WordPress, and passing parameters along that your plugin can recognize, and then having the plugin take appropriate action based on that. Considering that this is precisely what the admin-ajax.php method does, that’s probably the way to go.
Yeah,
site_url()was a bad example, I see what you’re saying now. I had my head on backwards and am sufficiently embarrassed. Be assured I’ll no longer advocate such a cheap shortcut. I appreciate your feedback. Thank you.I have more information to share regarding the problem of accessing WordPress functions from external files. Otto sagely suggests using AJAX. Such a solution is almost always possible, though not always desirable. As it happens, there is a similar technique to the AJAX approach, except no javascript or jQuery is required, your request handler can be initiated from a simple HTML link or form action. It is suitable for any GET or POST request. The handler can include another PHP file and in the process enable access to WP functions on that file.
See Plugin_API/Action_Reference/admin_post_(action).
Better late than never š
The topic ‘$wpdb’ is closed to new replies.