I have installed the latest version of Gibbon to a subdomain, and I appear to have a problem with the actions of the Manage Courses module.
If I click on the links to other pages for course listings I can see the behaviour of the button change but no action occurs, not even an error message. The same thing happens if I use the drop list to change the number of listings from 25 to another value. I can filter subjects by year group and edit them there, but the link to clear the filter does not work.
I did try to enforce HTTPS on the subdomain (before adding data) and found that it affected the CSS stylesheet and the script to access the login page. I suspect that the Gibbon installation is designed for an internal server with absolute file paths and not relative paths. Would this be correct, and would my attempted HTTPS enforcement have corrupted the functions of the Manage Courses module? I don’t seem to have a problem with other modules at the moment, but I am only at the stage of setting up a clean production version for September.
The shared host is set to use PHP 7.1 as default and does not have PHP 7.0, but I can go up to PHP 7.2. What version was the latest release of Gibbon tested on?
You are right, Gibbon uses absolute paths (but not because it is for internal use). If you switch to HTTPS, or switch the URL, you need to update the absoluteURL (and sometimes absolutePath) settings with the System scope in the gibbonSetting table in your database. You can do this in Admin > System Admin > System Settings, but only if you load the page up before you make the change.
Gibbon v17 was tested mostly on PHP7.1, but also 7.2.
Changing the URL worked great. Login page now functioning correctly and the green SSL padlock appears next to the URL. However, I still have a problem with the Manage Courses buttons in the View block:
As you can see, Page 2 button border changes colour when clicked in Opera but no action. The Next button also follows a similar trait and the drop list does not update when a new value is selected.
I noticed that I set up Gibbon as a testing server, now changed to Production, and I have moved up to PHP 7.2 to see if that would solve the problem, still no change. I even uploaded the Timetable and Timetable Admin modules to overwrite the existing versions, ran a system check and everything is hunky-dory, and updated the MyISAM tables to InnoDB.
I experience the same problem with other browsers.
My only recourse may be to nuke the DB, overwrite the modules, install folder and main files, and start over again.
Good progress! These buttons using JavaScript and AJAX, and so I guess it might be a client side issue. I’m not sure we’ve tested much on Opera. Can you try in Firefox or Chrome and see if that makes any difference? If it is not working in those browsers, then you can use Inspect’s Console to see what is going on (not sure if this is available in Opera, if it is, try it there).
I agree, sounds like an AJAX script request is either being redirected or blocked. No need to nuke everything! It’s likely something small that needs tweaked or fixed.
Numpty alert!
I checked the page as you suggested and found links to JSQuery not working, then a little retrospective thought sprung to mind. When I uploaded files with Filezilla it wasn’t done in sequence; did I forget something, yes I did. No lib folder present. Folder uploaded and everything now working.
It’s likely something small that needs tweaked or fixed.