Turning on “headlines” will crash the Typography database

Can you post a screenshot of such a diff (or send it to me via e-mail)? I’d like to see what tables are changed and in what way to guess at which plugin is storing that data – it is definitely not wp-Typography.

Also, after turning of the setting, did you try to manually clear wp-Typography’s cache (there is button in the settings page)? Normally that should happen automatically on an config change, but if for some reason it does not, it should clear any remnants of the old settings from your object cache.

Also, to be certain, can you specify which setting change exactly did cause the issue?

Follow-up: Please list all plugins, you theme and the relevant versions. I’ve installed Elementor 3.18.3 in a test environment and have seen neither database changes nor crashes with wp-Typography. Disabling wp-Typography also rolled back any enabled typographic modifications (as expected).

I tried to clear the cahce several times, but it had no effect.

Disabling the Hedalines and changing back the fonts in website settings, did not work, too. I hat always to replace the database which was saved before I made these changes.

I think it does not deal with any other plugins, as it seems directly related to the website settings, which I figred out, now, with some more tests.

When I change the WP Typography plugin, to use “headlines”, too, the fonts get distracted as soon as website settings are changed. That’s why I did not realize it and made some work on the website, thinking everything would be alright. But always, when I change the website settings, the fonts of the website break.

The font settings will never crash, while “headlines” is deactivated, regardless from whatever I change in the website settings.

headlines on
01_ON-Headlines_aktivieren_test.ixtract_WP-Typography_.png
changing one title font from “normal” to “italic”
02_ON-Headlines_Website_Einstellungen_a?ndern_test.ixtract_WP-Typography_.png
All website fonts are broken (always on any change)
03_ON-Headlines_Broken-Fonts_a?ndern_test.ixtract_WP-Typography_.png

headlines off
04_OFF-Headline_test.ixtract_WP-Typography_.png
changing one title font from “normal” to “italic”
05_OFF-Headlines_Website_Einstellungen_a?ndern_test.ixtract_WP-Typography_.png
All website fonts are working (always on any change)
06_OFF-Headlines_Working-Fonts__test.ixtract_WP-Typography_.png

• This reply was modified 10 months ago by hirschferkel.
• This reply was modified 10 months ago by hirschferkel.

Hi @hirschferkel, thank you for the screenshots. I see that enabling hyphenation for headlines apparently breaks parts of your layout. That can happen, depending on how the theme uses certain WordPress functions (for a more detailed review, I’d need to be able to look at the broken layout with a browser myself).

What I don’t see is any evidence for database corruption. You said you made some database diffs that showed the changes? I’d like see a screenshot of that.

Also, I really do need a list of all enabled plugins and your theme to have any chance to replicate the issue. A WordPress installation is a complex system of interlocking parts and all included code matters. Of course, if you can replicate the issue in a minimal environment, that would be even better.

@pepe did you try it with your Elementor installation? I would guess, it will throw this error, too. In my guess it is not related to plugins or themes, but the core Website settings, which are used by Elementor itself.

It is really difficult and laborious on my side to investigate this further.

Settings and Plugins: All my settings can be seen here (System Info > click to reveal: https://github.com/elementor/elementor/issues/24893)

Website is https://test.ixtract.de

e.g. all lines with this code are missing after “headlines” is turned on and website settings are changed (Example):

"fonts";a:1:{i:0;s:6:"Nunito";}s:5:"icons";a:5:{i:0;s:12:"ixtract_some";i:1;s:12:"the7-feather";i:3;s:10:"fa-regular";i:4;s:0:"";i:5;s:8:"fa-solid";}s:20:"dynamic_elements_ids";a:0:{}s:6:"status";s:4:"file";i:0;s:0:

Screenshots with database differences attached (images are available for 2 weeks):

https://ibb.co/R387YvN
https://ibb.co/0C1XFY0
https://ibb.co/pLBrbpG
https://ibb.co/6ttjsBf
https://ibb.co/BNLDWnv
https://ibb.co/VDs6QM4

• This reply was modified 10 months ago by hirschferkel.

Hi @hirschferkel, thank you for the screenshots. I installed Elementor with its basic theme and activated both wp-Typography and Elementor. I did not see any error.

This is an interaction between your specific theme, your Elementor use/configuration and the way wp-Typography modifies the HTML content. The only “database changes” directly caused by wp-Typography are the _transient_type_* rows in wp_options. Everything else are Elementor settings my plugin has no influence over.

As for why things don’t immediately change back when wp-Typography is deactivated, the answer is probably “caching” – either in-application caching by Elementor or some additional caching layer outside WordPress (like Nginx Content Cache or some other form of reverse proxy).

I’ll gladly help you narrow things down, but you will need to provide me with a minimal environment that exhibits the symptoms (i.e. with as few plugins as possible and preferably with a WordPress default theme). However, I suspect the issue is really with your theme, which unfortunately appears to be non-FOSS (or at least not publicly available).

Thanks for your investigation.

Would it be helpful to provide you just with an account to my site? I could make a backup before and you could change settings as you want. I guess this would be closest to “my environment” ;D

But I do not want to bother you any way. So deactivating headlines is o.k. for me, as I can add manual breaks to them. But it is still a kind of not the best gut feeling because it might pop up again on any other chance …

Sorry, that’s not allowed for liability reasons.

Since AFAIK this is a test site, it would be best if you could simply deactivate all plugins (except Elementor and wp-Typography) and set a default theme and check if you still notice the issue. If not, you activate another plugin and check again. You do this until the issue re-occurs, then we know which plugins interact.

Alternatively, when you have only Elementor and wp-Typography and a default theme and don’t experience the issue, instead of a plugin you enable your regular theme. I am assuming you will then see the issue again.

It’s not allowed? What do you speak about. So far, there was never any developer, who had access because of all kind of bugs, to claim “liability”.

As I have access restrictions and will always reload the last backup, there is absolutely no reason why you should not get any access .. . anyway.

It’s your plugin causing the troubles.

All other plugins work like expected, so does the theme.

Best

(and there where much more lines in different database blocks, but much to laborious to get through them)

• This reply was modified 10 months ago by hirschferkel.
• This reply was modified 10 months ago by hirschferkel.

Asking for site access is specifically against the WP.org plugin guidelines and as far as I know that is interpreted as accepting the same as well.

I obviously cannot change your belief that you know better than me what my plugin actually does and how it interacts with other plugins and themes. It may come as a shock to you, but you are not the first person having issues while combining (random commercial theme) with wp-Typography.

wp-Typography tries to be mindful of WordPress API contracts, best practices and common idioms, but in the end WP combines all the code from all the activated plugins, the theme, and WordPress Core into one big runtime, so side effects are always a possibility, even none of the included components contain any bugs (and of course they always do, it’s software after all).

So the first step in debugging any issue is narrowing things down by excluding variables. I realize its a chore, but I am genuinely interested in helping you. To do that, we have to narrow things down. I know what pieces of wp-Typography are likely to break with certain kinds of input (the HTML parser when confronted with invalid or not well-formed markup), I also know what wp-Typography does not do (write anything to the database except options and transients through the WordPress API). So I do have a pretty good idea where things might be going wrong, but in order to not run in circles, we still need to do this systematically.

If you don’t want to put in the work, fine, but that’s neither my nor the plugin’s fault. You are getting free one-on-one developer support here, even though you are not my customer, so I really would prefer a more cooperative attitude from you.

(Also, in case this is a bit of a language issue, you can send me a message via https://code.mundschenk.at and we can talk about this in German.)

It’s not allowed? What do you speak about. So far, there was never any developer, who had access because of all kind of bugs, to claim “liability”.

This plugin’s developer is correct @hirschferkel. It’s not just their personal rule, it’s a rule for the entire www.ads-software.com forum system.

For liability reasons, you may not provide or request login information in any way shape or form on these forums: https://www.ads-software.com/support/guidelines/#we-reserve-the-right-to-manage-the-forums-to-the-best-of-our-ability

@moderator I was not talking about sending credentials to my website via this forum. So I had other things in mind. Thanks for clarification anyway.

Why are my comments moderated? I did not violate any guidelines so far nor did I get in conflict with any netiquette.

I did not violate any guidelines so far nor did I get in conflict with any netiquette.

https://www.ads-software.com/support/topic/turning-on-headlines-will-crash-the-typography-database/#post-17383161

And yet, you did:

Would it be helpful to provide you just with an account to my site?

https://www.ads-software.com/support/topic/turning-on-headlines-will-crash-the-typography-database/#post-17382447

Here is the guideline liked to in your earlier warning:

Common reasons for edits or suspensions include but are not limited to: Posting offers or requests for login information to a site.

https://www.ads-software.com/support/guidelines/#we-reserve-the-right-to-manage-the-forums-to-the-best-of-our-ability