[Steven Zahm]

@ Jane

Good to hear things are normal again!

[Steven Zahm]

@ dean535

Yes, they will. If this is a new directory on the same site, there’s no need to add them again, once is enough.

If I have not asked and you have a moment, I would truly appreciate a review as they really do make a difference. Many thanks in advance!
https://wordpress.org/support/view/plugin-reviews/connections

[Steven Zahm]

@ kkthompson

Great to hear my solution worked for you!

If you have a moment, I would truly appreciate a review as they really do make a difference. Many thanks in advance!
https://wordpress.org/support/view/plugin-reviews/connections

[Steven Zahm]

@ Michael

Ahhh… yes. I immediately tested this and was able to reproduce it. My first thought; “Well, this is hokey!”

I did quickly find the issue though. As part of the search logic, I run the keywords thru the same list of stopwords that WP uses and then strips those stopwords from the search.

I give you one guess what one of the stopwords are. Yes, one of them is “will”, so when you search for “Will” it’ll get stripped and new results found. That explains why searching for “Wil” works.

I think maybe I should remove “will” from the stopwords … none of the others do not seem like they would interfere with searching for names.

Luckily this is fixable right now… here’s how:

Install the Code Snippets plugin.
Add a new snippet with the following code:

add_filter( ‘wp_search_stopwords’, ‘cn_remove_will_from_stopwords’ );

function cn_remove_will_from_stopwords( $stopwords ) {

if ( FALSE !== $key = array_search( 'will', $stopwords ) ) {

    unset( $stopwords[ $key ] );
}

return $stopwords;

}

Save and activate the new snippet.

And like magic, search “will” should return the expected results.

Apologies for the trouble!

If you have a moment, I would truly appreciate a review as they really do make a difference. Thanks in advance!
https://wordpress.org/support/view/plugin-reviews/connections

[Steven Zahm]

@ kkthompson

Yep, I see the issue.

The CN_IMAGE_BASE_URL has the http protocol rather than the https protocol like it should.

Inspecting the var dump of the $upload_info shows that protocol is https like it should:

array(6) { 
    [“base_path”]=> string(42) “/var/www/server/html/wp-content/uploads/” 
    [“base_url”]=> string(50) “https://server.gov/wp-content/uploads/” 
    [“base_rel_url”]=> string(20) “/wp-content/uploads/” 
    [“img_base_path”]=> string(61) “/var/www/server/html/wp-content/uploads/connections-images/” 
    [“img_base_url”]=> string(69) “https://server.gov/wp-content/uploads/connections-images/” 
    [“img_base_rel_url”]=> string(39) “/wp-content/uploads/connections-images/” 
}

This definitely had me scratching my head since they both use the exact same code to define the URL. Then it occurred to me after looking at plugin you’re using to set https on your site … that plugin must be running after Connections is initiated so CN_IMAGE_BASE_URL is set wrong but when the images source URL/s are created the Force SSL plugin has already initiated so the source URL/s are created correctly. Because of the protocol discrepancy, it fails a validation sanity check resulting in the error message you’re seeing.

If I’m right, there are two options to resolve this. My recommended fix is…

Since the Force SSL plugin is absolutely required by your site, you should move it to the mu-plugins folder. These are initiated before “regular” plugins. This will fix for all plugins and not just the ones that happen to load after it. This folder is in the ../wp-content/ folder. If it does not exist, just create it before moving the plugin. You can read more about MU Plugins here:
http://codex.wordpress.org/Must_Use_Plugins

The second fix is to define the CN_IMAGE_BASE_URL in the wp-config.php file. Add this to it:
define( 'CN_IMAGE_BASE_URL', 'path' );

Do not use path, instead use the path shown in the System widget for CN_IMAGE_BASE_URL, but change the protocol from http to https.

The down sides to this fix is image URL/s will always be https so if the site is visited in http you’ll have the exact same problem, just in reverse. Also the relative URL for the images will be incorrect but I’m not currently using the relative URL/s so it is safe for now, but in future versions???

Let me know how it goes.

[Steven Zahm]

@ dean535

Yep, makes sense. Now with all the CSS being loaded it is much easier to give you a proper solution.

I just uploaded an update to Slim Plus that contains a few CSS tweak that deal with some spacing issues. You can download it via your purchase history or if you activated your support license key on your site, which it does not appear to be, it’ll show up as a plugin update within 24hrs. I would recommend activating your support license key on this site so your receive updates.

This should fix the spacing. You also asked about making the character index larger… add the following to the theme’s custom CSS area:

#cn-list div.cn-alphaindex {
  font-size: 20px !important;
}

As far as not receiving the reply notifications … according to the email log, the notices were sent to your gmail account. Maybe they ended up in your junk mail???

Hope that helps. Let me know!

[Steven Zahm]

@ kkthompson

That NULL is the problem. This means the requested image source URL is not within the theme directory or within the uploads directory.

I still need the screenshot of the System widget on the Connections : Dashboard admin page.

On line 1509, add this and let me know the results:
var_dump( $source );var_dump( $upload_info );var_dump( $theme_dir );

Once again it’ll output a lot, but I only need to see the results of one series.

[Steven Zahm]

@ Kenneth

I’m assuming you’re using one of the templates which allow the user to filter by category, yes? If that is the case, use the category shortcode option.

It filter the results list by the defined category which will be overridden when the user chooses a category. It just will not show in the drop down that the category is the one that is selected. Hope that make sense!

Hope that helps!

[Steven Zahm]

@ Michael

The best way to handle this would be to enhance Connections to make the “view” pluggable. Connections already has the code in place to determine what to show based on the “view”. A simple example is the list (card) view vs. the detail view already in Connections. At first glance, it does not seem to hard to make this change while ensuring it is backward compatible, it would just take time.

With that in place, an extension could be created, that could offer the list view to the user. I’m thinking along the lines how WordPress offers a list view and excerpt view on the Posts admin page (those odd little icons by the pagination control).

Oh, looking at the DataTables Table plug-in. It does look like a way to retrieve entry data via AJAX would be required (it needs to supports pagination, searching and ordering) … trying to render a table and then have this plugin enhance it would be really, really, slow with thousands of entries.

The actual extension would require a settings screen in the admin so the columns (fields) could be selected and arranged in the desired order. The hard part here … since entries can have n-number of addresses, phone, emails and such would be how to handle that. My first thought would be to limit those to the preferred and it a preferred was not set use the first, basically limiting it to only one of each. Or, alternatively, just down all addresses (and such) in single columns with no sorting. Actually I guess both could be done, but might be confusing to have an adresses column and separate columns for city/state/zip.

If you would be interesting in sponsoring the required enhancements, I’d be willing to do the work. Of course I’d toss in the extension. I would need to write something to test the features anyway.

[Steven Zahm]

@ Jan

Thanks!

If you have a moment, I would truly appreciate a review as they really do make a difference. Many thanks in advance!
https://wordpress.org/support/view/plugin-reviews/connections

[Author]

Posts