Kyle Pott

Hey there!

To sum up, you’ve got everything working, but your last call requires passing in an an argument to the front end which clutters the URL. I’m going to assume your front end is a PHP page, but correct me if I’ve got that wrong. Also I assume you’re talking about unix cron, but can you clarify if you mean WP Cron?

Instead of calling the PHP function and passing the argument through the URL, have you tried adding one last line to your cron job that passes the argument in directly? This would be the same functionality, just moving your last call from the frontend into cron and then it would keep the URL looking clean.

/usr/bin/php path/to/frontend/index.php v=xxx

https://stackoverflow.com/questions/3872679/cron-jobs-calling-a-php-script-with-variables

Kyle

• This reply was modified 7 years ago by Kyle Pott.

Hello!

You can add this link to your main page.

http://example.com/wp-login.php?action=logout

Don’t forget to replace example.com with your URL. You can read more about this process here.

https://www.wpbeginner.com/wp-tutorials/how-to-add-the-wordpress-logout-link-to-navigation-menu/

Take care!

Kyle

Hi Clinton,

I’m glad you were able to recreate the error on another system. Can you provide me step-by-step instructions and I will try to reproduce the error again today? I would like to open a bug report for the main trunk of WordPress.

This defect has the potential to be a heightened concern – especially if the Gutenberg editor is interpreting text as SQL or as a script – that could open up other security concerns. I’m not certain that’s what’s happening here, but I would like to understand better what’s going on and escalate to the WordPress developers.

Thanks for following up Clinton.

Kyle

Hello! When I click your post I see comments are enabled at the bottom of the page.

http://www.thirdwaysober.com/welcome-to-third-way-sober/

Try clearing your browser cache and then check if you can see the comments box.

Kyle

Exactly what you described should be happening. However, when I click your ARTICLESCATEGORY menu item I get a blank index.php page instead of the WordPress page listing all of the posts with the ARTICLES category.

I think the issue is your life-changing-articles static page and your life-changing-articles category have the same slug. For debugging purposes, try changing the slug on your static page to life-changing-article-static-page and then check to see if your menu item behaves the way you want it to.

Here’s the issue you may be having.

https://wordpress.stackexchange.com/questions/32561/using-same-slug-name-for-a-page-and-category

Hi Lee,

A white page covering your wp-content folder is just fine. What you are trying to avoid is a scenario where the directory index is unprotected and an adversary can browse everything in the wp-content directory. You’ve got that protected so that is very good.

Your next question on 404 vs. 403 forbidden is more philosophical. Having the content protected is what’s most important. In my experience conducting penetration tests and security audits of WordPress, a 404 is probably more helpful for you, the site owner, because when adversaries see a forbidden directory they think, “this is interesting, let’s find a way in.” When an adversary comes across a 404 they think, “nothing here, better move on” and then they move to the next target in the attack chain. I’m sure there are other opinions on the matter.

If you’d like to implement a scenario like this, you can set your .htaccess to forward your 403 errors to your 404.php file. Please note, this isn’t an airtight method. Depending on how you implement it, advanced attackers will see the 403 return code in the header then the 301 call to redirect to the 404.php error trap page. A programmer more skilled than me may be able to suggest ways to mask your header return code using .htaccess. Here is an awesome guide that describes many different techniques to push your 403 to a 404.php error page.

https://stackoverflow.com/questions/10509849/always-return-a-404-when-you-decide-to-return-a-403

I really like the first approach outlined in the guide, first make a copy of your 404.php file in WordPress and rename it http-errors.php and then add these lines to the .htaccess file.

ErrorDocument 400 /http-errors.php
ErrorDocument 403 /http-errors.php
ErrorDocument 404 /http-errors.php

Adversaries will have a more difficult time ascertaining useful information from your error trap page.

Kudos to you for going through the effort to harden your WordPress install! Many people don’t. Make sure you’re practicing good password hygiene and not re-using passwords – especially for your admin account.

Best wishes,
Kyle

Hello!

The technique you described would certainly work – so you’re starting from a good conceptual way of thinking about it. Let me offer a few suggestions that would help you take advantage of the strengths of WordPress. WordPress is incredibly flexible and you can use plugins to assist with your migration.

Exporting/Importing
Since your current site has a similar architecture (PHP, MySQL) to WordPress, it is very possible to write a script that could export content from your current platform into WordPress. I would avoid the manual copy/paste routine at all costs. You can either do this directly through phpmyadmin as you’ve suggested, through a custom PHP page, or through a variety of other scripting techniques. I suggest making a copy of your current MySQL database tables so that you are working from a copy rather than the master, just to be safe. Alternatively, you might be able to scan the WordPress universe to find a plugin that would allow you to define the schema of your current site and do the export automatically for you. Sorry I don’t have a specific plugin to recommend.

Here is a link to the database schema for WordPress which describes how the back-end is organized for a standard installation. Focus on the wp_posts table which I believe is where you’ll do most of your work. https://codex.wordpress.org/Database_Description

Site Design
I would recommend importing each of your current pages as a WordPress “post” with the appropriately denoted category or tag.

Then the header menu of each page of your site would be the major categories or tags. By organizing your site this way you can avoid the manual work of using anchors. When you click on the menu the posts will all automatically appear and be sorted from newest to oldest. WordPress has an option for you to customize how many posts appear on the page and whether you want the whole post to appear or just the opening few paragraphs with a “read more” link.

I would rely on WordPress for menu design and content organization – it’s what WordPress does best – and it would get you out of the hassle of manually organizing the content. The menu, posts, and categories/tags are all native to WordPress and very easy to configure through the wp-admin portal once you have your posts imported.

Good luck with your project, it is very doable. I would be happy to answer any more specific questions you may have. Best wishes!

Kyle

• This reply was modified 7 years ago by Kyle Pott.

Hello! When I searched your source code, the first instance I saw of this set of characters occurred in the wpemojiSettings JavaScript – this may be the culprit. This guide suggests adding lines to your function.php file to resolve the issue.

// REMOVE WP EMOJI
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');

remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );