bfarber

I would recommend blocking unwanted traffic at the server level. By the time the request makes it to PHP, a lot of unnecessary overhead has already occurred if your intention is to block the traffic. You can already ban by IP address if you wish, and most legitimate spiders will advertise the IP address ranges used by their bots if you wish to do that, but again...this is better served at the server/firewall level.

There's some good discussion in here about the behavior of invoice generation so I've moved the topic to the feedback forum.

Create an Anti-Fraud Rule with "Hold for manual approval" as the action to take and leave all of the settings on the defaults. This should accomplish what you are after.

You can follow an item by calling to POST /core/members/{id}/follows. You can do this manually after posting the content item. I'll raise a suggestion internally to allow automatic following during posting.

Command line php and the php engine used by the webserver are not always the same. You may need to check your webserver configuration to figure out which PHP library it is currently using.

This is happening because your server checks for the presence of a file on the filesystem first. If found, it executes or serves the file.
If not found, it passes to IPS, and IPS has to work to determine if the URI if the request represents something to serve out, if the request has permission, and whether or not to return the not found error.
You can identify the traffic that is asking for things it shouldn't be asking for and block it with a firewall, either on your server or in-between your server and the requestor.
This configuration may be complex and depends entirely on your environment, yet the behavior you are seeing is precisely by design otherwise.

Ok, well allowing videos where we currently allow images is secondary to supporting webp. We're talking about two different things at that point - not that it's a bad suggestion or anything, but I was focusing first on where you wanted to see webp support implemented so we can break this down into workable chunks. 🙂 

It is recommended to output webp files in a <picture> tag instead of an <img> tag, which supports specifying multiple versions. That's something we'd have to take into account.
Also, ios14 added support apparently: https://css-tricks.com/webp-image-support-coming-to-ios-14/
I found that we have an open internal suggestion discussing this already so I've updated it. Thanks!

No, there is no difference in behavior behind the scenes. We serve the same HTML output, same caches, etc. regardless of the device.
There are minor javascript differences (i.e. there are some areas of javascript that do like "if( mobile ) { do this }") but those instances are minimal. The legwork of the difference in display comes from responsive CSS.

Hello to whomever may stumble upon this! 

I work for a small organization that doesn't have the capacity to support a self hosted solution but still needed to extend upon the base functionality of the website. This means I don't have access to the developer console - as a result I have been experimenting over the last month or so with development on the cloud hosted version. While not ideal I have been able to accomplish some features that have been useful for us.  If you are in a similar situation I hope this can be useful for you as well and perhaps save you some time.

If you read this and think there are better ways to achieve these means I would be very happy to learn them. Please do share any ideas you may have if you care to do so!

Here is an example of a Community Map we built via PHP & HTML custom blocks.
PHP Block for getting member data - template key = "php_template_key"
Standard API request as outlined in the docs with the addition of setting the returned data in the global $_SESSION variable to make it accessible from the front end HTML block. (thanks to @bfarber for that idea!).
$communityUrl = 'BASE_URL_HERE'; $apiKey = 'API_KEY_HERE'; $endpoint = '/core/members?perPage=700'; $curl = curl_init( $communityUrl . 'api' . $endpoint ); curl_setopt_array( $curl, array( CURLOPT_RETURNTRANSFER => TRUE, CURLOPT_HTTPAUTH => CURLAUTH_BASIC, CURLOPT_USERPWD => "{$apiKey}:", CURLOPT_USERAGENT => "MyUserAgent/1.0" )); $response = curl_exec( $curl ); $_SESSION['apiResponseVariable'] = json_encode($response,JSON_HEX_APOS|JSON_HEX_QUOT); Since I only need member name, a custom field and their location I could (and probably should) groom the data here on the BE before passing to the front end. 
 
HTML Block for rendering map
This requires you to enable Google Maps Third-party Enhancement at 'YOUR-DOMAIN/admin/?app=core&module=applications&controller=enhancements'.
Some useful docs for working with the Google Maps API:
https://developers.google.com/maps/documentation/javascript/adding-a-google-map
https://developers.google.com/maps/documentation/javascript/marker-clustering
{block="php_template_key"} {{$response = $_SESSION['apiResponseVariable'];}} <html> <head> <title>Community Map</title> <script src="https://unpkg.com/@google/markerclustererplus@4.0.1/dist/markerclustererplus.min.js"></script> <script src="https://maps.googleapis.com/maps/api/js?key=API_KEY&callback=initMap&libraries=&v=weekly" defer ></script> <style type="text/css"> #map { height: 400px; width: 100%; } .welcome-text { padding-bottom: 20px; } .welcome-text span { font-size: 16px; } </style> <script> function initMap() { let mapStyleOptions = [ { featureType: "water", elementType: "geometry", stylers: [ { color: "#d0d3d4" } ] }, { featureType: "landscape", elementType: "geometry", stylers: [ { color: "#dee2e3" } ], }, { featureType: "road", elementType: "geometry", stylers: [ { visibility: "off" } ], }]; const myMap = new google.maps.Map(document.getElementById("map"), { zoom: 2.5, center: {lat:24.63940428579627, lng:-50.6783944937192}, styles: mapStyleOptions, }); /* This is the messy bit of conforming the $apiResponseVariable to usable json */ let data = '{json_decode($response, TRUE)}'; data = data.replace('{json_decode("', ''); data = data.replace('", TRUE)}', ''); data = JSON.parse(data); let locations = []; let markers = []; let infowindow = new google.maps.InfoWindow(); data.results.forEach(member => { let memberLoc = JSON.parse(member.customFields[1].fields[2].value); if(memberLoc.lat !== null && memberLoc.long !== null) { let organization = member.customFields[1].fields[3].value; let memberName = member.formattedName; let memberUrl = member.profileUrl; let displayName = memberName; if (memberName != organization && organization != '') { displayName = memberName + ' - ' + organization; } locations.push({ id: memberLoc.lat.toString() + memberLoc.long.toString(), name: displayName, profileUrl: member.profileUrl, lat: memberLoc.lat, lng: memberLoc.long }); }; }); const uniqueLocations = Array.from(new Set(locations.map(a => a.id))) .map(id => { return locations.find(a => a.id === id) }); for (i = 0; i < uniqueLocations.length; i++) { marker = new google.maps.Marker({ position: new google.maps.LatLng(uniqueLocations[i].lat, uniqueLocations[i].lng), icon: { url: "some-custom-image-url", }, }); markers.push(marker); google.maps.event.addListener(marker, 'click', (function(marker, i) { return function() { let UrlElement = '<a href="' + uniqueLocations[i].profileUrl + '">' + uniqueLocations[i].name + '</a>'; infowindow.setContent(UrlElement); infowindow.open(myMap, marker); } })(marker, i)); } let clusterImagePath = 'some-custom-image-url' new MarkerClusterer(myMap, markers, { imagePath: clusterImagePath, height: '100px', width: '100px', }); } </script> </head> <body> <div class="welcome-text"><h2>Welcome to the community map!</h2><span>Use our Community Map below to find and interact with other members.</span></div> <!--The div element for the map --> <div id="map"></div> </body> </html>
I've used this pattern of BE API request and FE PHTML/JS jumble to achieve a fair amount of custom tooling so far (in the absence of access to the developer console). Hope this is useful to someone out there.  Happy to answer any questions or receive feedback.
Peace love and chicken grease.
 

It's a group permission, so edit a group...

I can only say that this is on an internal suggestions tracker and is being considered for a future release.

Anecdotally I will say that IN_DEV locally feels a lot faster to me on PHP 8 than it does on PHP 7. I haven't measured speeds for both, however.

We have been testing PHP 8 compatibility locally and it will be included in a future release, however I can't say exactly when that will be. I can say that certain third party libraries we use will also need updates before we can fully support PHP 8.

No, there is no difference in behavior behind the scenes. We serve the same HTML output, same caches, etc. regardless of the device.
There are minor javascript differences (i.e. there are some areas of javascript that do like "if( mobile ) { do this }") but those instances are minimal. The legwork of the difference in display comes from responsive CSS.

@AndreasW2000, if you don't mind my asking, what's motivating the desire to have search engine (or other web crawlers) identified as such in Who's Online?
If the purpose is to determine the level of human traffic on your community as a community administrator, I'd suggest you'd explore some better options that exist to see these measures. If the purpose is for your membership to know this information, I might be helpful to talk a bit more about your use case here.
As an administrator, I'd recommend using a third-party analytics package such as Google Analytics. It's free, can be turned on natively with IPS (ACP > System > Community Enhancements) and will show you in both real-time and historical snapshots human visitors vs. automated traffic. The data presented here is going to be far more accurate and insightful than any efforts to visually monitor the Who's Online page.
No, this simply means that there won't be session data stored, and the overhead of creating/updating that session data in your database or Redis. Doing this would improve your site's speed and performance for things accessing your site that aren't logged in. Presumably (though I have no idea) these changes would apply to all non-authenticated traffic.
It would not block or prevent them from crawling your site, nor viewing the content. Just an under the hood optimization.

I just got my first referral on my account. It was actually brilliant to show the account signups instead of just anonymous sales. I heard the little notification noise, I see the account of the person I helped create, and now I want to help answer their questions so they will buy something. This is definitely an underutilized feature I think we need learn how to use properly.

It's likely not this. Are you sure permissions are correct? ACP > Support > System Check

Yes

You would need to use the framework methods for storing and retrieving files.
$file = \IPS\File::create( "core_Theme", $filename, $fileData ); print $file->url; /** * Create File * * @param string $storageExtension Storage extension * @param string $filename Filename * @param string|null $data Data (set to null if you intend to use $filePath) * @param string|null $container Key to identify container for storage * @param boolean $isSafe This file is safe and doesn't require security checking * @param string|null $filePath Path to existing file on disk - Filesystem can move file without loading all of the contents into memory if this method is used * @param bool $obscure Controls if an md5 hash should be added to the filename * @return \IPS\File * @throws \DomainException * @throws \RuntimeException */ public static function create( $storageExtension, $filename, $data=NULL, $container=NULL, $isSafe=FALSE, $filePath=NULL, $obscure=TRUE )  

You can use the IPS REST API Ikey endpoint , but you can also just use the http://www.example.com/applications/nexus/interface/licenses/?ENDPOINT URL.
We've covered this in our guides 
 
 

That's correct - a cookie is set and they are tracked even if they sign up later.

We store the post content as already generated HTML, which means the same content is served to members and guests. In order to accomplish what is being asked here our options are limited, as such. We could in theory...
Link to a script that serves the image (instead of to the actual image), and let that script serve an error/alternative "no access" image to guests. Main con: you lose the benefit of using a CDN (such as Cloudfront) to serve your images. Use javascript to provide an alternative experience for guests. Main con: simply disabling javascript circumvents the "protection", so it's not really that useful if you truly want to block guests from seeing the images. Store different content for guests and members. Main con: you duplicate the bulk of your database, and all existing content would need to be rebuilt on upgrade. Realistically there's not a great way to handle what you are asking for when you factor in other considerations as above.

We store the post content as already generated HTML, which means the same content is served to members and guests. In order to accomplish what is being asked here our options are limited, as such. We could in theory...
Link to a script that serves the image (instead of to the actual image), and let that script serve an error/alternative "no access" image to guests. Main con: you lose the benefit of using a CDN (such as Cloudfront) to serve your images. Use javascript to provide an alternative experience for guests. Main con: simply disabling javascript circumvents the "protection", so it's not really that useful if you truly want to block guests from seeing the images. Store different content for guests and members. Main con: you duplicate the bulk of your database, and all existing content would need to be rebuilt on upgrade. Realistically there's not a great way to handle what you are asking for when you factor in other considerations as above.