CUNY Academic Commons

Scott,

This is a weird issue. I can confirm that there are jQuery errors on the History Program's site. But I'm not yet convinced that it's the theme's fault. I'd like to propose some more plugin testing before updating the theme. Also, I cannot find the theme in the WordPress theme repo. I'm not sure if it's hosted there anymore. Which would explain why there's not an update notification in our admin. I found the theme on Github but there are no clear indications about what exactly the newest version is. I'm hesitant to upgrade to the Github version without first verifying this is indeed a theme issue. There are almost 20 other sites using the theme and we're not getting any bug reports from them.

Take a look at the GCEnglish site. They are using the slider and not experiencing any errors. This would also indicate a plugin related issue.

I don't see the slider on the History site. Have they disabled it because it's not working correctly?

I think we should work a little more with Tracy to rule out a plugin error before upgrading the theme. I did look through their plugins and didn't see any obvious culprits. I would suggest deactivating one plugin at a time until the errors disappear. That will tell us where the error is occurring.

Thanks Dom. I sent Tracy a note with your findings. Haven't heard back, but will keep you posted.

Hi Dom -
I received this from Tracy. I will ask her to join Redmine to address the issue:
From WordPress Help:

Thanks for the update, Scott. I noticed that the Arras theme slider seems to be working on other sites, so I’m really confused about why ours is not. I believe that other programs have more experienced tech people working for them–I’m a PhD in Renaissance History-turned-College-Assistant-for-the-moment that didn’t have experience with Wordpress or websites before the hurricane, so I apologize if I’ve done something in the course of trying to set up and configure this blog that threw the theme for a loop.

It is possible that there is a plugin conflict–although I already deactivated all of our plugins in hopes of fixing the issue (I did this before contacting you).

I have reactivated the non-functioning slider to help with diagnostics.

We have a sort-of, maybe related problem to the slider issue that could help suggest what is going wrong with the theme on our site: our Latest stories section of the main page is set to display 16 stories, which it does. But the layout has random gaps with blank space. I set the theme to display only 10 of the Latest stories, but the gaps remained (and I now have returned to our original 16-story configuration). Like the slider, at one point, the Latest stories section worked–it displayed stories in orderly columns (2 columns by 8 rows with no gaps).

Is it possible that I “broke” the theme by playing with it too much? I’ve even tried to switch to another theme entirely, then return to Arras (re-configuring the theme again) in hopes of getting a fresh start.

Many thanks, as always.

Dom, can you look to see whether Arras allows for custom cache locations? As in previous cases, I do not want to modify directory permissions like this if there's a way around it.

scott voth wrote:

Hi Dom -
I received this from Tracy. I will ask her to join Redmine to address the issue:

I'm here to answer any questions you have about our Arras settings.

Sorry Scott, I'm all caught up in cramming for finals. This issue is at the top of my list. I'll ave an update for you as soon as I can.

Boone,

I know we don't like to adjust permissions on a per theme (or plugin) basis. For good reason. Not sure why this one install is acting so weird compared to the other Arras themes, but I'll figure it out.

Thanks, Dom. And thanks, Tracy, for joining us here! I believe this now qualifies you as a Commons power user!

Thanks Dom - and good luck on your finals! I thought I was able to recreate the issue Tracy was experiencing - but upon retest, it seems that the slider is still working on my site (my bad.) I looked at the English site, and my own site (both of these work), and I don't see any javascript errors. But on Tracy's site, I do see an error. And it seems like it is happening within the WPNG-Calendar plugin's javascript. I think we made this plugin unavailable to new users, since the API changed, but left active for existing users. (I think we now have a new Google calendar plugin, but not sure?) - So I am wondering if you think that this might be causing the error?

Tracy - are you using WPNG-Calendar plugin? Or did you used to use it in the past, and replace it with something else? That might help Dom in debugging the issue.

Scott,

This is probably exactly what's happening. I didn't see the old google calendar plugin in her list of active plugins (it was my first thought). But I didn't take into account that we are hiding the plugin now.

If she is using the old google calendar plugin we need to deactivate in favor of the new one. I have a feeling this will fix our issue. I will find out the easiest way to deactivate the plugin now that we're hiding it and get back to you.

Tracy,

The WPNG-Calendar plugin is old and outdated, and has been replaced by a newer version from a different developer. Because it was already activated by a large number of users and was only causing problems on a select few sites we decided to leave the plugin installed and active on those sites. And instead "hide" the plugin from the rest of our users to prevent it's activation going forward.

I believe I will have to manually deactivate the plugin on your site because it is not visible in your list of active plugins, and therefore cannot be deactivated from the WordPress admin. I am right in the middle of my finals so I'm pretty slammed right now. I will be done on Wed, so I'll begin working on the deactivation Wed night or Thursday. It shouldn't take too long.

I will update everyone here once it's been deactivated and then we'll test to see if its deactivation has removed the javascript errors that are preventing you from using your slider.

Happy Holidays! :-)

Thank you, Dominic. I'm in a similar position with finals, and I'll be returning to New York shortly after New Years, so we're not in a rush to sort this out. Happy Holidays!

I'm back in New York, so I'll be in contact on Tuesdays and Thursday in January.

Boone,

I've been playing around in my local env trying to use a delete url to see if I can paste that url directly into a wp-admin session and have it deactivate the wpng-calendar.php plugin. Unfortunately it will only work when I comment out the code on line 108 of cac-functions.php which hides the plugin from the wp-admin. I believe deactivation of this plugin will allow the History Program to enable their slider and use other features of the theme without error.

The simplest fix in this situation is for me to comment out line 108 in cac-functions.php, push for tomorrows release and then add a note to ACTION_REQUIRED to deactivate the plugin on this site and then uncomment line 108 and push back up for the next release so it's not forgotten. We still want to continue hiding the plugin from future users.

If you know of an easier way to remove this plugin from this site without going through the edit/push/release round, let me know. If you've got direct access to the production sql db I guess you could just remove wpng-calendar from the serialized list of active plugins for this site. That might be a bit of overkill in a non-critical situation though. :-)

I've temporarily removed wpng-calendar plugin from the hidden plugins in cac-functions.php so I can disable it on this site. Once it's disabled we should be able to run the slider with no problems and I assume it will also fix the issue mentioned about the sidebar.

I'll post here once I've had a chance to look into the slider after 1.4.20 is released. ACTION_REQUIRED has been updated with a reminder to undue this change.

Commit: https://github.com/castiron/cac/commit/0a9ba1aaf9d6769f70a6346102cd43a8ef76b682

Thanks, Dom.

I modified your fix to make it more flexible and permanent. https://github.com/castiron/cac/commit/f42b2c75ad5ba4775b521ff4f0b1a690c8adcc7f

My reasoning: When we deprecate plugins, it generally means that we don't want users to activate them anymore. However, in most cases, it would be fine if users deactivated the plugins. So I added a check that says: if the plugin is active, don't hide it from the list.

However, there may be cases where we don't want users activating or deactivating plugins. For that purpose, I added an array of plugins that should be hidden from the list even when active.

I also added a switch that allows super admins to bypass filters: ?show_all_plugins=1

Dom, I'll still leave the necessary deactivation to you after 1.4.20 is live.

Very nice, this will make it much simpler to work with deprecated plugins moving forward.

Yes, I will handle the deactivation as part of closing out this ticket after tomorrow's release.

Thanks to you both.

Dom, the 1.4.20 release is live, and ready for you to do what you need to do. Go ahead and mark this ticket Resolved when you're done.