tallmanbrown

kbwood’s “jquery.countdown.js” v1.6.1 does actually work in Chrome, but you can’t just copy and paste it in to replace ujimoto’s version because it breaks the consistency of the timer styling across all the browsers.

I tried doing a side-by-side comparison of the code and cherry-picking the snippets that seemed relevant to the Chrome incompatibility issue (see https://github.com/kbwood/countdown/issues/6), but it had no effect and I couldn’t figure it out.

I guess we must either spring for ubisoft’s PRO version, wait for his update to the free one, or go for kbwood’s original countdown.

@edv_bruneck:

Indeed, I too would be interested in your adLDAP.php mods to get SSO. I’ve been running the previous Active Directory Integration v1.1.3 for a while now and would definitely move to ADAI v0.6 if it incorporated SSO. Any updates to this effect yet?

@dhkendall

I had the same problem when I recently updated to v1.4.9. I realize you fixed your problem using the [expander] shortcodes and their new formatting attributes, but for what it’s worth, I fixed my broken div code by removing the <div class="content_collapse_wrapper"> tags and leaving only my <div id="target-XXX" class="collapseomatic_content force_content_collapse">.

It seems the recent update has made it unnecessary and redundant, and only the single div reference is required now. At least that’s how I did it, and it’s working fine for me once again.

I tried (unsuccessfully) to modify the code in my ad-integration.php as suggested at https://bt.steindorff.de/view.php?id=3, but also with alexnolan‘s code modification above.

It simply killed my SSL authentication altogether. (For what it’s worth, my deployment is on a redundant 4-server web-farm running WinServer 2008 R2 and IIS7.5 with Windows Authentication.) Should I have disabled Anonymous Authentication when trying this? Is that why it didn’t work?

Thanks for your follow-up.

Normally, that would be IUSR, I reckon, but we’ve enabled Windows Authentication to restrict SSL and domain access only to our IIS, so I’ve discovered since posting my above inquiry that each individual domain user account accessing the website must have Read (and Write, if they want to post anything) perm’s to the folders.

That includes me, when I’m trying to update or execute a plugin. I just wondered how BackUpWordPress would execute after-hours when it’s on its own. Probably with the local machine’s IUSR account, which would fail because it needs to be [email protected], or something like that. A domain account of some sort.

Thanks for your feedback, anyway. I think I know what I must do. . . .

Yes, the problem persists, thanks for following up.

I have determined the conflict occurs between my Edit Flow and WPML Multilingual CMS plugins. I deactivated all plugins and then re-activated one by one, checking the Edit Flow groups after each. Nothing blocked my groups but the WPML main plugin.

Here are my groups without WPML plugin activated (the marqueed ones are the affected ones):

https://www.cpccims.ca/images/EditFlowGroups-All.png

With WPML activated, it blocks all but “Translators” group:

https://www.cpccims.ca/images/EditFlowGroups-WPMLBlocked.png

I have checked my WPML config extensively and cannot figure out why or where the conflict is occurring. But perhaps this inquiry more appropriately belongs in the WPML support forums. Any suggestions here, however, are still welcome.