No, it’s not related to the number of images. The sliders were working just fine until recently.
Here is one showing the same symptoms, with only 16 images:
https://forwardky.com/josh-hicks-hits-the-hustings-a-photo-gallery/
And if the number of images is a problem, why do they work correctly if I open Inspect?
Actually using both. I use some of the templates from the Standard Pack, and then have added a few cloud templates as well.
I’m very comfortable editing code. Just don’t want to have to hunt around for what to edit. 🙂
Yoast support sent me the PHP to add to have it show on the front end. I just need to know which file to edit to add it to the meta for posts.
Well, I don’t use Gutenberg, so was wanting to know which file in the Newspaper theme I need to edit to add it via code. I looked, and was not sure I found the right meta line.
I’m using the Standard Pack. Can you point me to the right place?
If the cloud templates are stored in a special post type, how do we edit the raw code? Go into the database itself?
Ah, I found them. They are saved as special post types. Harder to edit the raw code, though. Thanks!
Yes, thank you! That seems to have taken care of it. I really appreciate your help; I might have been able to get there, but it would have taken much longer. 🙂
I’ve gone through and checked the settings, and they appear to be correct. When I look in my Cloud Templates list, there is only one footer template, and it is Influencer. Both the home page and the global setting are set to it. And yet, it is rendered differently on posts than on pages.
I appreciate your help with this. At this time, I’ve spent enough time trouble-shooting, so I’m just going to let it go. Perhaps at some point I’ll have the time to re-import a footer template and rebuild from scratch. You can go ahead and mark this as Closed. Thanks!
Your first screen captures actually showed the problem I’m talking about. There is a gap above the menu word “Content” on all the posts, but no gap above that same word on the home page or on any other page.
It’s a very small thing, and not something I worry about. But, it bugs me not to be able to fix it. And of course, on a post, there is no “Edit with Tagdiv Composer” button at the top — only on pages.
In the Options table, I have hundreds of entries like this:
Option name – 116c6152cbdbe0eed30677feb095ba97
Value – 2720***/home/brumap/ForwardKY.com/wp-content/uploads/2017/01/636200799463033485-jeff-sessions.jpeg
I’m trying to figure out what caused them, and if I can get rid of them.
OK, found the problem, and need your help to fix it.
We use SiteGround for hosting. They have a plugin, the SG Optimizer, that hooks your site to their server-based caching, AND does a number of other things to speed up the site. Through the process of elimination, I found it was this setting that caused the problem:
SG Optimizer -> Frontend Optimization -> Defer Render-blocking JS (turned ON)
The setting allows for excluding scripts from being deferred. Which tagdiv script contains the code for the gallery? The drop-down list contains the following:
js_files_for_front
js_files_vue_modals
js_files_vue_modals_last
js_posts_autoload
js_files_for_live_css
js_files_for_plugin_live_css
ace.js
ext-language_tools
ext-searchbox
tagdiv_theme
OK, I switched it back to the tagdiv gallery.
https://forwardky.com/atlanta-visits-breonna-square-a-photo-gallery/
Same behavior: works in Chrome, doesn’t work in Safari.
I did some more digging, and realized there is a comments.php in the Standard Pack (which I am using). I tried editing that, and got close. Trying to track the build of the comments form through multiple PHP files is tiresome, though.
It appears that the code I showed you is ignored by the Standard Pack comments.php. I’ll keep working on it.
I’m using Newspaper 10, and the standard post styles that were there in Newspaper 9. Not using a cloud template for posts.
The code came from WP Beginner: https://www.wpbeginner.com/wp-themes/how-to-style-wordpress-comment-form/
I added it to our custom functions plugin, but it doesn’t seem to work. As I said, I suspect it is because Newspaper uses another term for the comments area, but I’m not sure.
Try using Molongui Author plugin. We’ve used it for a long time with Newspaper, and very pleased with the results.
Still didn’t get an answer to my two questions above:
1. If we move to all cloud templates, are we still not dependent on tagdiv? The templates use their own shortcodes, correct? They don’t actually implement HTML that will remain if we change themes, right?
2. Imkinc, what was the difference in the test you ran?
I have installed v. 10 on a staging site, and began looking at the work to remove all the v. 9 pieces. It’s not horrible, but it’s a bunch of work, and I’m not sure I want to take it on. If I’m going to do that anyway, perhaps I need to look at another theme. Ugh.
I think caching is making the difference. I am seeing a huge difference between the views shown in both the backend and frontend, and what my analytics tool is showing.
The analytics tool uses Javascript, which executes every time the page is viewed whether it is cached or not. I think that WordPress/Newspaper uses PHP, which is cached and not executed.
Well, I took the drastic step of changing to the Twenty Twenty theme, and the problem went away. So, it seems to me that there is something in Newspaper 9 that is causing the problem (or, some interaction with Newspaper and a plugin).
Late tonight, I will disable all the plugins and see if the problem disappears. Will let you know what I find.
Note that the problem goes away if I resize the browser window to force a redraw. But, if I refresh the page at the new size, it returns.
So that code isn’t some sort of CSS thing added by Newspaper?
Thanks for the long and detailed reply.
I have a question for you or for anyone else who knows: when the documentation says to use the cloud templates instead of the built-in ones, are we still not dependent on tagdiv in the future? In other words, if we use the v9 templates or the v10 cloud templates, aren’t we will going to just see shortcodes if we move to another theme?
I’ve become more and more leery of “shortcode hell” from changing themes, plugins, and so on. Some of it can’t be helped; I understand that. But, with a site with over 2,000 posts and publishing 10-20 new articles a day, going back and fixing shortcodes is not on my short list of Fun Things to Do.
Thanks for the original post. I’ve been holding off doing the upgrade to 10, because I was fearful of the very things you note.
Version 9 is working well for us, and the speed is not too bad. (But, we didn’t use a lot of the cloud templates or other goodies.)
I REALLY don’t want to leave the Newspaper theme; we have put a lot of work into our site, and since I do all the tech work, I get horrified thinking of the work it would take to change. But, at some point, version 9 will reach EOL, and we’ll have to do something.
-
This reply was modified 6 years by
BruceInLouisville.
OK, I got this one fixed. Go ahead and mark it closed. Thanks!
Ah, thank you! No, I disabled the Ajax post views, but left this setting as it was. So, the theme (or WP core) is updating post views, just not using Ajax. Excellent. Thanks for your answer!
You can mark this one closed. Thanks!
Additional info: I added some regular text to the column text element, then put the shortcode beside it. The regular text showed up, but the shortcode does not seem to be working. When I click the Edit Content button, the shortcode is still there.
Well … as I said above, I already disabled the Ajax counter. And the reason for my original question remains: Even with the Newspaper Ajax counter disabled, the views are still incrementing.
So, is there a built-in view counter in WordPress core? Or, is something else updating the view count?
