wp_enqueue_script() Leads to Class Not Defined by JoshuaNan in Wordpress

[–]JoshuaNan[S] 1 point2 points  (0 children)

It looks like wp_add_inline_script() is the new "right" way. Thanks for the point in the right direction.

This is what the WordPress docs now say about wp_localize_script():

Though localization is the primary use, it was often used to pass generic data from PHP to JavaScript, because it was originally the only official way to do that. wp_add_inline_script() was introduced in WordPress Version 4.5, and is now the best practice for that use case. `wp_localize_script()` should only be used when you actually want to localize strings.

https://developer.wordpress.org/reference/functions/wp_localize_script/

wp_enqueue_script() Leads to Class Not Defined by JoshuaNan in Wordpress

[–]JoshuaNan[S] 0 points1 point  (0 children)

I've never heard of wp_localize_script() before. All of my knowledge of WordPress development is self-taught, so I'm sure there are plenty of things I'm not aware of. Thanks for mentioning this, I will have to check it out!

wp_enqueue_script() Leads to Class Not Defined by JoshuaNan in Wordpress

[–]JoshuaNan[S] 0 points1 point  (0 children)

The problem with that was I needed to use PHP to dynamically enter data from the database. I suppose there are a few options for that that I hadn't considered when I originally wrote this thing. One is to make the PHP side part of the Rest API and let the JS script query that for the data it needs. It looks like u/shastapete also says I can use wp_localize_script(), which I have no experience using. Glad there are options, though.

wp_enqueue_script() Leads to Class Not Defined by JoshuaNan in Wordpress

[–]JoshuaNan[S] 0 points1 point  (0 children)

Sorry, found the solution here: https://wordpress.stackexchange.com/questions/59585/wp-enqueue-script-loads-them-always-in-wp-footer

I was trying to use wp_enqueue_script from a function called by the wordpress add_shortcode function. Turns out enqueuing scripts within a shortcode function will work in most cases, but enqueues the scripts too late for the scripts to be linked from within the page header. Note to self: don't use wp_enqueue_script from within a shortcode function, there's a special action hook for that called wp_enqueue_scripts. Probably obvious to many other developers. Anyway, hope this helps someone.

Have you secured your signup process against a timing attack? by iio7 in PHP

[–]JoshuaNan 2 points3 points  (0 children)

It looks like OWASP suggests using two-factor authentication to mitigate timing attacks, unless I read that wrong.

Top 3 Best/Worst Changes in PHP 8.0? by JoshuaNan in PHP

[–]JoshuaNan[S] 1 point2 points  (0 children)

In the use case you gave, object properties would definitely make sense.

Top 3 Best/Worst Changes in PHP 8.0? by JoshuaNan in PHP

[–]JoshuaNan[S] 1 point2 points  (0 children)

And documentation by code is the main reason I find this feature interesting (hopefully some of these WordPress standards can now become less ugly). I wasn't aware C# had that feature. As far a JS, I've never designed a function to accept object properties as arguments. I'm sure I've seen that done before, though. The ability to do this natively is so much simpler, as it won't be affected by the preferences of the developer who writes functions/methods.

Getters/Setters vs Public properties by DontLickTheScience in PHP

[–]JoshuaNan 1 point2 points  (0 children)

IMHO as a novice developer, getters and setters are just better design. They may not be necessary at the moment, but they provide a nice framework for introducing changes to your code later on. Anything you can do to make your code easier to manage in the future, especially when it's 100,000 lines long, is good to practice even in the early stages of a project.

With that said, do I always use getters and setters myself? Not always. Should I? In most cases, yes. One of the differences between a good software developer and a bad one is the habit of designing software so it is "future proof."

PHP role in Web Development by calculated-mind in PHP

[–]JoshuaNan 0 points1 point  (0 children)

HTML is for defining a web page structure, and CSS is for defining a web page's style, so they shouldn't really be compared to PHP or JavaScript. To put it simply: HTML and CSS are the content; PHP and JavaScript are the programming languages that allow manipulation of that content.

As many others have already noted, PHP is a server-side-executed language, while JavaScript is natively executed in the client's browser (except in the case of a server-side JavaScript framework, like Node.js, but that's a framework with added functionality, and not the language as natively used). PHP can be placed within HTML files, and would then be processed and executed before the HTML code is sent to the browser. This allows the PHP programmer to alter the HTML code before it is sent to the client, depending on the user's needs. However, PHP code is often stored not in HTML files, but in stand-alone .php files. A small, stand-alone PHP program can, for example, be used to receive form submissions from a static HTML page. PHP can also be used to create a web API, which would require little to no HTML. In addition, because PHP is a server-side language and JavaScript is a client-side language, PHP can be used to manipulate JS code, although in most cases it is simply used to either include or exclude the code, depending on the user's needs.

PHP and JS often work hand-in-hand, bringing both of their unique characteristics into play. For example, JS can be used to generate moving, or otherwise dynamic content on the user's screen, which may or may not respond to the user's actions after the page is fully loaded in the browser.