Dutch van Andel

For some reason www.remarpro.com is serving the trunk/development build and NOT the official release tag. I’ve attempted to tag another release (several hours ago) in the hopes that the system will stop serving trunk and start serving a stable release, but so far the page hasn’t updated.

I’ll keep you posted, but this appears to be a glitch in the www.remarpro.com SVN release mechanism, as I’ve double, triple, and quadruple checked the release tags.

The latest stable release should be 1.4.5, which I released in an attempt to force 1.5.x off of the website. Hopefully the site is updated soon.

Yes, but you’d have to get your hands dirty with a bit of code.

There’s a few ways you could do this, but here’s some pointers:

1. Start by creating an appropriate hook in your theme’s functions.php file, or as a new plugin. You’d probably want to use the user_register hook.
2. Use CTXPS_Queries::add_membership_with_expiration() to automatically register new users to a specified group with a specified expiration date (this is located in contexture-page-security/core/model_queries.php.

Here’s some code right off the top of my head that may do the trick (totally untested) – you’ll need to check it to ensure the correct group id and whatnot suit your needs, of course.

add_action('user_register','autoregister_user',10,1);
function autoregister_user($user_id){
   $group_id = 3;
   $expires = strtotime(date("Y-m-d")) . " +2 week");
   $expires = date("Y-m-d",$expires);
   CTXPS_Queries::add_membership_with_expiration($user_id,$group_id,$expires);
}

Theoretically, the above will automatically enroll any newly registered user in the group with id 3, and that membership will expire two weeks from the day they registered.

Hope this helps.

Oh man, sorry it took so long to get back to you, I must have missed the email notice about this post.

If you were using one of the original provided theme functions (like psc_get_groups()), they are still available under controllers/theme-functions.php – just copy the functions you need right out of there and into your themes functions.php file and everything should work again. Technically they’re deprecated, so I’m not loading them in automatically… but they’ll still work.

If you want to rejigger things to use the new code, the method that handles this is CTXPS_Queries::get_groups(). This should be readily available for use in your theme files. To get an array of groups attached to the current user, just use this:

$group_array = CTXPS_Queries::get_groups($current_user->ID);

From there you could loop through and echo out group info like this:

foreach($group_array as $user_group){
   echo $user_group->ID;
   echo $user_group->group_title;
}

Hope this helps. ??

I can’t seem to reproduce this.

Have you tried disabling then re-enabling the plugin? Failing that, you can try a soft-reinstall, which fixes any corrupt files and usually clears up the stranger issues folks have had. Here’s how you do this:

1) Disable PSC from your WordPress admin (DO NOT DELETE as this will wipe your PSC data)
2) Using an FTP client, delete the /wp-content/plugins/contexture-page-security/ directory.
3) From your WordPress admin, go to Plugins > Add New, then find, install, and activate ‘Page Security by Contexture’.

This preserves all your existing PSC data while clearing up any issues caused by damaged or corrupt files. Please let me know if this solves your issue.

Best Solution:

Use array-formatted callbacks. For maximum compatibility, the above string-formatted static-method example should be converted to an array-formatted callback like this:

register_activation_hook(__FILE__, array( 'myClass','install' );

Here’s why:
String-formatted static-method callbacks are only supported in PHP 5.2+. To ensure maximum compatibility with earlier versions of PHP (I know, ugh), you should simply use array-formatted callbacks.

The first array value is the class, the second is the method.

ivanrojas,

BC oAuth may fit the bill. The first release was broken and had some incorrect service-specific implementations, but I believe the author recently updated it, so give that a try (mine is so heavily modified now that I’m going to stick with it instead of the official trunk).

If you have any problems with it, let me know and I’ll share some of the changes I made to get it to work (the more important Google-related ones are actually on the forum already if you check out the bc-oauth tagged posts).

I’m tempted to fork it to clean up some standards, UI, and usability issues – but the author has done such a spectacular job getting the oAuth libraries integrated with WordPress that I don’t want to step on any toes just yet.

In all honesty, I haven’t tested on MS at all – although I’ve had folks send me occasional MS fixes, and I’ve worked those in as I get them… so there’s definitely people using it with MS.

My first thought is that these are two most likely culprits (more detail to follow):

• The “Registered Users” group may be attached to the content or one of it’s ancestors. If so, the user would have access if there were no additional requirements.
• Server, MySQL, or WordPress caching may be preventing PSC from getting the most up-to-date data from the db. Try clearing your caches after removing the user, or try temporarily disabling any caching tech you’re running.

Here’s a little more detail that might help us figure out what’s going on and where:

When PSC determines access, it generates two arrays. One array contains the necessary permissions for the current page (including permissions for all ancestor pages), and the other contains the current users groups.

PSC then compares the two arrays, ensuring that at least one of the groups shows up at each requirement point in the permissions array. Each array is generated on demand from the permissions & membership data in the database – so in order to pass the security check, the user has to have a group record in the PSC relationships table.

Here’s some things I would run through, just for the purpose of collecting more info:
1) Create a new user.
2) Log in with that user and see if they can access restricted page (they shouldn’t – but if they can, stop here and let me know).
3) Add the user to a group and attach that group to a restricted page
4) Try to access the restricted page with the now-authenticated user (it should work)
5) Remove the user from the group
6) Try to access the restricted content again. If they can still access the content at this point, read on.

If you made it all the way to step 6, and the user can still access the restricted content, check for the following:
1) Do you have any kind of WordPress caching enabled? This might be saving the data from the group access query even after the database has changed. This means PSC would be checking against “old” data.
2) Do you have any database/php/server caching enabled? This also might result in “old” data being used in the security check.

If you suspect either of the above cases is true, then there’s some things you can try to confirm or debunk…
1) Disable the caching, or clear the cache after user check in step 6 and see if the access is removed afterward.
2) If you have direct access to the database, check the wp_ps_group_relationships table and ensure the user is no longer in the specified group. If the record isn’t there, it’s probably a caching issue… particularly if the user didn’t have access before they were added to the group.

I know that’s a LOT. But hopefully it helps. If you still have problems after trying all this, please reply and I’ll see what else I can do to help.

I’ve never encountered any bugs with the css override tool… but you never know what might crop up with all the different PHP configurations out there.

Here’s what I’d try… verify that the file exists at the URL the error message is reporting. For instance, if you paste https://domain/path/wp-content/themes/custom/style.css into your browser, does the CSS file come up? If you get a 404, then the error is correct and it cant find the file at that location. To fix it, you just have to ensure the file is somewhere in the WordPress directory, and provide a correct path to it.

Based on the example URL provided, this is where the theme is looking:

1. Site root /
2. The directory where WordPress is installed (WP not installed at site root)
3. wp-content/themes/
4. a theme directory called “custom”
5. A file called style.css

Is that correct?

1.5 is now available on www.remarpro.com. The pot file *is* included in this version, too. ??

Hey thefourd,

This is a bug with our theme. We’ve fixed it for the next release, but you can fix it yourself if you need this right away. Here’s how:

1. Open footer.php and find the line that refers to wp_nav_menu() (around line 10 – it’s a very small file).
2. Replace that entire line with this one:

   <div class="nav-horz nav-footer"><?php  wp_nav_menu( array( 'theme_location' => 'footer-menu' ) ); ?></div>

You should now be able to see the bottom menu.

I tried that approach and couldn’t get it to work. Take this line in TwentyTen’s header.php:

$image = wp_get_attachment_image_src( get_post_thumbnail_id( $post->ID ), 'post-thumbnail' ) )

If you change 'post-thumbnail' in wp_get_attachment_image_src() to ‘full’, nothing is returned. It seems that get_post_thumbnail_id( $post->ID ) refers specifically to the smaller, pre-cropped/resized featured image and so it can’t be used to fetch a different size of the same source image.

I could be mistaken, but so far I haven’t figured out how to use the featured image metadata to identify the SOURCE image and then fetch a different size for use in the site header (ie: ‘full’ or ‘custom-image-size’).

I may just need to spend more time acquainting myself with WordPress’s media functions.

So I’ve done a lot of digging around lately to figure this out, and it seems that even TwentyTen handles this in a way that will probably never work. Here’s what’s happening:

The header art and “featured image” art for posts are both preset to ensure they work with various layouts. Here’s the catch, there are two possible uses for featured images – and they seem to be mutually exclusive without a lot of extra work.

On one hand, you can have featured images appear in the loop – so they’re visible on blog listings and singular pages at the top of the post. This is our usage.

On the other hand, you use featured images to override the header graphic. In the case of TwentyTen and Adventure Journal, the size of the “featured image” will always be smaller than the header graphic, so it just plain won’t work up there – and the code that exists now isn’t really made to handle multiple simultaneous sizes for the featured image so we can’t really have both without essentially creating a big ol plugin for it.

So here’s how we decided to handle this:
We’ll be adding an option to Appearance > Adventure Journal that says “Use Featured Images as Header”. If checked, featured images will never appear in loops, but will replace the site header graphic on singular pages instead (when available).

Having these two usages be mutually exclusive isn’t ideal, but until I get a little more familiar with WordPress’s lower-level media handling, it’s the best I can think of without throwing a whole ton of work at it.

This feature will be available in 1.5 some time next week.

I just took a look at the repo and yup, the pot file isn’t there. Apparently I generated it, checked it off the task list, and never actually moved it to the languages folder. Sorry, this was a complete oversight on my part.

I’ll be absolutely sure to include it in the next release.

As an aside, we had planned to have AJ 1.5 out earlier this week, but got slammed with some 11th hour client stuff (and paying work always has to take precedence over our open-source projects).

P.S. I subscribe to the ‘adventure-journal’ tag on the forum, so I get an email any time someone posts an AJ-related question here. ??

enderandrew,

Yes, putting it directly above add_action('wp_ajax_bc_oauth', 'bc_oauth_init'); will work fine.

We’re on it. ??