Gauravk

We had the same discussion  mention 3 months ago.
 
 

Many thanks @Jim M for wonderful, prompt and precise support.
REALLY APPRECIATE IT.

Thank you for providing a member. I will keep that hidden so that it is not exposed publicly. 
Your Members group does not have access to Clubs so would not see anything. Their permissions in ACP -> System -> Applications -> expand System -> Clubs is disabled.

I mostly just use responsive tags. If you’ve set specific sizes. You’ll probably not get the best fill/rates. Just a heads up.

This would be Google hasn't approved those pages yet for ads. Keep in mind that our software just "prints" the code on the page, it's up to Google whether or not ads show. If ads are appearing on some pages but not all and nothing custom has been done to change that display on your end, that is typically Google not putting ads on those pages yet.

Putting it in the Google Analytics or Google Tag Manager integrations will place it in the Head.
I would not advise implementing automatic ads from AdSense as they do create issues and go sometimes where they are not wanted. It would be advised to implement their manual placement ads.
 

I use auto ads and they can sometimes be all over the place, so I would agree. You don’t need GTM for Adsense as you can just put the Adsense tags into the default ad placements.

Can anyone please help on how to add below line in custom.css?
  --header--height: 100px;
I tried this and didnt worked.
Thanks in advance

Only really to force an account to purchase, unfortunately. It may be better trying to locate the IPs of  these guests and blocking at a server level though

Thanks @Gauravk and @rebraf! 
Thank you for bringing this issue to our attention! I can confirm this should be further reviewed and I have logged an internal bug report for our development team to investigate and address as necessary, in a future maintenance release.
 

@Jim M Brandon here.
You need to submit the request as an "AJAX" request, that's the key. Here's a code snippet you can drop into postman or execute on the server to reproduce. It will cause the error on demand.
curl --location '{base_url}/events/event-search/' \ --header 'X-Requested-With: XMLHttpRequest' \ Swap out {base_url} with an Invision base URL.
I can reproduce the error here on this community easily with this for instance:
curl --location 'https://invisioncommunity.com/events/event-search/' \ --header 'X-Requested-With: XMLHttpRequest' \  
Hope this helps! The problem is that the $select variable in the controller isn't initialized basically (or rather, it's initialized inside an if statement but that if statement isn't hit, however a separate query is ran for AJAX requests later on expecting the variable to be set).

Just to save your time, @Gauravk, there's nothing in Members Shop that handles IPS Connect or any other type of external connection.

It would be one of these two which are referenced in the error:
applications/drives/hooks/drivesData.php
applications/membersshop/hooks/MemberHook.php

IPS Connect no longer exists since around 4.3. It was phased out for OAuth2. If you have anything custom or third party referencing that, you would want to remove it. 

Yeah, looks like I cleared the cache in the same moment the plugin was disabled. Glad you got it solved.
I'd still highly recommend upgrading your theme as soon as you can though 👍 It'll make future upgrades much smoother and less prone to errors.

After clearing the cache on your site, the sidebar is now working correctly. 
With that said, there is some severely outdated code in your theme, especially within globalTemplate. This will likely cause other issues on your site, or may prevent new features from working correctly. I'd suggest manually upgrading your template files by following the code changes provided by the Theme Tool.

It looks like you're in WHM (the "root" or server level).  It's not done there.  It's done in the user level cPanel.    Inside of the cPanel account for that user should be a section for cron jobs.  You would find the existing one and change it o reflect the correct path.  
In your screenshot for example, you'll notice it includes the "ea-php80".  That's what will tell cron to use PHP8 instead of what is most likely something like "ea-php70" or "ea-php74".

Yes, the RSVP box will be on the right now. Lots has changed when moving from Calendar to Events.

You would want to revert any which have been customized and have /calendar in the FURL. On the right-hand side, there will be a revert button. Should look something like the circular arrow here below:

I merged your two topics. You'll want to check the solution quoted above.

As Randy mentioned, support functions the same, for more than a year now we changed where you start it. You can create a topic in our staffed support forum at the link below and state your issue. If there is highly sensitive information, we have ways in the Client Area to obtain that information securely by our staff only or we can pass it to a ticket if further investigation is required.
https://invisioncommunity.com/forums/forum/497-technical-problems/

Well more than a year ago, the support model was changed to be forum first.  Self hosted users need to post on the forums here which are monitored by staff. If it requires deeper analysis or is something confidential in nature, they can open a ticket on your behalf which would be communicated via email.
If you are hosted by IPS, you can open a ticket via the client area.
What problem are you having?  One of the values of being forum first is you get the experience and scale of other customers as well. 

Any expected date of release, I'm highly interested.

Building what we call "widgets" is very expensive. It adds significant database overhead, which is why we almost always cache them. It means that one process builds them, and this built version can be shared with hundreds and possible thousands of subsequent page views.
The downside is that we cannot allow any personalisation of the widget based on the member that created the cache for it. This is why we cannot show unread topics in widgets (or feeds as discussed here).
It is a logical resource problem, not an ideological problem.
We have a duty of care to ensure that your site, no matter if it receives 100 clicks a day, or 1000 clicks a minute responds quickly and doesn't consume a disproportionate amount of resources to the point where performance degrades.
Marketplace authors often write plugins that significantly increase the resource footprint in a way that would be unsustainable for customers with the busiest communities but offer more functionality such as unread markers for widgets. We allow it because they benefit some communities but it is not something we can offer in the core software because we simply cannot allow a community to degrade as it scales.

There isn't really a workaround there. It's an addition. There are performance reasons we don't add this to the core platform, as mentioned in the topic above.

While there may be sites who can use things like this, they are not necessarily always something that is good to add to the core platform. If this was the case, the marketplace wouldn't exist. This is where the 3rd party community comes in.

Application and plugin developers develop for people who purchase their application or plugin. So by definition, in this case, the only people purchasing that addon are the people who need that added. We do the same, but have a broader audience. The people who are buying our product, are not only people who need that feature added. There is nothing wrong with that. Its just the way it is.
I'm sure there is a store somewhere that sells leopard print car seat covers for Ferraris. I'm also pretty sure thats never going to come as a default option