Lesson Recursively Opening Lesson Tab

Hi,

Please update version 2.1.6 then let us know if still have problem.

Regards,

Hien Phan.

I did the upgrade & nothing changed, but I’ve got a better idea what is happening now.

It may not specifically be a problem with the plugin, but will likely result in a code or documentation change. It is important for both of us to understand what’s happening because this is going to be many common cases. The issue is related to the nginx config & wordpress permalink settings, so basically anyone using nginx with any url customization could be affected, which is probably a lot of people.

The individual lesson attempts to load:

domain.ext/<course_page>/<course_name>/<lessons>/<lesson_number>/?content-item-only=yes

And this URL is not loading the individual lesson, it displays the entire document located at the webroot (basically “/”), which then gets some redirect to the courses/course/lesson page. The js checks for something on the content item, doesn’t see it and trys the same URL again (and again). This creates the recursive condition. It’s not producing any 404s, so it’s valid, but just wrong. So it seems that your code where the URL to display the lesson is created. Something is either hard-coded there, or a variable appears with no value.

I’m going to start with a fresh nginx vhost, and stock wordpress w/ LMS install with default URLs, then step through until the point this issue occurs.

We need to understand exactly what this URI should look like, where it is built, and what is the effect of anything coming from the db (courses page, category-base, etc) and if there is any part of that URI string which is hardcoded which needs to be a changed or accommodated in the nginx configuration in order to work properly.

I’ll update the issue here as I progress, unless you’ve got a better place for it.

Okay, after a little thought this issue was quickly resolved, but let’s understand it.

A visit to the nginx virtual host configuration file on several development servers reveals that the try_files directive provided for supercache prevents the passing of the GET string in the final request to index.php.

# Use cached or actual file if they exists, otherwise pass request to WordPress
	location / {
		try_files /wp-content/cache/supercache/$http_host/$cache_uri/index.html $uri $uri/ /index.php ;
	}  

I took a further look and found a number of popular “recommended” configurations for wordpress fail to include $args to the final attempt on index.php all over the place. Eg

#       Enable for vBulletin usage WITHOUT vbSEO installed
       try_files       $uri $uri/ /index.php;

Since the display of the lesson relies on GET “?content-item-only=yes”, any try_files setup which does not pass $args to index.php will cause the recursive condition to occur.

The solution in my case was to simplify this to

location / { try_files $uri $uri/ /index.php?$args; }

Which is fine for my environment. But shouldn’t be considered a copy/paste solution for anyone doing anything more complex with their try_files directive. Anything could be in there, and is there for a reason. The important part is to make sure $args are appended to index.php.

tl;dr LMS lesson display depends on GET, make sure $args are passed to index.php in nginx try_files directive. Lots of popular tutorials on the internet don’t include this. It’s easy to overlook.

hm, okay, I got this issue also. And unfortunately this is the only post reporting this issue.

I will try to look at my apache configuration (not using nginx here). It’s a multisite configuration.

Previously it works just fine. But not sure what did I change that create the recursive condition.

Will report it here
UPDATE:

1. Disabling all plugins, and activating only learn press still generate the issue
2. However, switching to other subnetwork, enabling LearnPress and creating a new course… this course works good

• This reply was modified 7 years, 4 months ago by Eko Suprapto Wibowo.