nhwp

This is a pretty critical feature for us. We’ve moved several municipal clients sites to your plugin because of the easy of customization, etc. But we’re really needing the sticky post feature enabled. I would hate to have to move to a different plugin just for this feature.

Thanks for considering this in your feature requests.

We are indeed using the [catlist] shortcode, but we are using the name=” parameter to pull a specific category. Does that disable the sticky posts function then?

Is there a way to use a hook perhaps to adjust the wp_query to enable sticky posts globally?

Thanks in advance.

Oops! Sorry. Got the date wrong… seems to be working as intended.

(drinking coffee now).

Thanks, Joe! I see the change has been included in the recent updated.

One glitch I found is that future instances of a repeating or multi-date event are also seeing the rel=”nofollow” applied.

See screenshot.
https://www.dropbox.com/s/p4qfl5pfdwsiamd/20191218.PNG?dl=1

Is there a fix for that?

Thanks!

That sounds great! We’ll take some baselines before we apply the next update so we can monitor it’s impact on old events showing up in Google search.

Thanks for your responsiveness!

Thanks for your reply, Joe.

Is there a hook or filter you can send me towards to throw that together? Or are you planning to integrate that as an option in a future release?

(just so I can update the client).

Yeah, I wondered about that after posting here too, actually. The site is running on PHP 5.4.45.

We adopted the site from a previous developer and I’ve asked their host to upgrade PHP. Thanks for the insight!

I believe I found the culprit in the Denali theme. I was having the same issue and noticed JS console was showing a Google Maps warning saying “NoApiKeys”. I could see in the source that there was a call to the following address without any API Key added:

https://maps.google.com/maps/api/js
?sensor=true

I wondered if there’s an old deprecated duplicate call to the maps API without the Key that is tripping the map’s developer mode. The fact that the script path above is setting “sensor=true” indicated to me it’s an old forgotten reference from years past since sensor is no longer required according to Google’s documentation.

So I started looking in the Denali theme (as I see @tomstep is running it like us). I found the reference at line 170 of /themes/denali/lib/classes/class-denali-theme.php

I commented out the following line (class-denali-theme.php:170):
$remote_assets[ 'script' ][ 'google-maps' ] = 'maps.google.com/maps/api/js?sensor=true';

Saved and force refreshed and shazam, both my supermap and listing maps load properly again.

Since the problematic line is in the parent theme, it will be reverted in the next theme update if it’s not corrected on UD’s side before then.

https://actionproperty.ca/rental/map-overview/
https://actionproperty.ca/properties/jackson-3-house-2/

Hopefully this can be corrected and pushed out in the next Denali update.

Thanks.

Discovered the documentation mention that v3.*.* of the theme wasn’t prompting for updates anymore.

I downloaded the updated theme from my UD account and installed manually.

Problem has been resolved.

I went ahead and deactivated ALL plugins as you suggested, deleted a PDF in question then loaded it from the public property page to access the PDF (link reads https://…/?wpp_flyer_create=true).

Despite that, PDF loads with first two pages blank as before, followed by the flyer page.

https://actionproperty.ca/properties/ross-house/

Any other ideas? I see Denali hasn’t updated on our site since 2014. Is there a more recent update to the theme? Could that be related?

Thanks in advance.

Yes – deactivating Monster Insights resolves the error for me as well.

I re-activated and tried re-saving their user role exclusion settings in different configurations (including leaving blank) and the error continues to appear.

I’ve posted a request to their support forum on the topic.

There is no need for them to manage settings – the problem is that all back-end pages including new post page and Edit My Profile pages are inaccessible to users without the “manage_options” capability.

Deactivating USP solves the problem, for some reason. I wonder, is there a capability check in the USP plugin that runs on all pages of the back-end that checks for the “manage_options” capability?

This is the feature I’m looking for too.

We have several local governments (regional districts, cities, etc.) that need to archive posts instead of deleting them where 90% of posts are auto-archiving via Post Expirator which doesn’t support custom post status. The feature has been requested on that plugin, but no ETA yet.

I’ll post here if I find an expiration plugin that supports custom post status.

Thanks for the reply!

We have over 60 fields we’re trying to include in the search, so your solve might prove to be a bit labour intensive.

I think we’ll be waiting for the feature to be added to the plugin itself.

Thanks again!

Looking forward to this added feature!