Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by maxxd

  1. I know - I can't stand snake case, but if it's an array key or database *anything*, my fingers just type it that way. Database tables and columns actually make sense to me because I have a tendency to prepend table names with "tbl_". In case I get confused, I guess. But "tbl_student" or "tbl_orders" reads easier to me than "tblStudents" and "tblOrders". And once you've got that established for table names, you might as well keep it going for the column names because then you don't have to think too much or type different patterns in the middle of custom MySQL statements. It makes perfect sense. Really. The array key thing I can't even pretend to explain, it's just something I realized I was doing at some point. I may have been dropped on my head as a child.
  2. I align almost exactly with @kicken except I use snake case for database, table, and column names, and - for whatever random reason - array keys. Couldn't explain the array key preference if I absolutely had to as I really do hate snake case. Unfortunately, I currently work with WordPress so I have see that crap daily...
  3. Yeah, Jason Larke's answer is pretty much exactly what taquitosensei and I have been saying. No. The 'public statements' before the __construct() method are called object properties or object variables. The reason I'm passing in 4 random values is because the constructor signature calls for 4 parameters to be passed in; you've got The first 0 is now assigned to $role, the second is $tag, third is $location, and fourth is $job_id. They're not used in the class you've written, so I passed in nonsense values. There's a bunch of different reasons for having multiple files. The biggest is that AJAX is a client-side technology, but database interaction is a server-side technology. So you need to have the JavaScript file and a PHP file. The JavaScript is separate from the HTML file because if it was all in the same file you'd run a decent chance of breaking the functionality every time you change a DOM element. The PHP is the server-side file that actually gathers the data and prints it back to the AJAX call. Adding the lines above to the jobsDatabase.php file will automatically create an instance of the jobsDatabase class and run the getAllRoles() method of that object, which in turn prints the gathered data. Basically, you're dealing with a whole lot of moving parts with what you're trying to do. Given what we've talked about, I'll recommend again just stubbing in the data - instead of trying to use an additional PHP file to connect to the database and gather the actual data, just make up an array and print it to the AJAX call. In the AJAX success() callback, print that data to screen or console. Once you see the data you're expecting, move on to the next stage - in this case, populating the returned data in the form. From there, worry about actual database interaction. Hopefully at least some of that makes sense - again, it's been a bit of a Monday here.
  4. If that's all the code there is and you're not using a framework, then yes, you need to call the method on the object. Add this to the bottom of your file: $job_data = new jobsDatabase(0,0,0,0); $data = $job_data->getAllRoles(); die($data); Note that anything happening here is dependent on the contents of connect_database.php. While you're learning it may be a little easier to create a static array inside getAllRoles() and output that. That way you know everything is self-contained and you know what you're expecting. This should make it easier to track down any issues and errors in the process.
  5. Did you write jobsDatabase.php yourself? Are you using a framework or library?
  6. Right, and we need to see what the actual JSON string is. If you're using Chrome, select 'More Tools > Developer Tools' from the menu (option - command - uppercase 'i' on a mac, Ctrl + Shift + uppercase 'i' on Windows). You'll see the 'Network' tab along the top - select that, then trigger your ajax call. You'll see 'jobsDatabase.php' under the 'Name' column. Click it, then select the 'Response' tab from the details screen that appears. This will show you the raw JSON output, which may have a slightly more helpful error message.
  7. I just took a look at the code again. I missed the 'method' in your data set - so, yes it's possible that is all being handled behind the scenes and not something you need to worry about. (Sorry - it's Monday in a big way here...) So that begs the question, what does the response show in your browser's devtool's network tab?
  8. From the jQuery documentation: The AJAX call will connect with the script assigned to the url parameter of settings object. In that script is where some action has to take place. For instance, in WordPress you pass a field named 'action' in your dataset to admin-ajax.php. admin-ajax.php then uses the value of that field to know what PHP functions to call in order to get you the data you need. What taquitosensei and I are suggesting is that you add the following to the end of he script - after the closing bracket of your class definition: $job_data = new jobsDatabasee(); $data = $job_data->getAllRoles(); die($data); and change `echo $json` to `return $json` inside the getAllRoles() method. Before you do that however, what does the response header show in your devtool's network tab after the AJAX call has been made?
  9. What taquitosensei just posted is what I was talking about. Ajax is connecting to the file jobsDatabase.php and will parse that file. But if there's no action in the script (like instantiating the object and calling the getallRoles() method), nothing will happen.
  10. Couple questions here, but the big one is this: you are calling the jobsDatabase::getAllRoles() method, right? In your ajax target script (../../../components/jobsDatabase.php) you instantiate a jobsDatabase object, then call getAllRoles() on that object, right? If so, then yes, it might make more sense to return from the method instead of directly outputting (you'd have to dump the returned value from the instantiated object). At this point var_dump() $json after your while loop and check the network tab of your browser's developer's tools to see what the output is. If you're not doing that, then that would be the problem - you're never going to get data from a method you don't call inside and object you don't instantiate.
  11. The email files are located in the woocommerce/templates/emails directory - I believe you're looking for the customer-processing-order.php file. Don't change the files in the plugin directory, though, or any changes you make will be overwritten next time the plugin updates. Create a /woocommerce directory in the root of your theme. Inside that, match the directory structure of the plugin's templates directory and copy the file there, then make changes to that version. In other words, copy /plugins/woocommerce/templates/emails/customer-processing-order.php file to /your-theme/woocommerce/emails/customer-processing-order.php. Make the change in the version that's in your theme directory.
  12. Excellent point about unicode and non-printable characters. And while I do agree there should be at least some sort of warning to people that obvious usernames should be avoided, I'd also say the user roles should be relevant to the application, not user names. So 'admin' , 'moderator', etc. are perfectly acceptable user roles and user names because the one has no bearing on the other. That being said, there's nothing at all wrong with dictating which should be used for logging in - and doing so minimizes chances of logic errors during the process.
  13. I have to disagree with @requinix about this - I find limiting the characters in usernames ickier than checking against both the username and email addresses. There should only be one instance of the email and the username in the database - remember, that's one instance each and not a combination of both. So if either exists in the database and the password matches, there's a not insubstantial assurance that it's the correct registered user.
  14. According to the documentation, find() returns null if the requested object isn't found. So check for null before you attempt the children() call - right now you're checking if $lis2 is greater than 0.
  15. @cyberRobot - I had the same thought about the 'download' attribute, but looking it up on MDN it's a legit attribute.
  16. Actually, what you posted and what @micky007 posted aren't quite equivalent. Here's yours: echo " Download <a href=".$file_path." download>Here</a>"; When parsed, this turns into: <a href=path/to/file download>Here</a> True, technically attributes don't need to be enclosed in quotes (last time I checked - that may be wrong now), but it is generally considered a good idea.
  17. I haven't done any php DOM manipulation or parsing in quite some time and as far as I can recall I've not used the Simple HTML Dom Parser library (usually just use DOMDocument), but from the docs it looks this could be what you're looking for: foreach($html->find('li') as $li){ print("<p>{$li->first_child()->innertext}</p>"); } The first_child() of each list item element should be the anchor tag, and innertext should return the contents of that anchor tag. Unless I'm not reading something correctly - it's been a long day, so it's very possible that I am...
  18. Another option would be to record the package cost to the customer with the specific customer row. A 'current_rate' field or a many-to-many table with `customerID`, `planID`, and `rate` fields. This way you could give discounts or charge somebody more depending on what mood you're in.
  19. Give this a try: $li = $html->find('li'); print("<p>{$li[0]->children[0]->attr['href']}</p>"); and see if you can follow the track through the output of the var_dump() function. Then try this: $li = $html->find('li', 0); print("<p>{$li->children[0]->attr['href']}</p>"); and follow that as well. Coupled with the documentation and the comments above, things will hopefully start to look a little clearer...
  20. They weren't intended to be copy and paste solutions. They were a mashup of the documentation and your code with the goal of showing you how the function call needs to be made to get you the results you want. Read the code, read the documentation, then apply logic. As @gw1500se says, $str1 isn't a string, it's an object with some properties that are arrays and it needs to be treated as such.
  21. It sounds like you're determined to make each package option an element of a form the sole purpose of which is to select a plan, just so you can use $_POST to get the value the user selected. My point is that you don't have to deal with form actions or button elements - just make each choice a link. Style it however you want, then pull the selection from $_GET on the target page and go from there. It's not a huge thing, but it's slightly less typing and potential troubleshooting for you and, from a coding and semantics perspective, it makes more logical sense.
  22. Look at some sites using that method (InMotion hosting comes to mind immediately). They're mostly links to pages, not buttons in a form. It seems like you're introducing quite a bit of unnecessary complexity to a fairly simple pattern. If you really wanted to, you could always just set the package to a session variable on load at the target pages from the comparison links (I hope that makes sense).
  23. Take a look at how you're making the call and how the documentation makes the call. I've updated the examples a bit to make the comparison more direct, I hope. Yours: $li->find('a')->first_child(); Theirs: $li->find('a', 0)->first_child(); And the error message: Call to a member function first_child() on array And finally, the documentation itself states (modified for emphasis): Hope that helps.
  24. I got a message with the actual code we've requested here... OP - if you want help with the task, post the code here and let all of us take a look at it. More eyes = more help, but remember this is your homework. So we will help, but we won't write it for you.
  • 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.