New answers tagged

1

It's actually a good question. Of course user input cannot be trusted, but also sanitizing the same value twice "just in case" isn't the best solution for a problem. The only real answer to this question can be given by looking at the code and following what goes on. And after reading it for a few hours, here is what I can say about it: WP Query ...


-1

I agree with 100% of the answers I read. Before starting any project or even reformulating what has already been done, ask yourself a question: How much is my work worth? Is it worth putting all the security of my project at risk? Would I be comfortable knowing that someone is tracking your site's browsing data without your permission? I would go further ... ...


0

I have a simple rule that I learned a long time ago when studying for fullstack development. If it's data/code that you didn't write yourself, always always always sanitize and validate it. Never trust data from anywhere, really, not even from established companies like facebook, google, github. Even if you think that wordpress will sanitize the information ...


0

I want to know if I have to sanitize user input for any of the other parameters. You should never trust user input, and therefore always sanitize and/or validate it, regardless of whether it is already done in core. Your code, your responsibility. As stated in the Theme Handbook, for example: Don’t trust any data. Don’t trust user input, third-party APIs, ...


0

Not especially, though I would disable it for your entire site if you have the option as a matter of general best practice. In a well maintained WordPress install, the contents of that directory aren't a secret, even if the directory listing is hidden. This is because you should never modify that folder, so it will always match the wp-includes folder in the ...


1

One approach (avoiding PHP timeouts) for a local Linux Cron Job (for exact timing) is creating a WP-CLI command (does not run in the browser), like: <?php /* Plugin Name: WP-CLI Foo */ function foo_command( $args ) { // Adjust to your needs ... WP_CLI::success( $args[0] ); } WP_CLI::add_command( 'foo', 'foo_command' ); and the corresponding ...


3

No, you don't need to escape hardcoded values. As I understand it, if the URL doesn't have an input via admin, it should be okay. Not necessarily. There's many more potential sources of potentially malicious (or just accidentally broken) output that need to be accounted for, such as: Translations. Query strings ($_GET) Cookies. WordPress filters. So ...


1

After thinking about this a little bit, I guess that the proper way to ensure that your comments are properly escaped, is by doing something like this: $the_comment = get_comment_text(); echo '<p>' . esc_html($the_comment) . '</p>'; Instead of simply using the function like this: comment_text(); Why even have these handy functions in the first ...


2

You can't. Any secrets you put into your pages or JavaScript can be read out of the downloaded files by the client. Instead, you probably want to either: Move the secrets into your server-side code and have your server code make requests to external APIs using the secrets, and use WordPress nonces and login cookies to authenticate your client scripts to ...


Top 50 recent answers are included