bfarber

Do you have the same problem on Facebook's site? (I use Windows so unfortunately my ability to test what happens in specific versions of Safari on specific versions of Mac is difficult - although many staff here use Safari and Mac so I can defer to them.)

We don't implement every single suggestion ever submitted, particularly when only one client has ever requested it. It's not an objection or unwillingness, but rather an attempt to gauge the request and how relevant or important it is, in the context of everything else we have going on, and also to see if it's something widely needed or desired, or just something one person wants for their own reasons.

Can you clarify what the issues are with embedded Facebook videos? Seem to work fine in a quick test ^^

Not exactly - the converters referenced in that download are for converting from other software, not for the UTF8 conversion. The UTF8 conversion utility is always included with the download. The error would seem to indicating that your blog_entries.entry_content column is likely not UTF8 presently, and at least one row has enough data stored in the column that when converting it to UTF8, the data would exceed the amount that you can store. For instance, if you are using latin1 and the column is currently TEXT type, then converting from a single byte character set to a multibyte character set results in too much data being stored in the column. It's a fairly niche scenario to find yourself in. You can likely work around this by changing the column type to allow more data (e.g. if the column is currently TEXT, change it to MEDIUMTEXT), and then continue the upgrade. Or you can submit a ticket if this occurs when attempting to upgrade your live site.

Facebook behaves the same - does this concern with your site carry over there, out of curiosity? I, personally, don't have much preference. I suppose an option could be introduced to shut off relative dates/times if this is a "thing", but I can't recall this really coming up much in the past and the software has behaved this way for years.

We output structured data in the form of JSON+LD. You can see this by validating any of our "blog" articles (which are actually generated through Pages). https://search.google.com/structured-data/testing-tool/u/0/?utm_campaign=devsite&utm_medium=jsonld&utm_source=review-snippet#url=https%3A%2F%2Finvisioncommunity.com%2Fnews%2Fcommunity-management%2Fwhat-is-the-engagement-trap-and-what-to-do-about-it-r1168%2F If you wish to remove the "article" markup and insert your own, you will likely need a plugin written. If you have some universal ideas related to structured data markup you think would be valuable to the community at large to support out of the box, please feel free to share them.

There is a per-group setting on the "Social" tab: Can view Display Name History

If you are familiar with your browser developer tools, you can use the Network tab to inspect the request and response when clicking on the next page. Presumably something is happening causing an invalid response to be returned.

Charles and coffee do.not.mix.

Thanks, I've submitted a patch for review but I'll push off a fix for 4.5 given how low level the code is and how low priority and rare the issue itself is.

Actually, I did some research and RSS has an enclosure tag which can be used to link to media. We'll review this suggestion further for a major release.

Sounds like some of your files might be out of date - I would recommend reupload an entire set of files to be sure.

It wouldn't be too hard to create a plugin to add support for this leveraging the GMagick extension. I don't think we would add native support in the software unless there was some level of demand, however.

I raised this internally in our tracker to get some more input, and unfortunately this isn't something that can/will be changed. Setting the 'required' flag on a form helper most often sets the 'required' HTML attribute as well, so there is browser-level validation going on as well which has no understanding of our toggles system. What you will need to do is what you are already doing - set required to NULL (or set appearRequired) and then perform custom validation on the input as needed.

You quoted my post, but then pointed to custom code again. 😛 I was asking if there's anywhere within the Suite at present where this issue is occurring, so we could focus on that. We try hard to ensure every API and method works as expected and everyone can use them with ease and so on, but we do have limited development resources at the end of the day, so it's not always the easiest task justifying development time on something that has absolutely no impact to how the software functions out of the box. That isn't to say of course we don't want to ensure the framework is rock solid (both for us, and for third parties), but hopefully you can understand that an issue like this would be at the very very bottom of the totem pole in terms of where we focus our efforts.

Setting aside the fact that only 2 people have responded to this topic (one of which was you, the original poster) - improvements and consolidation of code/consistency for custom fields features is something that has been discussed internally, more than once, but there is no current timeframe we can say to expect to see it. Unfortunately, it's simply not feasible to respond to every single topic to say "we've read this but there's nothing to note or add at this time".

I would recommend simply not publicly displaying the user's display name history if you have concerns about the information being displayed. (I don't believe there is any built in faculty to delete individual member history log entries right now)

I'm assuming you're not seeing this behavior occurring natively anywhere at present? If there's an existing form that isn't working, it would be easier to get this raised and fixed quicker.

Are you displaying the display name history publicly?

Why would you need to do that?

Looks like Instagram supports OAuth2 logins. https://www.instagram.com/developer/authentication/ You should be able to set it up using the built in OAuth 2 login handling in Invision Community without a special plugin (although admittedly I haven't tried - I don't use Instagram and don't even have an account to test with off hand).

Thanks, I'll note this to have it checked on in a future release.

The code would appear to be in place to ensure fields required for registration are filled in. If you removed that code, does everything work as you are expecting (including required fields still being "required")?

I'll be honest - I don't think we need configuration options for how long to cache the manifest file. I'm not opposed to adjusting the caching and using sensible values, however, so thank you for the information. We can discuss it further internally and make decisions as to whether or not to change it.

$cacheHeaders = ( \IPS\IN_DEV !== true AND \IPS\Theme::designersModeEnabled() !== true ) ? \IPS\Output::getCacheHeaders( time(), 86400 ) : array(); Line 174 applications/core/modules/front/system/metatags.php