Hello Themekey team and thank you for the help,

We had our server admin upgrade us from CentOS 6.3 to 6.6 as well as get nginx installed and our site is loads faster. We are using Drupal 6.34 atop MySQL 5.5.40 & PHP 5.3.29.

MySQL and PHP were not changed during this kernal upgrade process, but a ton of server packages were updated in the process (305!).

Site is back up now and everything is working great except ..... all our themes are wrong and blocks absent (blocks being theme dependent of course).

I've been at this for a few hours and am giving up. Themekey is 6.x-4.1 and has been in use for a good 4? years when we originally began using D6.

What is happening:
When I access /admin/settings/themekey Drupal seems to simply redirect to /admin/settings and our link for Themekey is no longer listed on the Site config page. So strange!

After the updates and our site was back up, I cleared cache, no themekey. I disabled Themekey in admin/build/modules, cleared cache, re-enabled themekey, still no themekey.

It is clearly checkmarked under admin/build/modules and enabled. We are also using Themekey UI and Themekey Properties 6.x-4.3. None of our public_html files were modified and I did a checksum on our existing Themekey with freshly downloaded Themekey and they are identical. Themekey is listed when I check for available updates (admin/reports/updates) as green/updated; Drupal knows it's there but it's config page and functionality has simply disappeared.

We are not using any sort of boost or other cache methods. I enabled error_reporting(E_ALL), ini_set('display_errors', TRUE), and ini_set('display_startup_errors', TRUE) in settings.php and get no errors. All other parts of our Drupal seem to function as expected as well as forum software on a few sub-domains we have. Essentially, as far as I can tell, everything went 100% smooth with this update except for Themekey.

I did read pages about early builds of Themekey having issues when pages are cached, but of course we've been using cached pages for years without a hitch. Our site admin said nginx acts as a reverse proxy so it shouldn't matter however this might depend on the situation. Searching for Themekey and nginx doesn't yield anything useful that I've been able to find...

I'm at a loss. I've searched and searched, can't figure out what's going on. Please help if you can and I'll reply back with any new information if I figure something out!

Regards,
BigMike

Comments

BigMike’s picture

BigMike CreditAttribution: BigMike commented
Issue summary: View changes
BigMike’s picture

BigMike CreditAttribution: BigMike commented

Update: Not a permissions issue (I'm logged in as uid 1 anyhow but confirmed its not appearing on uid 2 with permissions enabled either).

BigMike’s picture

BigMike CreditAttribution: BigMike commented

Update 2: Verified that Themekey's status in our system table is '1' (enabled).

BigMike’s picture

BigMike CreditAttribution: BigMike commented

Update 3: Verified the folder sites/all/modules/themekey is CHMOD okay (755) and owner is okay. Folder looks like any other module folder we have.

I'm starting to lean that something has been wrong for quite some time but it never got caught until we brought things up to date. Now any previously buggy server packages are fixed and catching something? We've been using our site all afternoon here and so far the only loss in functionality is Themekey.

BigMike’s picture

BigMike CreditAttribution: BigMike commented

Update

I had our server admin do some additional security and maintenance work while I was trying to troubleshoot this issue and out of nowhere our themes are fixed.

So it appears that Themekey is working..... However..... It is still not listed at Site configuration and accessing admin/settings/themekey or admin/settings/themekey/properties simply loads/redirects to admin/settings.

So it's great that our site can be used once again, but still need to get this sorted for when I eventually need to use Themekey again someday soon I'm sure.

mkalkbrenner’s picture

mkalkbrenner
Primary language German
Location 🇩🇪
CreditAttribution: mkalkbrenner commented

I never heard of a behavior like you describe. I just verified that the ThemeKey 6.x-4.x administration paths are working with php 5.3 and 5.5.

Can you have a look at the nginx server logs? What happens in the logs if you access /admin/settings/themekey ?

BTW if you added a reverse proxy you have to adjust settings.php accordingly!
Search for 'reverse_proxy' and 'reverse_proxy_addresses'.

BigMike’s picture

BigMike CreditAttribution: BigMike commented
Status: Active » Closed (fixed)

mkalkbrenner,

Thank you very much for the reply. We had a sessions issue appear on a customer support forum we have on a subdomain and got that fixed this morning, and just moments ago I discovered that we've lost functionality from a 2nd module, namely Ubercart Stock Notify (https://www.drupal.org/project/uc_stock_notify) (USN appears as check-marked & enabled at admin/build/modulesand and is listed as "Up to date" on admin/reports/updates, yet if we attempt to edit a node's stock via node/123/edit/stock, it simply redirects to node/123/edit and the link for "Stock" no longer appears on any of our Product-type node edit pages).

Therefore, since we now know this is no longer an issue isolated to Themekey, I am marking this as closed and am going to elevate this to Drupal's main Support forum.

Thanks again and I'll report back with a solution hopefully sooner than later-

Regards,
BigMike

BigMike’s picture

BigMike CreditAttribution: BigMike commented

I forgot to include that I asked our host about the reverse_proxy/reverse_proxy_addresses settings and he said that because we run our entire site as HTTPS (something I have not mentioned here until now) that traffic doesn't go through Nginx but directly connects to Apache.

So he believes that we should leave the settings.php as it was before.

Regards,
BigMike

EDIT: Created new thread to the main Drupal Support Forum: https://www.drupal.org/node/2419677

BigMike’s picture

BigMike CreditAttribution: BigMike commented

Update on this:

Got it figured out in a really bizarre way: It was a WHM new feature announcement message that I had been ignoring. Seriously. Just a news announcement. Read more about it here: https://www.drupal.org/node/2419677#comment-9585931

Regards,
BigMike