maxxd

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

What you're looking for is not the way WordPress search works by default. It does a straight string comparison - if the word(s) you typed in the search field are in the title or content of the post (or post type), WP will going to return that post record. Search for an Elastic Search plugin in the plugin directory - I'm pretty sure there are a couple out there.

You could also accomplish this with CSS using flex and order. It won't affect the actual data structure, which could present some issues with screen readers in this case, but if that's not a concern it'll get the job done.

True. Unfortunately, I think some newer folk don't know that what they're seeing is WP-specific code and not standard PHP.

Try the posts_orderby hook to alter the ORDER BY clause of the main query. More information here. You'll want to use is_search() to make sure you're dealing with the search query only. ginerjm, unfortunately this is the standard way of writing a template for WordPress. There are other ways out there (one of my favorites - Timber - allows the use of Twig templates), but they're non-standard and all depend on either a plugin or specific theme.

Typically this happens when PHP outputs an error. Check your console and see what the output is from the server. Looking at your $queryForCheckInLijst, it may be a SQL error - it looks like you've added a couple column names without commas. I haven't looked through the rest of the code, but that's a place to start.

Right beneath the live that reads //ADDED TO UPDATE change $node = new stdClass(); to $node = $result['node']; and see what happens. I'm assuming you know that the code presents a possibility for race condition issues, so you may want to make sure that either save_node() or EntityFieldQuery have some sort of safeguard in place. Again, I know very little about Drupal. Also, I'm not sure if it's just how the code pasted in or not, but formatting your code properly makes it much easier to read - I actually couldn't find where you'd instantiated $event in the foreach() loop until I'd copied the code, pasted it into my IDE, and formatted it. If it is just a by-product of pasting the existing code into the browser, then please disregard all of this last little bit.

Everybody here was new to PHP at one point, so that's not a problem! Please post your code as it is now. I think I may be a bit confused - did you add the code from reply #5 to the conditional branch where the event was found, or where it wasn't? The impression that I got before I posted my reply was that you'd added those lines to the 'true' branch of the conditional, and that may not be the case at this point. Basically, I don't see where you're getting the $node variable from if the event is found in the database. It may be Drupal thing (not terribly familiar with Drupal), but it seems to me that the record you want is stored in $result['node'], not in $node.

What did it accomplish? Anything at all? You're assigning a value to a variable and then doing nothing at all with that variable or value as far as I can tell. You have other issues with the code - you need to escape output, for example, not to mention that if you're just learning PHP it's a great time to learn a templating system like Twig as well, but as to your original question I'd start there.

Well, that escalated quickly...

If you're updating an existing record, wouldn't setting $node to the value of $result['node'] (in order to get the existing event record) make more sense than creating a new standard object - like you do when the event doesn't exist?

Actually, I feel like you've just proven my point. It's easy to dismiss the benefits of consolidating code when taking the simple and frankly rather inane example UML diagram literally, but when you expand to a real-world scope, it makes a lot of sense in some situations. While I'm not saying that abstract classes should always be used, I am saying don't discount them out of hand. In much the same way, I think interfaces are an incredibly useful tool as well, but they don't make sense in all situations and I don't think every class should implement one unless you really, really like typing and (potentially) maintaining the same code in multiple places. Or you're using a framework that builds them for you - I remember Yii would generate skeleton controllers and pretty full models automatically. I'm not using it now, so I don't know if it still does, and I don't know if that's a thing that most frameworks do these days.

But those very special assumptions are the interface. Poor class design (public properties, inflexible constructor, etc.) don't mean the pattern is useless or even bad. Sure, when you use a simple interface, the workings of the methods are up to the concrete classes, but then again they're entirely up to the concrete classes. In this instance, it's a pretty safe bet that both a contractor and an employee have a name. So in both cases, you'll be using toString() (which, in all honestly, should be getName() or something else that actually makes sense - again, it's bad design, not a bad pattern) to print that name. Why write that code in both classes? If the contractor happens to be a corporate entity, create a new CorporateContractor class and overwrite the toString() method there - you're only doing it once, and it's a specific and telling use case. Note the getSalary() method is abstract - if I'm not mistaken, that method has to be implemented in any class that extends from the Person class. So, in effect, it's very similar to your interface except that you're not writing and maintaining the same chunk of code in multiple classes.

If you're never going to use anything other than the HTML class, there's no need for an interface. Interfaces dictate consistency of functionality across your application. If a method is defined in an interface, the class that implements that interface must implement that method. This means that every class in your *VarDumper family will have a consistent API and you don't have to worry about which specific VarDumper you're using - just call the dump() method because you know for a fact it's there, and you know what parameters need to be passed and in which order. Another great thing about interfaces is that the implementing class inherits the interface type for use in typecasting. So, if you're working a class that makes use of a VarDumper class, you don't need to write a separate method for callCLIVarDumper(CLVarDumper $dumper){} and callHTMLVarDumper(HTMLVarDumper $dumper){} You'd simply use: callVarDumper(VarDumper $dumper){} Again, because of the defined interface, the master class doesn't really care what type of VarDumper it's using, it just knows it can use it and how to do so. However, all three of the above are valid and will work, so if you do need the specificity of calling a method to work with, for example, only an HTMLVarDumper you can do that as well. Hopefully this makes some sense - I'm only about halfway through my second cup of coffee...

My wife has an iPhone 6, and for some odd reason any images she'd post to Facebook for a while were showing up either rotated 90 or 180 degrees. No obvious rhyme or reason for it. Not much help to you, I know, but at least you know you're not alone with the issue...