maxxd

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 rude at all - it was a genuine question and thanks for taking the time to respond! 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. 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?

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.

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.

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.

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.

Only thing about using $_SERVER['DOCUMENT_ROOT'] instead of plugin_dir_path() is that the WordPress content directory can be renamed pretty easily, and if you've hard-coded the path from document root to the directory of your plugin (wp-content/plugins/MyPlugin/), it's going to break. Honestly, it's not like plenty of plugins don't already hard-code the plugin path (nextgen gallery, I'm looking at you...), but it is something to keep in mind.

The 'section' index is not within the 'attributes' array. Try this structure: foreach($catalog as $book){ $bookTitle = $book['attributes']['book']; foreach($book['section'] as $section){ $sxn[$section['id']] = $section['title']; } }

Are you having trouble with WordPress's plugin_dir_path()? What are the issues you're having with including files?

As long as you're not actively developing on a live site, you're good. What your plugin is doing right now is just flat-out printing the value of $wp_version. It's not actually doing anything, so where it's doing it isn't really all that important at the moment. The file where you put the WP plugin headers is your basic functions sheet - here you'll use WP action and filter hooks to let your plugin know what to do and when. So, if you're attempting to include some JavaScript you'd do something like the following: function myPluginQueueScripts(){ wp_enqueue_script('myPlugin', dirname(plugin_dir_url(__FILE__)).'/js/myPluginScript.js', array('jquery'), null, true); } add_action('wp_enqueue_scripts', 'myPluginQueueScripts'); The links I posted in my last reply will give more information on the wp_enqueue_script() function and the wp_enqueue_scripts action hook. WordPress has some ... strange behavior at times, and it has a million ways of doing some things. It's huge, a bit frustrating, and kind of a mess once you start poking around under the hood; so don't get frustrated (easier said than done, I realize), just keep Googling. There's a ton of resources on the web - some are good, some are not, and you'll have to use your judgement and some time to figure out which is which. That being said, you can always ask here.

Honestly, it shouldn't show up in admin, either. What hook are you using in your functions sheet? If you're trying to add javascript you need to use the wp_enqueue_script hook. You can find more information and a couple examples here. What's the full code you've written, including the plugin functions file?

Not sure why you'd recommend C# code instead of php in this case, but sure. PHP does have imagecopyresized() and imagecopyresampled() functions that should do what the OP is looking for.

Are you applying the plugin anywhere? It's hard to tell what's going on with the information you've given us - what's the plugin supposed to do? Does it use shortcode to create output? Is it a custom post type? Are you using the correct WordPress hook?

I've not tried it, but there's this - https://github.com/PHPOffice/PHPWord. Seems worth looking into.

The action parameter of your form is still 'thankyou.php', so the form is still pointing to that page. Remove the 'action="thankyou.php"' part of the opening form tag and it should start behaving as you expect.