the.mnbvcx

you mean like here?
https://www.ads-software.com/support/topic/granting-access-to-the-editor-role/

it seems your site doesn’t load fontawesome by default….

The most basic remedy should be to read https://fontawesome.com/get-started and include the stylesheet link in your theme.

The more advanced method is to download the package from fontawesome, upload the necessary files to your website (preferably in your child theme folder) and properly enqueue the stylesheet(s) in your functions.php like e.g.

function child_load_local_fonts() {
	wp_register_style( 'font-awesome', get_stylesheet_directory_uri() . '/fontawesome-all.min.css' );
	wp_enqueue_style( 'font-awesome' );
}
add_action( 'wp_enqueue_scripts', 'child_load_local_fonts', 100 );

YMMV

edit:
I just tried to use the fa-external-link icon and had to learn that this is only included in the Pro version of Fontawesome 5 – the free version only includes fa-external-link-alt
So either you buy the pro version or you modify wp-external-links/data/json/fontawesome.json accordingly (or fall back to an older version of fontawesome, 4.x should be ok)

• This reply was modified 6 years, 5 months ago by the.mnbvcx.
• This reply was modified 6 years, 5 months ago by the.mnbvcx.

OK, using local IP is probably indeed not the best idea, forget about that ??

IP addresses are considered personal data in various countries, that’s why storing them over a longer period might be an issue under GDPR. I wouldn’t take a bet that today’s privacy policies will be valid unaltered after 25 May when it comes to storage duration. GDPR requires the retention period to be as short as possible – for some, 60 days might easily be allowed, for others not. Having a possibility to configure that would simply add flexibility on the safe side here.

The reliability of GeoIP is another story, but for the time being this is what we have available. And it is way better than using language or other settings from the browser…
Anonymizing the IPs would be a compromise between complete loss and (possibly illegal in terms of GDPR) storage. Personally I wouldn’t allow an Antispam tool te delete retroactively simply because an IP address all over sudden appears on blacklists; either Spam is identified when it arrives or it will have to be cleaned up manually. Bigger sites might have other opinions here, that’s only my view. Maintaining partial IPs still reduces the number of possible spam posts when checking retroactively, in any case it’s better than having no IP at all. Finding the right balance between anonymizing the original IP and deleting it completely after some time will be a tedious and individual task for every WP site owner.
(I got inspired by Matomo (formerly Piwik) which already has an option to delete the last one or two octets from the IP before storing it in the database.)

Ooops.

That checkbox was indeed unchecked – and apparently works as intended.
My opt-out problem is solved, thanks.

I gave up further investigations after I discovered that everything was fine on the production site from which I had cloned the test site (on the very same server). The errors could not be reproduced by any means, I now simply accept the plugin working fine as all the years before ??

*bump*

same here. WP 4.8.3, php 7.1.11
Creating and editing questions is possible, just saving any options doesn’t work. All I can see is a record in the yop2_pollmeta table with meta_key “options” and empty meta_value.
Doesn’t seem to be related to php 7, I get the same under php 5.6

It’s a standard shared hosting platform w/ php 7.1.9, Apache 2 – nothing special.

But I think I will rest my case here (at least for a while) and simply reinstall the site; it was only a test version anyway so it doesn’t hurt too much.

And I will report back my findings.

Yes, the errors disappear with RWP deactivated.
On pages they disappear when the filters content and thumbnails are disabled, manual call of rwp_style still gives errors and generates correct css.

But I just downgraded to 1.9.7 and had exactly the same behaviour; seems it happens for a while longer – or the root cause is something completely different.

Laurence,
thx for the quick fix – applied it and indeed the error msg is gone.

Some more finetuning:
(1) add some custom background sizes in your (child) theme’s function.php for various screen widths; actually these sizes are independent from the breakpoints of your responsive theme:

// background sizes
add_image_size('bg400', 400, 9999);
add_image_size('bg720', 720, 9999);
add_image_size('bg1024', 1024, 9999);
add_image_size('bg1280', 1280, 9999);
add_image_size('bg1440', 1440, 9999);
add_image_size('bg1680', 1680, 9999);

(2) modify the inserted code: add the sizes to be taken into consideration

if(!empty($sections)){
foreach ($sections as $section) {
	$responsive_image_id = get_attachment_id_from_src( $section['image'] );
	if ( $responsive_image_id > 0 ) {
	echo rwp_style($responsive_image_id, array(
		'selector' => '#section-'.$section['page'],
		'sizes' => array('bg400', 'bg720', 'bg1024', 'bg1280', 'bg1440', 'bg1680', 'full'),
		'media_queries' => array(
			'bg720'  => 'min-width:  720px',
			'bg1024' => 'min-width: 1024px',
			'bg1280' => 'min-width: 1280px',
			'bg1440' => 'min-width: 1440px',
			'bg1680' => 'min-width: 1680px',
			'full'   => 'min-width: 1920px',
		)
		) );
	echo "\n";
	}
}
}
echo "<style type='text/css' media='all'>\n";

Here’s my workaround part 2:
(1) Install and activate the plugin Responsify WP
(2) copy the full function from inc/accesspress-functions.php into your child theme’s function.php and insert

if(!empty($sections)){
	foreach ($sections as $section) {
		$responsive_image_id = get_attachment_id_from_src( $section['image'] );
		if ( $responsive_image_id > 0 ) {
		echo rwp_style($responsive_image_id, array(
			'selector' => '#section-'.$section['page']
			) );
		echo "\n";
		}
	}
	}
	echo "<style type='text/css' media='all'>\n";

before

if(!empty($sections)){
	foreach ($sections as $section) {
		echo "#section-".$section['page']."{ background:url(".$section['image'].") ".$section['repeat']." ".$section['attachment']." ".$section['position']." ".$section['color']."; background-size:".$section['size']."; color:".$section['font_color']."}\n";
		echo "#section-".$section['page']." .overlay { background:url(".$image_url.$section['overlay'].".png);}\n";
	}
	}

w/o having checked it in detail I would assume that checkbox only triggers responsive layout (i.e. rearranging all visible elements to fit the screen size), but not responsive images.

First step towards a workaround or solution would be to wrap the original function in

if ( ! function_exists( 'accesspress_header_styles_scripts' ) ) :
function accesspress_header_styles_scripts() {
[...]
}
endif;

Thus it can be overwritten in a child theme.

What we mean under “responsive” is to have the image automatically resized so that it fits to the actual resolution and users can get the same view on their mobile devices.

Not exactly, at least that is not my point.
A responsive page does not send the full 1900*800 pic every time and lets the browser scale it down, but sends a fitting (smaller) image instead thus saving load time and bandwidth. WP does this since 4.4 for images inside posts, but not for css backgrounds.

OK, thx for the feedback.

As you have it on your agenda I will mark this topic resolved for now.

Look at the installation instructions:

In the plugin’s root directory you will find a folder called template. You can override that folder and any of the files within, by copying them into your active theme and renaming the folder to /yourtheme/wp_knowledgebase. WP Knowledgebase plugin will automatically load any template files you have in that folder in your theme, and use them instead of its default template files. If no such folder or files exist in your theme, it will use the ones from the plugin.

I would start with copying wp-knowledgebase/template/single-kbe_knowledgebase.php to your theme folder and edit (i.e. add the date) around line 54ff

<h1><?php the_title(); ?></h1>
<?php
     the_content();

to something like this

<h1><?php the_title(); ?></h1>
<span class="entry-date"><?php echo get_the_date(); ?></span>
<?php
     the_content();

(Untested approach as I haven’t yet done anything apart from installing and activating the plugin)

For hints on how to include the date it might be worth having a look at e.g. your theme’s content-single.php (assuming the post date is shown there)
Additional inspiration for dates is here.