VIPStephan

I’m getting the same notice (which can be disabled with the appropriate error reporting settings on the server). Also, the forms now add <br> tags wherever there is a line break in the form template.

Turns out, it is important to have double quotes in your theme.json file for it to work; I had wrapped all the property names and some values in single quotes and that won’t do it. At least I can now replace the color and font support settings in functions.php with the settings in theme.json. ??

I have the same issue. I didn’t have any theme.json file initially but these declarations in my functions.php:

add_theme_support( 'editor-color-palette' );
add_theme_support( 'disable-custom-colors' );
add_theme_support( 'disable-custom-gradients' );
add_theme_support( 'editor-font-sizes' );
add_theme_support('disable-custom-font-sizes');
add_theme_support('editor-gradient-presets');
remove_theme_support( 'core-block-patterns' );

If I comment out all of them the warning is gone; but then I have all these unwanted options in the admin edit screens. I thought, perhaps adding a theme.json file and adding these settings (or at least some of them) there would fix it but this file doesn’t even seem to be recognized and used by WP. Is there any other setting I’m missing? Is anyone else having this problem? This thread here is the only one I see coming up when doing an internet search.

This isn’t a fair review. It’s not the best plugin ever but it’s also not the worst plugin ever. And “everything is mismanaged” is also way too general a claim to make.

You can and will never get an accurate preview of an email layout because the support for HTML and CSS in different email clients is varying a lot, and therefore it’s impossible to predict how something will look in an email client. The preview can only give you a general idea. So this isn’t actually a problem with this plugin, it’s something we all have to live with.

I found the “custom CSS” field in the advanced settings but the documentation at https://www.thenewsletterplugin.com/documentation/installation/newsletter-configuration/ is very vague. What does that field actually do? Does it change the global newsletter styles or the styles for the editor? Because when I added some CSS to test, nothing changed, apparently.
And likewise, what is the “disable default styles” select doing? Which styles does it disable, because, again, I’m not seeing any change.

Well, the class names are there already, as far as I can see. Top-level items have a class “level-0” on the table rows, child items have “level-1” etc. It could even be a change as simple as

$pad = str_repeat( '<span class="dash">—</span> ', $this->current_level );

so that it could be addressed by CSS, e. g. to just hide it. I’m gonna suggest that.

Thanks. Sounds like that would make a good feature request (and I would think it’s not even too hard to just remove these dashes in the core code and have CSS do that job). And it seems like this is a relict of the very early days of WordPress where little thought was put into displaying post/category hierarchies.

It sounds like you need to change the domain that is stored in the database to your local domain. I’ve made good experience with Search Replace DB. You upload that to the web root directory of your site, load it in your browser, enter the string that you want changed in the database (the old domain to the new one) and all the DB credentials and it will change any occurrence of that string. Then you should be able to load the site on your local domain without issues.

There are different approaches to this; which one to take depends on your preferences/requirements.

1. You could delete the current live site and upload the new one. This would cause the site to be offline for as long as it takes which could be a major issue depending on the popularity of your site.
2. You could upload the new site to a new subdirectory, move the old site to another subdirectory and then move the files of the new site from the subdirectory to the root. The downtime of your site would be minimal, if done correctly.
3. You could upload the new site to a subdirectory on your live server and point the domain to this new directory. This will make the switch instantaneous.
4. Depending on whether the content stays the same structurally, you could also just upload the new theme and switch themes without changing the underlying system.

In the first three cases you’ll need to configure the system to use the remote domain (and subdirectory, if applicable), including all possible occurrences of the domain in the database (e. g. if there are absolute URLs in links somewhere), so that you don’t have broken links.

Yeah, I specifically wanted to avoid using category names because there is always the possibility that the client can change them while the IDs should stay the same. Thanks again, you pointed me in the right direction.

Well, you have to think about that: how would the parser know that you want podcast posts OR regular posts of a certain format? It can only fetch posts matching all of the options you specify. You would have to do two separate queries and merge them, I guess, but I’m not able to provide you any code. There should be something similar somewhere on the internet you could adapt.

OK, well, apparently a URL like “https://example.com/this-page-doesnt-exist” will only reveal the category_name query variable, because it basically translates to something like “https://example.com/index.php?category_name=this-page-doesnt-exist”, so get('cat') doesn’t bring up anything.

What I ended up with was retrieving the category ID from the category_name variable and using that to compare against:

function modify_loop($query) {
	if(!is_admin() && $query->is_main_query()) {
		$cat_name = $query->get('category_name');
		$cat_object = get_category_by_slug($cat_name);
		$cat_id = $cat_object ? $cat_object->term_id : null;
		if(in_array($cat_id, [7,8,18,23,24]) {
			// stuff
		}
	}
}

As far as I can tell this works.

Yeah, updating old sites is always a PITA. I’m not familiar with ionCube Encoder but is it an option to just disable that? As far as I read it’s only responsible for obfuscating PHP code, so just run it unobfuscated, at least for now?

Thanks for your prompt reply, @bcworkz. ?? I think I understand the concept now. So, you are saying I should rather do something like $query->get('cat') and then perform the conditional test on this result?