Support

February 26, 2019 at 9:35 am

Hi there,

Go to Dashboard -> Settings -> Permalinks.

What is it currently set to?

After opening the about setting page (you don’t need to do anything on the page), retry the link for your event, does it work then?

February 26, 2019 at 10:00 am

So this is your event? https://dev.setrac.org/events/symposium/

That’s no longer giving a 404 page not found, but there is an error being thrown on that page currently.

If you check the servers error logs can you see any ‘fatal error’ entries there?

Your host will usually have a section on the control panel that allows you to view any errors being thrown on the site.

February 26, 2019 at 12:43 pm

Ok, add the code shown here:

https://eventespresso.com/wiki/troubleshooting-checklist/#wpdebug

to your wp-config.php file and let me know when that’s done.

Are you aware you’re using a Windows server? Whilst some people do install and use WordPress on a Windows Server, its usually not a joyful experience for those users and I would highly recommend migrating the site to a linux stack.

February 26, 2019 at 2:55 pm

How far at the end is at the end? (I know, sorry)

It should be before this comment: /* That's all, stop editing! Happy blogging. */

But definitely before this:

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

Like so: https://monosnap.com/file/qgsn1vmf8jrpXbPY8rM4e3U1bSKYxq

Or, because this is a dev/staging site (it is, right?) you could just use: define( 'WP_DEBUG', true ); and it will display the errors directly on the page.

February 27, 2019 at 6:53 am

Hmm, ok, with the above, errors should be logged but they don’t appear to be.

Quick explanation:

// Enable WP_DEBUG mode
define( ‘WP_DEBUG’, true );

Tells WordPress to enable DEBUG mode, which basically means it tells your server to display all notices/warnings/errors on the page, you don’t want that set to true on a production site buts it is really useful on dev to see what errors are being thrown.

if ( WP_DEBUG ) {
@ini_set( ‘display_errors’, 0 );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );
}

Says, if WP_DEBUG is enabled (set to true), then…

Don’t display errors at all – @ini_set( ‘display_errors’, 0 );

Log the errors – define( ‘WP_DEBUG_LOG’, true );
(That logs the errors to w /wp-content/debug.log file)

Just to be double sure, use the WordPress constant to tell WordPress to tell the server, not to display errors – define( ‘WP_DEBUG_DISPLAY’, false );
(Yes a bit of a mouthful but it covers all bases)

Now, if your site can’t create the debug.log itself, the above doesn’t work, nothing breaks it just doesn’t log the errors, being a windows server, its common for it not to have the correct permissions so this may be why I can’t view the log.

This is what I would do next:

// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
//if ( WP_DEBUG ) {
//    @ini_set( 'display_errors', 0 );
//    define( 'WP_DEBUG_LOG', true );
//    define( 'WP_DEBUG_DISPLAY', false );
//}
/* That’s all, stop editing! Happy blogging. */

// are PHP comments, meaning anything on that line is ignored, you can just remove them and leave define( 'WP_DEBUG', true ); if preferred.

The site might ‘blow up’ with this change, in that if errors/warnings/notices etc are being thrown the site will look a mess whilst the above is acitve, it doesn’t break anything and once you change it back they will be hidden again (they are still thrown even now, they just aren’t displayed).

Once that’s done, let me know and I’ll check again.

February 27, 2019 at 7:26 am

Correct the site is now “the site can not be reached”

That’s actually not what I meant by the site blowing up and shouldn’t happen, theres a few possible reasons for that error:

https://stackoverflow.com/questions/14039804/error-330-neterr-content-decoding-failed

Problem is we are not getting into server config and I have very little experience with Windows server.

If you set WP_DEBUG back to false the site should show once again.

February 27, 2019 at 10:48 am

I’m glad its up and running, but that’s a little annoying as we now just don’t know the cause.

For whatever reason (although I’m not surprised) your logs reply was flagged as spam, so I’m only just seeing that now.

The errors you’re getting all link to open_basedir restriction in effect

Which means you host is set up to only allow specific directories to run PHP, so its likely that as soon as anything tries to pull a file outside of that directory, things are going blow up again and stop working.

I’d recommend you contact your host and have them slacken off the above restriction a little so that plugins can access their own code at least.