Joe Ponzio

Great discussion! We’ve built some very large, complex websites using WordPress, and have on many occasions brought in tons of third party libraries and code via custom themes and plugins, and I can’t remember the last time we’ve needed to call wp-load.php.

DionDesigns is correct – if you’re trying to access WordPress from another application, you’d have to call it. But if you’re building a WP theme or plugin, or otherwise using WP as your main framework, and you find yourself calling wp-load.php, there’s almost certainly a better way to do what you’re trying to achieve.

wp-load.php is used when WordPress isn’t loaded and you need it to do so. If you’re working in WordPress…it’s loaded ??

Here’s an easy fix for both the plugin author and you, dennislam. It’s important because this broken javascript is also breaking the “Quick Edit” feature.

In plugins/wp-custom-taxonomy-meta/includes/wp-texonomy-meta-scripts.js, declare enable as a variable after the jQuery document ready declaration:

CURRENT

jQuery(document).ready(function($) {
  if (enable) {
    var original_send_to_editor = window.send_to_editor;
  }
  ...

FIXED

jQuery(document).ready(function($) {
  var enabled;
  if (enable) {
    var original_send_to_editor = window.send_to_editor;
  }
  ...

You don’t include it in your plugin because it will already exist. The plugin is loaded when WordPress is loaded; so, you don’t need to call wp-load.php.

So basically any time your plugin loads, functions like site_url should already be available to your code when it executes.

The only time you would need to call wp-load.php is if you need to load WordPress in an external script and WordPress would not otherwise be loaded. But again – you’re building a WordPress plugin which only runs when the site is loaded up, so you don’t need to include wp-load.php.

I’m using site_url() below to link to your home page, but you can replace that href with whatever you want:

<span class="logo"><a href="<?php print site_url(); ?>"><img class="img-responsive" src="<?php echo $mt_logo; ?>" width="40" alt="" " /></a></span>

We build our themes and plugins using PHP classes, but I’ll exclude that so as not to complicate the issue…

Let’s say you want to integrate the Mailchimp API so that visitors can sign up to your email newsletter through your site, but you don’t want to send them to the Mailchimp signup form and you don’t want to use a plugin. There are many ways to accomplish this, but as an example:

You download the Mailchimp PHP SDK and put that into a folder in your theme (let’s call that folder mailchimp). Now, your theme folder looks something like this:

footer.php
functions.php
header.php
index.php
style.css
mailchimp/

When someone clicks your “Subscribe” button, you want to capture that information, connect with Mailchimp via the SDK, and then continue loading your site after adding the user to your list. To do this, you need to include (for example) the init.php file in the mailchimp directory when the form is submitted:

add_action( 'init', 'my_mailchimp_subscribe' );
function my_mailchimp_subscribe(){
  // If the form was submitted with the EMAIL variable
  // let's load the mailchimp file and add the user
  if( $_POST && is_email( $_POST[ 'EMAIL' ] ) ){
    // You're in a custom theme. If mailchimp is in a child theme
    // you'd use get_stylesheet_directory() instead
    require_once( get_template_directory() . '/mailchimp/init.php' );

    // Mailchimp is now loaded and we can add the user
    ...
  }
}

And that’s it. You can put whatever you want in your theme (or a plugin) and then include it when you need it. You could use WordPress hooks to determine when to include code and when not to so you don’t slow your site down, loading resources when they’re not needed.

What you’re dealing with is the 0.25em/4px margin that browsers automatically add to inline/inline-block list items. The solution you mention is possible by writing your own “walker” class for your wp_nav_menu() which would allow you to override the HTML of the list items before they’re printed to the screen. There are easier ways to address this, but if you insist on implementing the custom HTML solution, you want to look up writing a custom nav walker and calling it in your wp_nav_menu() call in your theme.

The other solutions are CSS-based:

• float your items left, which collapses the space between them
• set the font size on the ul to 0, and then set the font size on your li back to your target font size

Either one of these works extremely well, but I can’t recommend which you should use as I don’t know enough about your nav menu.

(Note: In response to the other discussion we’re having, your “hooK” here is actually being able to write the custom walker class which you would include in your theme folder and call from your functions file and wp_nav_menu() function.)

Oh I know. I wasn’t questioning/challenging your advice. I just wanted to point out to the OP that (s)he should start with that plugin before going the more drastic route of resetting the theme and deactivating other plugins.

A change in the URL may or may not go unnoticed, but different designs, navigation menus, layouts, logos, etc would be disruptions.

As an example – there are usually huge abandonment rates when sending people to a PayPal hosted checkout/payment page. It looks different, it’s not the design/style/font size/etc. they were used to and it breaks their mojo, causing confusion or introducing the opportunity for second guessing and buyer’s remorse before the purchase.

BUT, integrate with PayPal’s api, roll your own payment solution on your own site using your layout, fonts, etc so it is seamlessly integrated, and people will be more likely not to abandon.

It’s not that you’re more trusted or known than PayPal, it’s the interruption that snaps them briefly out of buying mode. That tiny “what just happened” moment introduces just enough doubt/hesitation/concern in people to cause more of them to abandon the purchase.

It’s UX and buyer psychology, and why I suggest that it comes down strictly to dollars and cents. If you’re going to sell $50/year of merchandise, it’s not worth the $101. UNLESS you know that you’re losing more than the $101 each year in sales.

Analytics will help you here. Do a good job of tracking what people are putting in their cart, how they’re navigating the site, and if/when they’re abandoning. If it’s happening during your transition to the other site for checkout (and happening enough to justify the $101/yr), you’ve got your answer.

If your application is on a different server, then you can’t use sessions but we’ve tackled this before too. So here are two scenarios based on the different use case:

SCENARIO 1: WordPress and Application on Same Server
Here you could use sessions for authentication with a few functions. This assumes you’re having them log in via WordPress:

// Start a PHP session
session_start();

// Set a session variable when the user logs in via WordPress
function my_set_session(){
    $_SESSION[ 'authenticated' ] = 1;
    wp_redirect( 'https://www.myapplication.com' );
    exit();
}
add_action( 'wp_login', 'my_set_session' );

// In your application...
session_start();
if( 1 !== $_SESSION[ 'authenticated' ] ){
  // User is not authenticated. Redirect to WordPress
  header( 'Location: https://www.mysite.com/wp-login.php' );
  exit();
}

SCENARIO 2: WordPress and Application on different servers
In this case, we’d create a user table on the Application with 2 unique hashes – authentication tokens or unique IDs, if you will. In WordPress, we associate those hashes with the user via add_user_meta.

// Sessions aren't needed on the WordPress side now
// because you're sending them to another server.

// Get the user's authentication token in WordPress
function my_set_session(){
    $user_id = get_current_user_id();
    $token = get_user_meta( $user_id, 'my_token', true );
    $app_user_id = get_user_meta( $user_id, 'my_app_user_id', true );
    wp_redirect( 'https://www.myapplication.com/check_login.php?token=' . $token . '&id=' . $app_user_id );
    exit();
}
add_action( 'wp_login', 'my_get_tokens' );

// In your application...
// I'd still start a session to keep checking the user's authentication
session_start();
if( $_GET[ 'token' ] && $_GET[ 'id' ] ){
  $wp_token = $_GET[ 'token' ];
  $user_id = $_GET[ 'id' ];

  // Sanitize the $wp_token and $user_id, and then check those against
  // the values in your database. If they match, you've got an
  // authenticated user and you can set an authenticated session
  // variable. Otherwise, redirect them to log in.
}

I prefer the double token/id combination because it makes two values that a hacker would have to guess, just like a username/password combination.

With a little creativity, you could harden this up even more but hopefully this sends you down the right path. Let me know!

The problem looks to be with the slideshow-gallery plugin so I’d go in via FTP and first rename/remove that one. That will deactivate it and should solve the error.

I’d consider that before blowing up the theme folder or other plugins.

WordPress uses the $post variable in the loop, and will use that in your the_tags() function. You’re overriding $post in your foreach loop; so, the_tags() is using the last post in your foreach loop as the $post to pull tags for.

Two solutions for you.

#1: Assign the $post variable to a temporary one, and then reset it after your foreach loop:

<?php
  global $post;
  $temp = $post;
  $cat_posts = ...
  foreach( $cat_post as $post ): ?>
    //Your foreach loop
  <?php
  endforeach;
  $post = $temp;
  the_tags(...);
?>

#2: Alternatively (and perhaps better), don’t use $post in your foreach:

<?php foreach( $cat_post as $article ):?>
  <li><i class="fa fa-caret-right"></i>...
    <a href="<?php print get_permalink( $article->ID ); ?>">
      <?php print get_the_title( $article->ID ); ?>
    </a>
  </li>
<?php endforeach; ?>

There is absolutely no recommended way of overwriting core files, and we haven’t had to do this in more than 7 years of working with WordPress. There are so many hooks it’s unbelievable, and anything that doesn’t have a hook could still be included in some way through custom PHP in your theme or a plugin.

This isn’t just moderators being tentative or holding back – there is literally no reason to hack the core on a production site. If WordPress really doesn’t achieve what you need it to, then it’s the wrong solution to the problem you’re trying to solve. (But we’ve also built some really advanced stuff in WordPress so that’s not always the case either.)

If you’re not good with coding, first check out your theme’s documentation to see if they’ve added an easy way for you to do this (maybe a full width page template or ability to change the row width). See here: https://accesspressthemes.com/documentation/theme-instruction-accesspress-staple/

Also, consider resizing/optimizing the image of the school. It’s 12 MB which is way too large to display on the web – particularly as design image. For how you’re using it, it should only be a few dozen or hundred KB. Right now, it takes forever to load, slowing down your site (which will ultimately frustrate your visitors).

Hope that helps!

If you disrupt the user experience, you’ll see a dropoff in conversions. So the answer to your question is another question: Will you generate more than $101/year in sales from the original site (without redirecting)? Or asked another way, will you lose more than $101/year in sales if conversion rates are lower?

A SSL certificate from GoDaddy is about $89/year and a dedicated IP from a good hosting company is about $1/mo, bringing your total spend to $101. Only you can answer whether or not the $101/year is justified, but I’d be inclined to recommend that you buy the SSL and dedicated IP address.

Check your site url and home url in Settings->General in your dashboard. They may still be set to the old staging url. If not, the next thing to check is the Appearances->Menus and see if your navigation menu is using hardcoded custom links for your menus. If so, delete those and drag over the actual pages you want in your navigation.