jafiwam
Forum Replies Created
-
Thanks for your detailed response.
We now believe that there must be a theme or plugin conflict specific to the site.
I found some other sites with your plugin and used IE (11 on Win7, Edge on Win10, and IE 11 on Win10) and it worked fine there.
The plan next is to disable plugins in various combinations and note any differences.
I will update to 5.3.1 before proceeding.
Unfortunately there are a large number of plugins and someone else is the admin, so it may take a while to get this accomplished. The theme (The7) is highly modified so there is a good chance some of the custom code is the problem too.
I will post again if I learn anything new. We did come up with a work-around to get the survey data we needed (with tablets and iPad and Chrome browser.)
Thank you!
Follow up. Using the debugger tools in IE shows it claims to find a syntax error in file “qmn_quiz.js” Line 91 Column 27.
That section of the file for that line deals with pagination. “initPagination: function”
The line itself:
step: (state, bar) => {
Not sure if this is the cause or not. With my limited JS knowledge, the line seems formed correctly.
Note, it works fine in IE when I view the demos. I am going to see about shutting off a bunch of other stuff in the same site and see if anything changes.
Update, it looks like it’s the entire “pagination display” DIV that’s missing from IE. (Which holds a horizontal line, the submit button, and next/previous buttons)
This seems to originate from a template “script ID tmpl-qsm-pagination”
- This reply was modified 8 years ago by jafiwam.
Forum: Plugins
In reply to: [Quick Page/Post Redirect Plugin] Redirection doesn't work on httpsUPDATE. I think I just solved this. Continuing on the post above, if I do this:
/help/?data=456 –> /url-for-help-file-456/
AND then have a second rule UNDER the first:
https://MYDOMAINNAME/help/?data=456 –> /url-for-help-file-456/
Then; if I do :
http://MYDOMAINNAME/help/?data=456
OR
https://MYDOMAINNAME/help/?data=456
They both get redirected properly. Not sure if that will help Jakub out or not but it’s worth a try.
I think this is a data-matching on the criteria problem. The domain and protocol seem to be looked for, but not used.
I was also able to do this:
/help/?data=456 –> /url-for-help-file-456/
https://MYDOMAINNAME/help/?data=456 –> /SOME-OTHER-URL/
Making a redirect behave differently depending on the protocol.
Forum: Plugins
In reply to: [Quick Page/Post Redirect Plugin] Redirection doesn't work on httpsHaving a similar problem.
WP 4.1.1
Redirect version 5.0.6In quick-redirects if I use:
/help/?data=456 –> /url-for-help-file-456/
It works in HTTP mode.
This also works:
/help/?data=456 –> http://MYDOMAINNAME/url-for-help-file-456/If I set it like this:
http://MYDOMAINNAME/help/?data=456 –> /url-for-help-file-456/https://MYDOMAINNAME/help/?data=456 –> /url-for-help-file-456/
The top one works, the second one doesn’t. (I know, it says not to use the full domain in there, however it does work.)
I’d like the redirect to not care what the protocol is and do the redirect anyway. The strange part is, if I reverse the order of the rules above, it’s always the first one that is executed and the second one (with the other protocol) is ignored.
One of two things is happening, either the way we have HTTPS implemented is causing one of the systems Redirect uses to be bypassed, or it stops processing rules based on the URL after the first slash and ignores the domain name. The fact that the rules change behavior when re-ordered makes me think it stops processing rules when it finds a match for after the first /.
My alternative method for doing the same thing (making help files for a program go to particular pages that don’t exist yet based on the context of the help button in the program today) is mess with mod_rewrite in htaccess.
Is there any way to get this tool to completely ignore the domain name and the protocol using just /file.htm > /file/ type redirects?
Forum: Plugins
In reply to: [Plugin Organizer] Works in Staging Site, but not in Production siteOops. Missed a paragraph. Our site uses HTTPS mostly, and is set to that. But also gets a lot of traffic in HTTP mode.
The error was showing up using an IE control from within a program hitting an HTTP page.
Forum: Plugins
In reply to: [Plugin Organizer] Works in Staging Site, but not in Production siteThe “Ignore URL Protocol” setting was on “enable”. I set it to “disable” and now the files where the plugin should be disabled appear to be working correctly. (That is, they no longer throw up the error we were dealing with.)
Our site, in the main settings uses “https:// …. .com”
That may be the difference here. The DEV site does not use SSL.
I am going to leave my configuration as it is and assume that was the fix. The setting doesn’t have much impact on administration for us so we are content to work with it as is.
Note however, we have had “caching issues” in the past where despite changing things (disabling or adding plugins, updating links in the menu, etc.) would stick around for a while. So it is possible that over night the cache cleared and the proper HTML/CSS was retrieved from the server. Our site runs on Genesis with Dynamik and then a customized theme which may contribute to the caching issue.
Thanks very much for your quick response and help.