Forum Replies Created

Viewing 15 replies - 1 through 15 (of 32 total)
  • Thread Starter timmmmyboy

    (@timmmmyboy)

    It’s definitely a bit of an odd scenario for sure. #1 wouldn’t work because we actually do want the default value for the majority of users to be Author. We are trying to target a subset of users that won’t have access to the system (essentially graduates, terminations, and retirees at a school). Because there are different potential headers and values for various scenarios they figured the easiest way was rather than try to do multiple values (which I know isn’t supported and there were many values anyway) to just say “if this header has no value they are a subscriber, otherwise proceed as normal”. So to be clear all users will have this header passed to us, but a small portion may have it be an empty value and those are the ones we want to take action on both on first login as well as checking and updating the role based on that information. #2 sounds like it could work in that scenario so I’m going to give that a try. Thanks!

    Thread Starter timmmmyboy

    (@timmmmyboy)

    That worked! I had to change it a bit to match up the classes being used:

    #text-6 .textwidget {
      min-height: 600px;
    }

    But it worked perfectly. Thank you so much for being active on these forums and helping me out!

    Thread Starter timmmmyboy

    (@timmmmyboy)

    I ended up taking the location directive out and just adding this directly to the config which worked.

    rewrite /files/(.+)$ /wp-includes/ms-files.php?file=$1 last;

    Thread Starter timmmmyboy

    (@timmmmyboy)

    I had replaced line 16 in this order http://pastebin.com/BP2ekyf0 with the code but tried moving it to the top and it didn’t seem to change anything. If I put log_not_found on; in that server block I don’t seem to get any 404 reporting to the error log which makes me think that rule isn’t catching on the URL.

    Thread Starter timmmmyboy

    (@timmmmyboy)

    Still no go, on a positive note it seems whatever bug was causing files to download instead of render we’ve got fixed now. Nginx log still implies it’s looking at /var/www/wordpress/lansingstar/files/2015/05/20140908_124852_RichtoneHDR.jpg for the file.

    Thread Starter timmmmyboy

    (@timmmmyboy)

    Yeah, the file is definitely there. I assume I still have something wrong with URL rewriting (though I hadn’t tried loading it using ms-files.php like that).

    http://news.jrn.msu.edu/wp-content/blogs.dir/7/files/2015/05/20140908_124852_RichtoneHDR.jpg

    Thread Starter timmmmyboy

    (@timmmmyboy)

    I appreciate your willingness to help! I added that line the site seems to be acting like it doesn’t have a PHP handler, all files get downloaded instead of displayed. See http://news.jrn.msu.edu. Nginx rules are like a foreign language to me, though I do recognize some of the regex from .htaccess rules. Not sure what in that block would cause it to stop rendering files in the browser though.

    timmmmyboy

    (@timmmmyboy)

    Works like a charm. Thank you all so much for such a quick response to this!

    timmmmyboy

    (@timmmmyboy)

    Hmm, I’m assuming they wouldn’t even see the password recovery option unless they were using the bypass parameter? I’m thinking in our case this option would be necessary because after the user is no longer in CAS they will have no idea what their password in WordPress should be and it would be much easier to support by having them reset themselves and login rather than us having to manually assign and send a password to them. So I’d say yes keep the option for password resets.

    timmmmyboy

    (@timmmmyboy)

    +1 for this as well (a query parameter would work for us too). We have a system that we’re integrating with CAS but our users will have access for ~6 months after they’ve left our university so having a fallback option to get them into the system (or with a query parameter we could provide a special entrypoint) is a must.

    Thread Starter timmmmyboy

    (@timmmmyboy)

    Debug only shows a bunch of strict standard stuff from other plugins at the top of the page but nothing related to the theme stats plugin. The timeout is happening about 5 seconds after the page begins loading which is much lower than any php timeout would be set to (I think the server is set to 60 seconds for script timeouts). Not sure what else I could do to troubleshoot. I just get the page title “Theme Statistics” and a blank page underneath with no errors. :/

    Thread Starter timmmmyboy

    (@timmmmyboy)

    Nothing in the logs that I see. We’re doing some maintenance updates but once we’re done with those I can temporarily turn on debug and see if I get any printout in the screen. We have over 8,000 sites so I wouldn’t be surprised if that’s an issue, but I could certainly try to adjust php settings to see if I can make it work.

    Thread Starter timmmmyboy

    (@timmmmyboy)

    That made a huge difference! Thanks so much for such a fast response.

    Thread Starter timmmmyboy

    (@timmmmyboy)

    I had given a cursory glance but where are the SQL commands happening in the plugin? I can see what I can come up with and help you test it with our install. I’ll be watching the Github project as well.

    Same here, hope I can figure out what’s going on because this plugin is exactly what I need for a project I’m working on. Wonder if it’s a change with 3.7?

Viewing 15 replies - 1 through 15 (of 32 total)