Hi,

Thanks for your prompt response.

For some reason there weren’t any revisions to restore. However, I did make note of the post number that contains the footer settings after visiting “Cloud Templates” in the wordpress admin panel and then clicking ‘Edit’ in the footer template section. With the post number, I was able restore the contents of the footer post from a database backup.

The post number is the value for ‘ID’ in the “wp_posts” table in the wordpress database. I simply copied the content from the column ‘post_content’ from a backup and inserted it into the my database and the footer settings were restored.

I explained my solution for anyone else who may wish to restore footer items deleted by mistake. This works on all items as long as you have the post number.

That is not what I asked nor did that suggestion work. I asked WHERE ARE THE SETTINGS STORED FOR CHANGES MADE TO THE LAYOUT IN TAGDIV COMPOSER!? I made changes to my FOOTER that I want to revert. Changes to the footer are not stored in the post as I’ve restored the post and the changes were not reverted. I am asking a simple question, where are the settings stored for the footer? Is it the database, a file, where!?!

WHERE IS THE OPTION TO DELETE THE BLOCK CACHE!?! This is NOT appearing on the system status page per your instructions. This is absolutely needed. The block cache is currently showing stale results on my site and there is no way to clear it.

Before you even ask, the cache time has passed and the block still shows old results. It is absolutely the cache because the block shows the correct content when the cache is disabled.

I am running the latest version of the Newspaper Theme 12.6.3

The problem has been fixed. The solution for anyone else experiencing the same problem is:

“Please go to the theme panel -> block settings -> inline css and disable the option to minify the css.”

When will you have a solution? I am experiencing this on my site as well and I don’t want to disable recaptcha as a solution.

To troubleshoot further….. I disabled recaptcha through the theme’s panel and the leads plugin started working as expected. Which means there is something wrong with the recaptcha integration as indicated above.

It does not work. There is absolutely a bug in the coding as it states:

[DOM] Found 2 elements with non-unique id #g-recaptcha-response-leads: (More info: https://goo.gl/9p2vKq) <input type=​”hidden” id=​”g-recaptcha-response-leads” name=​”g-recaptcha-response” data-sitekey=​”KEY-REMOVED”>​
<input type=”hidden” id=”g-recaptcha-response-leads” name=”g-recaptcha-response” data-sitekey=”KEY-REMOVED”>

Apparently these elements should have unique id’s. This element is directly attached to the leads form that comes standard on the front page of Newsweek Pro. I experienced this error in both browsers Firefox and Chrome.

Hello Everyone,

I was experiencing the same issue and found a solution after monitoring the browser’s console and making changes to my webserver’s configuration.

The following error appeared whenever I went to edit a page with the tagDiv Composer:

Error at zones: 6(models) : 0(dom). The model does not match the content Current state has involved an issue. You could try an UNDO operation (CTRL+Z / CTRL+SHIFT+Z)

I decided to look at the browser’s console while the tagDiv composer page was loaded to see if I could find out what was causing the problem. I saw the following error in the console:

The loading of “https://www.mywebsite.com/tdb_templates/404-template-week-pro/?td_action=tdc_edit&post_id=89&tdbTemplateType=404” in a frame is denied by “X-Frame-Options“ directive set to “DENY“.

Apparently the tagdiv editor uses an xframe and my webserver (Nginx) was configured to deny all xframes. After visiting https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options and following the instructions I was able to get the editor working.

The specific configuration line in NGINX’s server configuration that was causing the problem was:

add_header X-Frame-Options “DENY”;

I deleted this line and replaced it with:

add_header X-Frame-Options SAMEORIGIN always;

After doing this I restarted NGINX and the tagdiv editor proceeded to work as normal.

• This reply was modified 3 years by mediagod.