xbladerunner

It works for me but I had to deactivate the gutenberg editor by activating the classic editor plugin.

I’m using in it on a multisite setup and it is working fine, so long as I have the gutenberg editor disabled via network activation of the classic editor plugin. Your use case is different than mine, so I can’t say for certain that what you want will work. FYI, when someone is commenting on a post on the “aggregated blog” of the main site, the comment form below the post is the bbpress form for the forum you’ve designated for that post — and the comment will be propagated into that forum. I don’t know if comments will properly be propagated to the designated forum if made on any site (child site) other than the main site.

This has been solved, thanks to back and forth with Yannick via email. Turns out that I had missing short code on my search page — one needs to have both the [link-library-search] short code, as well as the [link-library] short code to get the results to show up. I only had the search short code. Thank you for your help Yannick!

No success on my end, yet. Do you have a url you can share showing what your integration looks like? On my set up, following your config suggestions, links from link library show up in the search results, but clicking on them doesn’t take you to the link’s url… the url is overwritten as if wordpress is looking for a blog post, resulting in the viewer never getting the promised info.

I’ve tried it with and without my theme’s search.php page. What I’m looking for is a format very much like link library’s native search form results, but including additional post types for blog posts, bbpress, and downloads (from download monitor plugin). No joy yet with relevanssi.

Thank you Yannick, I have sent my library configuration file, from stefan.densmore at gmail. Let me know if you need anything else.

• This reply was modified 5 years, 11 months ago by xbladerunner.

Hi Yannick — any update on this?

Thank you, Yannick — have a great trip!

I was wrong. This plugin doesn’t appear to be causing the problem, sorry for any confusion. Further testing revealed that it is the asset optimization (compression) of the legacy theme css file by my caching/performance plugin that is to blame, e.g., when I don’t compress the css file the banner shows up fine on buddypress profile pages.

I updated to 6.0 and I’m having the same issue. No links are being displayed — instead I get a message that a category must be selected… I’ve reverted back to Link Library v5.9.15.7, and all is well. Thank you.

Resolved. The child theme was missing our custom download-monitor directory.

@markfeld, I had same issue and had to experiment with the x and y position settings until it showed up (turns out the default settings were showing up at the very top of the page (out of view of the browser window) and therefor went unnoticed until I started experimenting.

@mcgrathlaw, when you removed the picture did you do so in the visual or text mode of the wordpress editor? I’m just wondering as I removed the pictures using the text mode, to make sure I had captured all the associated code. But we could be experiencing different causes of the error.

What ever is causing the errors my site is generating, it does not seem to be interfering with any other functioning. I found this code that removes the error display (errors are still occurring but at least not displaying for everyone to see):

ini_set('log_errors','On');
ini_set('display_errors','Off');
ini_set('error_reporting', E_ALL );
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Put it in your wp-config.php file, replacing the line that originally reads define('WP_DEBUG', false);. Then at least your site looks ok as you continue to try to figure what the problem is.

I think I’m having the same issue (or similar) since upgrade to WordPress 4.4

I’ve noticed that a google search for Illegal string offset ‘file’ in functions.php line 3373 returns a lot of pages displaying the error — all appear to be recent happenings.

I’ve figured out that in my situation, the error only occurs on pages with an image, and deleting the image removes the error… but that’s not a fix obviously, just curious if your situation shows the same pattern.

I have several multisite networks, and this error is only occurring on one of them, so I’ve been trying to do the ole compare and contrast to identify the problem, no such luck yet. For me, it is only occurring on child sites.

I don’t understand what the error code itself means and haven’t found anything or anyone to generally explain it, which may be helpful in trying to figure out what is going on.

Figured it out.

Within your child theme, copy over all the files from within wp-content/plugins/buddypress/bp-themes/bp-default/

These should have already been copied over if you have been customizing buddypress at all on your site.

The file you want to edit to make buddypress docs full width is not in the buddypress docs plugin, but rather in your child theme now, specifically the wp-content/themes/your-child-theme/groups/single/plugins.php file. This file specifically gives directions to plugins that interface with buddypress groups — it tells them how to render the page.

Get rid of the following line <?php get_sidebar( 'buddypress' ) ?> found at the bottom of the document. To work with my theme, I also had to change
<div id="content"> to <div id="post-content"> found at the top of the page.

Now, that usually does it. But not with buddypress docs. There’s one more change I needed that eluded me for awhile (the reason I initially posted), and I still don’t like the solution required, but here it is:

You have to change your page.php theme file, as buddypress docs appears to be using it to render the “create doc” page. So move it from your main theme folder to your child theme folder. Once I edited that page to get rid of the side bar and comments option, buddypress docs was full width throughout the user experience.

Yes, very scary seeing error messages replace all the pricing tables on my live site after update. Even more scary seeing I couldn’t get access to your support forums on your plugin site. Glad you posted here with the quick fix. My pricing tables are pretty elaborate, so needed to bring them back up (using version 1.2.5) so as to reference them when creating new ones “from scratch” with version 1.3.0.