maxxd

Are you actually using a font named Bold? The rest of the CSS should be working, so make sure it's being included into the HTML - can the calling page actually find it? Add body{ background-color: red; } to your CSS sheet.

Set a cookie or local storage key when someone votes; check for it before you process a vote. Admittedly, if your poll is available for a long time this won't be greatly effective, but if you poll is only up for a day or so it could work.

Or you could be really tricky with it: <style> .circle-2-colors{ height: 0; width: 0; border-top: 15px solid red; border-right: 15px solid red; border-bottom: 15px solid blue; border-left: 15px solid blue; border-radius: 50%; transform: rotate(45deg); } </style>

Apparently the php.ini included in the repo was incorrect and the include_path had to be updated.

Hi y'all. I just inherited a legacy system that is in mid-rebuild but needs to be tended until it can be completely phased out and have run into an issue I can't remember how to deal with. The file system is as such: DocumentRoot/ m/ js/ css/ In the 'm' directory I have many files that use require_once as so: require_once "m/another_file.php"; The problem is that none of them have a $_SERVER['DOCUMENT_ROOT'] or even a __DIR__ to start the path, so I'm blowing up with errors. I know this code works as it's currently in production, but I can't remember for the life of me what php.ini or .htaccess setting needs to be set to make it viable. My coworker swears he didn't have to do any magic to make it work on his system. Anybody old enough to remember?

foreach() the way you're using it is going to pass each individual value of the array into the function body, so you don't need to reference $contacts[$var]. I assume the first value in your $contacts array is '18733', right? But there's probably not an index of 18733 in the $contacts array. Try this: foreach($contacts as $var){ echo $var.PHP_EOL; } You should see each value of your array on a separate line.

Post getTableColumns() and getTableData(). Looking at everything, it kinda looks like you're overthinking things - you want the column names as table headers and the data as the table data, right? That's not how your output is set up right now. It's going to loop through all the records in tableData and output the column names for every line of data. But you're not printing the data and it seems like there's no actual header row output. I recommend drawing out what you want to see on paper - map the source for every table cell, then write the code to make that output happen.

Look closely at the tag pair in this line.

If it's one or several predefined page(s), does the built-in password protection not work? It should limit access to either those users with a password or admin/editor permissions. If that doesn't do it, I think I used to use the 'init' hook to check if the user is logged in and any custom permissions associated with that login - it's run after 'set_current_user' so it should be good. Although, it may have been the 'wp_loaded' hook - sorry, it's been a bit.

What exactly are you expecting and what exactly are you getting? You say you're trying to understand functions - groovy. Functions basically work like this: you pass some parameters to a function when you call it (sometimes), and at the same time (most of the time) you assign whatever that function does with those parameters and then returns to a "local" variable. I put "local" in quotes because functions, methods, classes, and objects all have different meanings and potentially different scopes - which is another thing you'll want to look into as you learn the way this all works.

Mostly because WordPress runs (last time I checked) like 30% of the sites on the web, and WooCommerce is built by the same company.

I think you mean "pretty URL" or sometimes "friendly URL". Yes, you can do that with your .htaccess file, but it'll probably take some php coding as well. If you look at open-source CMSes and frameworks you'll get the basic idea - WordPress, Laravel, and Codeigniter are all examples I've personally used. Check out the .htaccess and index.php files, and follow the trail from there. You can also just google it and come up with plenty of examples.

Honestly, I don't know - as I said, I've never published my own eBook. If you're going the straight HTML route that's where the picture element comes in - it's not just the same image resized, you can specify completely different images for each media query break and not have to worry about downloading the other(s) first. So you can crop a screen shot differently for smartphone display than for desktop or tablet, and the media queries would call in the correct one.

I'm talking about media queries associated with the picture element, not CSS. There's more information here. I've not created any eBooks myself, but doesn't it handle the DRM natively? I'm pretty sure if I buy a Barnes and Noble book on my nook I can't just transfer the file to my wife's computer and open it - I think I have to be in another nook app and logged in with the same credentials. Although I'm not actually sure I've tried that now that I type it out loud...

Yes, people will read books of all types on mobile devices. My wife interacts exclusively using her iphone and ipad, and I'm currently reading a tutorial-style book on my desktop, surface, and galaxy phone depending on where I am and what I have on me at the time (and just to give some frame of reference, we're both older than you are so it's not just GenZ and Millennials). As far as javascripting goes, there are many drop-in libraries that only need the user to modify the image attributes in order to add lazyloading to the page - this one, for instance. And even then, you can use the picture element and media queries to display completely different images to different screen sizes (and to a degree devices, if you hack the media queries enough). Really, what you're concerned about isn't newfangled technology or practices, it's modern HTML. Assuming, of course, that you're building your website from scratch - if you're using a CMS it might be a bit more difficult. I know that trying to use the picture element inside a WordPress post is (or was about a year ago, anyway) damned near impossible. This is a completely unrelated thought and I'm not even through my first cup of coffee so please excuse it, but have you considered just offering downloadable PDFs of your tutorials? That way people know what they're in for before they click the link and you save yourself all this work - there's no need to worry about layloading and mobile performance and whatnot.

To add to the advice @requinix gave - optimize your images, make sure you serve the correct version of your image for the situation, and lazyload the images that are shown on the page. Shouldn't be a problem at all.

You can do exactly that; you just need to do some error checking and handling.

It sounds like you're saying that the DB connection is in the include file, but you'd like to not include the include file if the DB connection in the include file fails? You can't not include a file after you've included it, and you'll have to include it to see if the connection is successful. What's the actual issue you're dealing with?

Sorry - misread the question.

Yes, and that's what we've been saying since the beginning - don't pass the price from the form. Pass the product ID and use that to look up the price. Not gonna lie, I did not know that - thanks for the heads-up!

You can see and alter any of the page's html in the inspector tab of your developer tools. No.

Yes, every field has to have a name attribute for PHP to recognize it. So, yeah - it's a good point, depending on how you're pages are set up you'll probably want a hidden field to pass the product ID. My point was mostly don't pass the price for the product and assume that it hasn't been modified by the user. Which leads us to the next question: Sure - put this on your local dev environment: <?php if(!empty($_POST)){ print("<p>{$_POST['hidden_field']}</p>"); }else{ print("<p>not set</p>"); } ?> <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Document</title> </head> <body> <form method="post"> <input type="hidden" name="hidden_field" value="originally set!" /> <input type="submit" /> </form> </body> </html> Load the script into your browser and click the submit button; see where 'not set' changes to 'originally set!'? Groovy - now, open your developer tools from the browser and select the field with the 'hidden_field' name attribute and change the value attribute on that field to 'hacked, yo!'. Now click the submit button again. Without any sort of validation or server-side checking, the form happily passes 'hacked, yo!' to the processing script, and if that script processed a product price the user could easily change it to 0.00 or less. *edit* If they mess with the product ID.... well, honestly who cares? They'll just end up paying the correct price and getting a different product. It doesn't really help them out at all.

Pass a product ID and quantity to the order form, then get the product price from the database and calculate the total price at that point. These fields should both be visible to the user. You can use a hidden honeypot or nonce field if you really want to, but if you're charging money I'm not sure many bots would actually pay for something at random (though I could be wrong so don't quote me on that). The only time you should deal with the price on the server-side (other than for output purposes) is when the order is being completed - you need to make sure the user doesn't use the developer tools to change the price during the sale, but once the sale is made you need to track how much the product cost at the time of the purchase in case the price changes in the future (which it will).

Part of the reason jQuery became what it is is because of cross-browser compliance. You didn't have to do the `if(ie), else(everyone_else)` jig. However, as requinix pointed out, these days an AJAX call is pretty much an AJAX call regardless what browser you're using, assuming it's not an obsolete browser. Shoot, even fetch() is supported by everything except ie11, and I'm pretty sure there's a polyfill for that.

I remember we had issues with the Mojave > Catalina upgrade on our iMacs at my last job.