Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by maxxd

  1. I may not be understanding your question, but do_shortcode() is not a PHP function, it's a WordPress function. If you're trying to call it from a script that isn't run through WordPress (if it's an external script [I think is what you're describing]), it's not going to work.
  2. Couldn't even begin to say why, but I always forget about __DIR__. It's weird, honestly.
  3. I've typically used something along the lines of this: require_once(dirname(__FILE__).'/style/navbar.php'); I don't know if it's better or not, but it does make me feel like I've got more control over the file structure and as though there's less of a chance of somehow injecting "../../{whatever nefarious thing}" into $_SERVER['DOCUMENT_ROOT']. Also, (really no point in lying here) I don't even know if it's possible to inject into$_SERVER['DOCUMENT_ROOT'], but I know that $_SERVER['PHP_SELF'] can be spoofed, so I think it may just be possible. Maybe I'm just being paranoid.
  4. It's a kludge, but you could always keep a list of files in a database or flatfile and schedule a CRON to run a script that scans the directory for file names, then compare that to the saved list. You'd know if something had been added or removed, though it wouldn't be instant.
  5. Just don't forget that you'll have to make those changes to the plugin file every time you update your plugin.
  6. Not as it is now - if you want to tell the user which is taken you'll have to update the query. Right now it just returns a count of records that match either the username or the email. You'll have to actually select both and then check in PHP which one matches, or rewrite the query to return the offending column. However, I'd recommend just letting people know that one of the two has been taken. That way you're not confirming to an outside party which of the two actually exists in the database - a hacker that knows for a fact a username exists has less work to do and can focus only on figuring out a correct password.
  7. Don't do that. Try PHP The Right Way or codecademy - there are a lot of tutorials and lessons out there. If you don't know whether or not they're any good, ask here first. Someone can tell you. w3shools.com is a great place to look up what exactly you need to Google in order to figure out how something works, but it's not a great place to actually learn how something works.
  8. SELECT COUNT(*) AS recs FROM users WHERE username = :username OR email = :email You're overwriting your query and only checking for the email match - try the above as the only value of $sql. Also (and I could be wrong so hopefully someone will correct me if I am) I seem to remember having run into to troubles using 'email' as a column name in MySql - I tend to use something like "email_address" (or "eAddy" if I'm tired of typing). As to the unique index point that mac_gyver raised, if those columns are already set to 'UNIQUE', just insert the data. If there's a duplicate in either column, the insert will throw an error - check that and let the user know what's up. No data will actually be inserted because the attempt violates the unique constraints so no harm done.
  9. I don't program Python, but I have to say that VSCode is quickly becoming my favorite IDE. It's fast, has a huge amount of plugins, and seems light and nimble on my Mac desktop, Windows 10 desktop, and my Surface. The biggest issue I have with it as of right now is that some of the Windows version keyboard shortcuts are different from the Mac version shortcuts.
  10. The biggest thing about WordPress and AJAX is that WP routes all AJAX calls through the admin_ajax file, and what exactly it does at that point is dependent on the `action` parameter of the passed data - at that point it uses it's internal routing and the 'action' parameter to figure out what file and function/method to call via the add_action() call - however, it doesn't actually pass any parameters to the called function. So you need to pass all the data in the AJAX request but don't expect any of it to actually hit the handling function that you've written - you're still going to have to go to the $_POST or $_GET superglobals for that. Sure, you could use the $_REQUEST superglobal, but WP has enough security concerns without adding more so skip $_REQUEST entirely please. Sorry, none of that is entirely unusual but IMO if you're going to force everything to go through a centralized location you should at least consolidate and pass data to the called target. It's just courtesy for making me jump through the extra hoop. Anyway (long and random "it's my second glass of wine" rant aside), the important part is that you technically can - like any other application - send your AJAX request to any receptive PHP file you want. The problem is that if you don't use the admin_ajax link, the WordPress core won't be loaded. So any and all of the functions, objects, or hooks you want or need to use won't exist at the time of the AJAX call.
  11. First, if you're going to be handling form processing via AJAX you don't need an action attribute on the form. Your JavaScript preventDefault() on the submit event stops the form from submitting to the action target anyway. Your AJAX handling functions are doing a few redundant things. For instance, the acikudos_ajax_handler() function is invoking the global $wpdb in order to ignore it completely before sending the program to acikudos_process_request(), where the global $wpdb is invoked again. Then acikudos_process_request() echos the JSON encoded data before returning the array data to acikudos_ajax_handler(), which prints the JSON encoded array. Again. Beyond that, WordPress runs all AJAX calls through the wp_ajax_{action}() and wp_ajax_nopriv_{action}() hooks, so I'm a bit confused as to how the acikudos-update.php file is even getting called at this point if the hooks for those actions are actually in that file. It's pretty normal to put all the action and filter hooks into the plugin main (or 'functions') file (I assume at this point that is acikudos-plugin.php). You can always call to external classes from the functions file by using an array as the second parameter in the add_action() or add_filter() calls - for instance: add_action('wp_ajax_acikudos', [myObject, 'acikudos_ajax_handler'], 0, 1); It's late so I hope I'm not missing something you've described in your code, but I would recommend doing some more searching into how WordPress handles AJAX in general - it can be a bit confusing at first. Beyond that, you've got a random quotation mark in the acikudos-edit.php file that should be easy to see in any decent IDE or even here in your post. I'm assuming it's an issue in the copy/paste as the file wouldn't work at all if that were the verbatim code in development and testing.
  12. requinix is right - don't worry about the physical size of the screen. As monitors are packing more pixels in per inch it doesn't matter at all. I personally use pixel-based breakpoints for my media queries with rem or percentages for element sizing and placement. It's an approach some people disagree with - I've talked to developers that think using rem or em is the only way to go, I've just not really been able to wrap my head around applying rem or em units to a Photoshop file, and I guarantee the designers here won't do it either.
  13. It's because you're making things hard on yourself. You're constructing a full URL (for no reason other than to assign it immediately to another variable) only in order to check that a $_GET variable marker exists without actually checking to see if the corresponding $_GET variable value exists. You then try to access the value of the $_GET variable without checking to see if it's actually set, hence the error you would be getting if you had error reporting turned on. All of this: $actual_link = (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] === 'on' ? "https" : "http") . "://$_SERVER[HTTP_HOST]$_SERVER[REQUEST_URI]"; $url = $actual_link; if (strpos($url, "?viewkudoid")!==false){ $viewkudoid = $_GET['viewkudoid']; /* ... stuff ... */ } should be replaced with this: if(!empty($_GET['viewkudoid'])){ /* ... stuff ... */ } What you're doing now by checking to see if the string `?viewkudoid` is in the URL will technically handle scenario 2 and most of scenario 3 - the problem is that you're assuming there's a value assigned to viewkudoid in the URL. Which you can't. Besides which, everything after the question mark in a URL is the $_GET array. So ditch the homespun variable name existence check and make sure the value exists. Then you'll be taking care of scenarios 2 and 3 - scenario 3 will follow the else clause and print out all kudos records. And turn on error reporting while you're developing. You should have it turned on in your php.ini on the development/testing server, but you can enable it on a per-site basis. With WordPress you've got 2 ways to turn on error reporting: you can go the traditional PHP way and add this to the top of your script file: error_reporting(-1); ini_set('display_errors', true); or you can go the WordPress way and add this to your wp-config.php file: define('WP_DEBUG', true); define('WP_DEBUG_DISPLAY', true); For more information, check here. I will say that in my experience the WordPress way isn't bulletproof, and I'd highly recommend using the PHP ini_set() and error_reporting() functions if you can't turn on error reporting at the server via the php.ini on your development/testing machine for whatever reason.
  14. Lots of questionable design choices work. Just trying to put you on a decent path for your class work.
  15. For the limited scope you're describing, what you're using will - theoretically and for the most part - be fine. However, I think what requinix was referring to is that the password value should be coming from $_POST, not $_SESSION. When a form is submitted, the data is passed to the receiving PHP script via a $_POST array (or $_GET, but this has to do with passwords so ignore $_GET for now). $_SESSION is a completely different thing, typically used for different reasons entirely. So, instead of if(empty($_SESSION['password'])) you'll want if(empty($_POST['password'])) This is assuming the value of the 'name' attribute on the password field in the HTML form is 'password' - the name of the field becomes the value's index in the $_POST array.
  16. Prepared statements in WordPress are sprintf() statements. @SkyRanger - what exactly does the acikudos_table_name() method return? If it's the name of the table, wouldn't you just use that directly as I assume you know the name of the table you've created. If the database table prefix is dynamic you could always use "{$wpdb->prefix}table_name". Also, is there a reason not to create the kudos as a custom post type? It seems like it would alleviate a lot of the problems you're running into (you'd be selecting directly from $wpdb->posts, for instance), however as I don't know the business logic I don't want to suggest you burn a bunch of time on something that won't work for you anyway.
  17. I hope my post didn't come across too negative or ... jerky. There are so many ways that things can be done poorly in WordPress it's sometimes hard not to do things wrong. As you keep working with the code, post it here and ask any questions you may have. Let us know what plugin you're dealing with - somebody here may have personal experience with it or the time to do some digging into it, thereby offering better or more specific advice.
  18. Barand is right about the equality condition. $wpdb->get_results() returns an array, object, or null, so comparing any of those to an integer (or whatever is passed through $_GET['viewkudoid']) will fail. Beyond that, you're ... I'm sorry, but you're doing it wrong. If you're not going to use get_posts() or one of the internally-escaped functions to get the data you're looking for, at least use $wpdb->prepare() so you get something that might look like a prepared statement if you squint at it long and hard enough. Beyond that, if the plugin you're using has a function to return the database table name, there's a decent possibility there's a function to directly retrieve records safely through the plugin's API. Use that instead of directly injecting a $_GET variable into an unsanitized query string. Other than that, WordPress offers the query_vars and rewrite_rules_array hooks to handle routing, instead of using the kludgy '?{var}={val}' $_GET pattern; admittedly I'll cut a good amount of slack here as that is rather advanced and can be a bit touchy in it's own right. However, one thing that I kinda can't cut slack on is that if you're creating a shortcode, use shortcode_atts() - $_GET may not be set at all, and even if it is it shouldn't matter to the shortcode. Shortcode gets parsed inside the user content, regardless of the page the user is on.
  19. Also, you don't need to use a framework to use a templating language. Twig works just fine as an external library included into and called from a bespoke PHP solution.
  20. Good job - you've figured out the syntax issues with your query (I really do mean that sincerely). Now, before anything else, please look into prepared statements as you're using $_GET variables directly in a MySQL query. Then please google the performance pitfalls of running a 'SELECT * ...' query. As for the coach name, the PHP array from a MySQL query has no idea what table each index of each row in the resultset came from, so the MySQL aliases you set up don't help the PHP output. In other words, the array indexes 'c.coachFirst' and 'c.coachLast' don't exist. The array indexes 'coachtFirst' and 'coachLast' should exist, however.
  21. There are many issues with the code you've posted, but I think it'd be best to start by reconsidering your database structure. Learn about normalization. Once you've got a usable database structure, you can decide if you want to use mysqli (probably not) or PDO (probably), and then learn about prepared statements.
  22. Not gonna lie, I didn't realize attaching a target attribute to a form would do anything at all... There's obviously nothing wrong with your response kicken, but personally (just for readability if nothing else) I'd still seriously consider doing this via AJAX and opening the modal after the processing script returns the data, using a data-{whatever} attribute on the buttons to tell the processing script which logic branch to follow. I have, however, been accused of working harder than I work smart sometimes.
  23. I could well be wrong (as I said I'd just do it via AJAX and open the popup on data return), but I'm not sure you're actually doing what you think you're doing. Check the documentation: https://developer.mozilla.org/en-US/docs/Web/API/Window/open The first parameter to the window.open() call is URL - you're passing 'about:blank' as the URL and sending your form to process.php. Two different addresses, two different actions.
  24. I'd do the data gathering via AJAX, then open the modal window using JavaScript once the AJAX response payload has been delivered. Right now you're sending the form data to process.php while trying to pop open a new window with no actual data attached.
  25. This looks like your browser is set to remember form fields. You don't have a placeholder attribute set on the username field, and password fields don't support placeholder attributes (I think - I'm pretty sure that's true...) so the presence of text in that field is a sign that the culprit isn't what you think it. Delete the form data via your preferences.
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.