frisco

Perhaps this article can help you out:
https://wpperform.com/wp-core-updated-version-4-1/

See the information about adjusting your screen options. You have to click the checkbox for DFW to be available, and screen options are per user settings.

That would account for the differences you’re seeing across several hosts.

Hi John – sorry for the delay in testing this.

Yes, we’re running NGG 2.0.66.29 and QM 2.6.8. The only other notes are that:

* we are running a bunch of other stuff that I doubt is related (HyperDB, Nginx, memcached, etc).
* It’s also multisite with subdomains. I’ve tested on both the main site in the network as well as a subsite, where QM and NGG are the only activated plugins.
* These latest tests were done on 4.1-alpha-20141017

The 502 error should put something in our error log, but alas there is nothing there.

Happy to supply whatever I can to assist in sorting this out.

If you mean other links in Zero Spam, such as the admin links, I would say yes, they work in 1.5.2 (without your pull request) and seemed to work in 1.5.0.

I gave Ben an invite as a site admin so he could confirm that.

That pull request doesn’t seem to relate to the logged URL where the spam came from. ie the spam URL. Admin URL’s seemed to work fine in 1.5.2. My comment only had to do with logged URLs.

The spam URL that’s logged seems to come from the code referenced in my previous comment.

If you want to log the correct URL in multisite, you need to use:

$_SERVER[“HTTP_HOST”]

instead of:

$_SERVER[“SERVER_NAME”]

We’ve tested both of the changes suggested in my comments, and they work.

Hope that helps.

Take this for what it’s worth, since I only spent a few minutes looking at the code, but …

Isn’t the spam URL grabbed from _get_url() around line 1195 of zero-spam.class.php?

Isn’t this due to using $_SERVER[“SERVER_NAME”]?

For example, changing this:

$pageURL .= $_SERVER[“SERVER_NAME”] . $_SERVER[“REQUEST_URI”];

to:

$pageURL = site_url() . $_SERVER[“REQUEST_URI”];

grabs the right domain. However, it’s still missing the rest of the URL on which the spam comment originated.

Note that function builds the protocol, but that’s already in site_url() so I changed .= to just = for simplicity/illustration.

Hope that helps.

Deactivated 1.5.1. Updated to 1.5.2. Activated 1.5.2. Reset log.

With 1.5.2 installed, here’s what we saw:

#3 (using wrong domain on multisite): Wrong domain still shows up.
#5 (log pagination): Works nicely. Thanks for the improvement.
#7 (use WP time, not server time): Still not working.

We’ll send you a private email since it looks like you haven’t activated your user account.

Will check out the update.

Just resent the email. It is an activation email from a site on our network.

Thanks for the follow up. Site will send an invite shortly.

Yes, we’re running 1.5.1.

#3) I am not sure the issue you linked is 100% on point. The site is a subdomain on a network that is mapped to its own domain. The plugin is activated on that site, not network activated, so any settings should be specific to that site. Other URL’s that WP generates for the site use its mapped domain, not the network domain. A look at that issue leads me to believe it is about network activating and getting the settings down to a site.

Since reporting, site admin manually cleared the logs, so the data isn’t the same as the initial post.

Let me know if you need more.

@photosbykev – For us and others reporting here, the problem does occur in 2.0.66.16 but did not occur in 2.0.66. If you repeat the search I linked to above, you’ll see that it was reported by others for version .16 at the end of July.

I can’t speak to why .16 worked for you, and I haven’t had a chance to run a diff on .16 compared to 2.0.66 to see what broke.

The sort option is a relatively new option to NGG. IIRC, it got introduced around 2.0.40, but that’s just a guess. If your first install of NGG was after the introduction of the setting, it may be that your settings are different from those who upgraded from older versions.

Hopefully, the NGG folks get it sorted out quickly. The descending sort option is useful when it works.

@photocrati – No prob.

@rogiermaas – We all get frustrated from time to time. No worries.

@rogiermaas & @photosbykev – Since both of you looked for this issue and didn’t find it, it might be helpful to take a step back and explore how to look for things here. Use regular Google search. If your issue is a new (such as with a plugin update that just came out), set the last update in Google search to past month. Set the site to www.ads-software.com to just get results from the WP site. Finally, search for the plugin name and a few words that might be specific to your issue. In this case, that word is singlepic. It’s better to start with fewer words and refine it with more words if the results aren’t relevant.

Here’s my Google search for “nextgen gallery singlepic” for results on www.ads-software.com in the last month.

https://www.google.com/search?as_q=nextgen+gallery+singlepic&as_epq=&as_oq=&as_eq=&as_nlo=&as_nhi=&lr=&cr=&as_qdr=m&as_sitesearch=http%3A%2F%2Fwww.ads-software.com&as_occt=any&safe=images&tbs=&as_filetype=&as_rights=&gws_rd=ssl

The SERP shows a couple of results that indicate this is a problem since .16 was released and include the tip that I repeated above.

Hope that helps.

Do you really think I didn’t search the forums for this?

Your comments in 3 different threads over a short period so soon after joining these forums relating to the same topic led me to the conclusion that you didn’t find the previous discussions and were probably frustrated.

If you found them and we’re aware of a separate issue that you don’t think is related to your problem, it’s important for you to provide that information – that you are aware of the other issue, tried the already-reported techniques to fix it, and they didn’t work for you. That’s basic troubleshooting. Otherwise, every new issue starts with a rehash of what’s already been covered, which is a waste of time.

Your problem might be a separate issue, and it will get fixed faster if you provide all the relevant details of what you investigated in your effort to resolve it in 1 separate thread. Not providing the details only makes it more likely that the particular bug you experienced doesn’t get fixed.

The problem is due to an NGG bug, but there’s an easy workaround until it’s fixed. The Photocrati folks are already aware of the bug.

Visit Gallery->Other Options and be sure the Sort in what direction? option is set to Ascending.

If it’s set to Descending, NGG grabs the image with an ID=1, and displays that for all uses of the shortcode displaying a single pic.

Given that NGG is an extremely popular plugin, unless you are one of the 1st to adopt a new version or the bug only applies to an edge case applicable to you, it’s something that others have probably already come across and resolved. A thorough search of this forum would have yielded threads that explain what I repeated.

Hope that helps.

Just an update, we installed the latest version 1.4.12 and that didn’t fix the E_WARNING errors.

@johan – Thanks for the follow up.

The code block does indeed work and solve the issue that drew my comment regarding Post Type Switcher.

I also discovered your comment here https://www.vanderwijk.com/wordpress/wordpress-custom-post-widget/ that your reason for making the content block not public by default was to “not cause any duplicate content or other SEO issues”.

Is that the best way to achieve that goal? Is there another combination of CPT registration parameters that would allow a content block to be public but wouldn’t create duplicate content issues, such as has_archive or publicly_queryable? (Just wondering…haven’t tried this.)

Also, while making the CPT of your plugin public fixes the issue with Post Type Switcher, it would be great if that plugin simply ignored non-public CPT’s, which would mean you couldn’t change them to other CPT’s using it but they wouldn’t break. The changelog of Post Type Switcher suggests that was the case as of version 0.2, but when your content blocks aren’t public, Post Type Switcher doesn’t ignore them.

I’m marking this as resolved because I think this is more of a Post Type Switcher issue.

Thanks again.

Thanks, Ben. I’ll follow the Github issues and make any comments there if appropriate.

I realize that most of this is minor stuff time-wise. What caught my eye was the Nova_Restaurant::init because a) I happen to be in Northern VA, which is often referred to as “NoVA” and b) have nothing to do with restaurants other than eating in them ??