maxxd
-
Posts
1,655 -
Joined
-
Last visited
-
Days Won
51
Posts posted by maxxd
-
-
I think you're looking for get_post_meta().
-
Quite honestly, ignoring the data retrieval issues you're having, there are several issues with the code you've posted. I'm not sure what your instructor is teaching, but he or she certainly shouldn't be advocating the use of mysql_* functions as they not only have deprecated for about a decade, they're completely removed from the current version of PHP. Hopefully he or she is also explaining the idea of data sanitation because you're dropping variables directly into your query, practically inviting a SQL injection attack.
I'd look very closely at the PDO library and prepared statements - if nothing else you may get extra credit, and you'll definitely get more robust, safer code out of it.
-
1
-
-
You can check the value of the field on submission with something like the following completely untested code:
$('#ap').prepend("<option value='-1'>This is the default option</option>"); $('form').submit(function(e){ e.preventDefault(); if($('#ap').val() == -1){ alert('Fill in the field, please.'); return false; } ... // continue processing }Of course, you'll want to check the value again during the server-side processing before you do anything with the value, like the also completely untested code below:
if($_POST['ap'] == -1){ throw new Exception('Fill in the field, please.'); } ... // continue processing -
You can, but it's a bit of restructuring. I'd suggest using the PHP to output the necessary values - in this case, loop, swfPath, solution, and title(s) - to an inline JavaScript variable or variables. Then you can grab that object from the included JavaScript file and use the variables there.
-
Get rid of the final closing tags on all your php files. Any white space after the closing tag will be output to screen and can cause issues in many different ways.
-
Any JavaScript in the HTML is in the global scope, and as such can be accessed from pretty much anywhere. Now then, that being said, putting the script inline is typically frowned upon as it breaks the separation of concerns principle of coding. You want your display code (HTML) in one spot, your client functionality (JavaScript) in another, and your server functionality (PHP) in another place. That way you're not wading through HTML to make changes to PHP or JavaScript.
So, with that out of the way, you can do this -
inline:
<script> function alertMe(){ alert('hi there, me!'); } </script> <script src='https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js'></script> <script src='yourJavaScriptFile.js'></script>yourJavaScriptFile.js:
$.ajax({ method: 'post', url: 'yourPhpScript.php', data: { 'key' : 'value' }, }).done(function(data,status,jqxhr){ if(stat === 'success' || jqxhr.status === 200){ alertMe(); } });yourPhpScript.php:
<?php echo('yup'); ?>Now, obviously you'll have an event of some sort trigger the Ajax call, and as soon as the Ajax call prints 'yup', the status will be equal to 'success' and jqxhr.status will be equal to 200. So, you should be greeted with an alert window saying 'hi there, me!'.
-
If the script is inline, it's in the global scope so you should be able to use it straight from your jquery file. Call the function name from the done() event of your ajax object - is this not working?
-
You would do the string replacement in your form processing method or function. Basically, you'll be doing what you're currently using SQL to do, but in PHP and before the record is inserted or updated in the database.
Something along the lines of:
$slug = $_POST['userSlug']; $slug = str_replace(array(' ','&','---'),'-',$slug); $slug = str_replace(array('"',"'"),'',$slug); -
As mac_gyver points out, it's difficult to give decent advice with no idea of the code context. You could do
$undeclaredVariable = ($a == $b) && ($c == $d);
However, this assumes that there's no additional logic for when $a != $b but $c == $d, or $a == $b but $c != $d, and that there are no additional assignments or operations around the logic for the setting of $undeclaredVariable. Depending on what you're attempting to use $undeclaredVariable for, you'll probably want to set it to false before you start your nest of conditionals.
-
That's entirely up to you. The roles imply permissions (unless you're also tracking permissions on a per-user basis, at which point the roles become a bit unnecessary) so which way you label it is a semantic decision.
-
Not, to be rude but, yes, I think you are missing something.
Not rude at all - it was a genuine question and thanks for taking the time to respond!
The reason to do this is it ensure that the super admin does not lose permission because the role based permissions are accidentally deleted, corrupted, whatever. Imagine the scenario where only the super admin has permissions to edit roles and somehow that permission got deleted for the super admin. There would be no way to resolve the issue through the application. It would require someone with knowledge of the application and access to the DB to create a query to manually add/edit the necessary records. This could be catastrophic if it were to occur when the application is mission critical. Sure, you can build the application to prevent such things, but those pesky business rules to mandate very narrow logic such as that are the ones that get tested the least.
Very true. I guess I rely too much on the idea that someone will be there with the system and database knowledge to fix a mission critical error. Which I really shouldn't do.
And - bugs happen.Well now that's just crazy talk...
Thanks for all that - interesting ideas and excellent explanation!
-
Hey y'all.
I'm trying to learn Drupal in an effort to steer away from WordPress, and I'm having some issues. Hoping someone here can help me out.
I've created a custom content type via the admin menus in Drupal 8. Name of the content type is 'Staff Member', machine name 'staff-member'. I added a content block in my myTheme.info.yml file called 'Staff', and assigned the Staff Member content to that block in the Structure > Block Layout page of the backend. I've created and uploaded a couple template files (page--front.html.twig and node--staff-member.htm.twig) to the server. The problem that I'm having is that the data I've entered as a Staff Member data type is nowhere to be found. My page--front.hmtl.twig template is as follows (simple enough):
<p>This is the front page. hooray</p> <pre> {{ dump(page) }} </pre>At the bottom of the dump, I see my custom blocks - including 'staff', which contains no data. If I change page--front.html.twig to the following:
<p>This is the front page. hooray</p> {{ page.content }}the page spits out some of the Staff Member data in the content section. Unfortunately, it doesn't appear to be using the node--staff-member.html.twig template to display the data.
Clearly I'm missing something here, I just can't figure out what that something is. Any ideas would be greatly appreciated as I'm starting to run thin on hair from pulling it out over this. I've found a trillion and four tutorials on creating a custom content type, but not one of them goes into detail about how to display the custom content type data...
I've cleared the Drupal cache a million and seven times.
-
What errors does it show?
The first thing I see from the code you've posted is that you're missing a closing quotation mark in your javascript (box.style.display="blocketurn";, but I'm assuming that's an error in the cut and paste as 'blocketurn' isn't a valid value for display.
-
As far as I've been able to tell, if you create a custom post type WP will sanitize the title and post content for you. If you create any additional custom fields on that cpt, you're on your own as far as validation and sanitizing. And given the fact that WP uses a consistent site address for all things ajax (both front- and back-end), making sure you set and validate a nonce in your cpt form is imperative.
I'm in Wilmington - from what I hear you've got a decent amount of snow right now, no?
-
One suggestion:
I assume the super_admin role would have full permissions and should never have limited permissions. So, you don't need to have any records in the role_permissions table for the super_admin. Instead, if the role is super_admin just assume all permissions are available. The reason for this is if any records from the role_permissions table were inadvertently deleted the super_admin could lose the ability to do things that no one has the rights to do. This basically ensure the system doesn't come to a halt.
You would likely have a service to check a permission for a user based on their role. That service would simply return true is the user is the super_admin instead of checking the role assignments.
Question on this set-up: how would you then differentiate between a super-user and an anonymous user? Because - the way it's occurring to me right now, and admittedly it's been a long day - is that the anonymous user wouldn't come back with a record from table users, so would have no permissions to store or check. If there are no permissions set up for super-admin, wouldn't that turn every anonymous user into a super-admin? Unless we're simply talking back-end stuff where the user would have to log in in order to see any of it at all; whereupon sure, that makes some sense. But even then, isn't it a better idea to enable an additional level of security whereupon you'd actively check that the super admin user has the permissions to do pretty much anything they want, rather than assume that a user with an active login session but no permissions is legit and not just partially hijacked?
Or am I just missing something blatantly obvious?
-
In your theme directory, there should be a file called 'functions.php'. There's more than likely a line toward the top that reads something like:
defined('ABSPATH') or die('No direct access, please');Add the session_start() line after that line and remove it from line 134 of the posted code. That should take care of the error, I'd think.
-
If you're using WordPress, your URL parameter is wrong. You should use wp_localize_script() to assign a JavaScript variable the value of admin_url('admin-ajax.php') in the body of your page. Use that value as the URL parameter in your ajax call, make sure you pass and validate a WP nonce in the form, and you'll be able to interact with the $wpdb object.
What does your PHP function (the one called on 'wp_ajax_del' and 'wp_ajax_nopriv_del' hooks) look like?
One more thing specifically about this code: your ajax call can return a success header, even if the database update fails miserably. All the ajax success() callback means is that the data was successfully received. You'll have to set a variable in the processing PHP script to let your JavaScript know if the database updated actually succeeded or not - check that value within the success() function of the ajax call.
WordPress takes a lot of getting used to, and even then it's not all that awesome. It does help speed up getting a site to the client by taking care of the admin basics from the get-go, but there are several to many hoops you have to jump through as a trade-off. If you're doing CRUD operations through ajax (or at all, really), make sure you validate and sanitize any user-submitted data - as far as I can tell, WordPress does not take care of this automatically, despite what some people seem to think.
Also, though WordPress doesn't actually support prepared statements (like I said, even when you get fairly proficient with it, it's not all that awesome), they do support a sprintf-like syntax kind-of prepared statement (not that awesome) that at least runs the submitted values through mysqli_real_escape_string(), so it's safer than just stuffing the value into a plain query.
-
1
-
-
You've got output before the call to session_start(). If I'm not mistaken, WordPress replaces shortcode at the point that it encounters it in the loop content. Which means there's the header file, and processing, all the HTML, and any post content before that shortcode that's output to screen before the session_start() call. I'd recommend starting the session either using the init hook, or at the top of your functions sheet.
-
That looks good!
With this setup, you can assume that all non-logged in users are role 'user', and those users that do log in successfully will get their roles assigned according to the role ID associated with their user record. Then you can check the permission or role_permission before any action is taken or restricted data is displayed.
Make sense?
-
Respectfully have to disagree with ginerjm.
I wouldn't set it up this way at all. You're duplicating a lot of information between the two tables. Is there a reason you don't add a user type column ('admin', 'public', 'superadmin', etc) in the Users table and then simply checking the user type and setting a permissions level based on that value? You can then drop the admin table entirely and replace it with a simple user type table.
Also, as long as you're using password_hash() and password_verify(), selecting the password from the database is perfectly acceptable, and will save you headaches while dealing with user passwords overall.
-
1
-
-
I agree with ignace regarding using only one table in this example. Parents, teachers, and students are all users. So, create the table Users and a secondary UserType table. This allows future expansion - for instance, let's say the higher-ups suddenly want to track grad students and undergrad students separately. Instead of having to create two more tables (Grad and UnderGrad), then figure out the SQL to separate out the current contents of Student, you'd simply add 'Graduate' and 'Undergradute' to the UserType table and update the foreign key in Users. And in a few months when it becomes imperative to track tutors as well as teachers, you add that key to the UserType table and start entering data.
'Doing things right' - to me - means trying your best to plan for future business logic changes during the design phase of your project. You're not always going to succeed; there are always going to be edge-case scenarios that pop up and make you rethink the design, and there are going to be situations where you over-plan. However, normalizing a database as much as possible and making sure that the data contained in a table is consistent and usable is going to mitigate refactoring both your SQL and PHP. I always say that the overall goal is to design and implement a system in such a way as to allow the maintainer of that system to be as lazy as possible.
Hopefully that makes sense - I'm only on my second cup of coffee yet this morning...
-
Have you tried
li{ position: relative; } li::before{ position: absolute; display: block; content: 'this is your content'; top: -50%; left :/* whatever */ transform: translateY(50%); }Theoretically, this should allow the content to remain at the mid-point of the li height regardless what that height is. May take a bit of tweaking, but it should get you started.
-
I have dealt with some database designs which complicate the PHP code and some which make it very simple. I don't know for sure, but highly suspect that the database design often has the same impact regardless of the programming language used.
To me, the major thing to remember is that the only way the database affects the programming in these situations is by being badly designed. The overall methodology of interacting with said database is going to be the same no matter what - for instance, "Grab an ID from this table, link it to a FK in this table, update the record in the third table that's defined by the FKs from table 1 and 2". However, when suddenly the FK from table 2 is actually an FK from table 7 that you have to get to by joining tables 4, 5, and 6; or the FK is actually a column in the current table that only has meaning when defined by magic joins to table 4, 5, and 6 - that's where the issues begin to happen. Again, the business logic is the same - it's the amount of time and cursing from the programmer that changes.
-
For examples and further discussion, I'd recommend Matt Zandra's book 'PHP Objects, Patterns, and Practice'. Personally, I've read and enjoyed the second, third, and fourth editions, and am looking forward to a fifth covering PHP 7.
Nested loop/array problem in PHP
in PHP Coding Help
Posted
The boolean false is from the var_dump(), so I assume the call to get_sub_field() is failing. The docs don't mention any kind of return value so it's kind of anyone's guess as to why... Maybe the get_sub_field_object() would be a better function to use? I've not used ACF in the past, so I'm kind of stabbing in the dark here...