bfarber

The utf-conversion went well, I also updated the gallery name in the database wherever it occurred, and renamed the gallery directory accordingly - we had problems previously with that, as the gallery directory name was "gallery" 🙂.
Currently running the upgrade, with add-on directories removed, and everything else that is no longer relevant,  but with add-on tables still intact - we'll see how that goes.
Kind regards, Wim

Yes, we use Google Cloud SQL for the SQL backend and Compute Engines for the frontend to host our large community. We use standard distro linux servers in Compute Engine, without any sort of plesk/cPanel/etc. If you're only comfortable using something like that, then you have the freedom and ability to provision accordingly. It may be possible to use App Engine for the front end, however we did not go that route. We do not host anything other than our Invision community on our IPS-specific instances, and for other projects, create separate instances as needed. We have a number of administrative web-based tools that run on separate SQL and engine instances. In our situation, isolating these things from each other makes sense.
We were able to significantly reduce costs compared to what we were paying with leased dedicated servers through what's now IBM's datacenter offering, and can take advantage of the ability to quickly scale. It also helps us with our testing environment, as we can quickly spin up copies of production for testing upgrades and new extension/application deployment. As GCP offered an initial credit for new customers, we were able to get a sense for average cost and correctly size our instances during the trial period without the risk of actual costs incurred while we tested things out and continued running our legacy infrastructure.
Highly recommend. We have not tried Azure nor Amazon's offerings, so I can't speak to comparison on that end.

I've raised your suggestion internally for consideration in a future release.

We are looking to put out a patch fairly soon to address this concern, however as I noted in another thread the net sum of this change is that user profile photos won't import correctly until the patch is released. You shouldn't notice any other changes in behavior on the community side.

Yes, see my answer to your first question. You can search throughout our codebase to see examples both of using Custom form helper instances, as well as custom formTemplate() calls. Displaying a topic uses a custom form template for instance.

I'm not that big in to Pages, but aren't you returning the truncated content here? So effectively you are truncating in HTML what is already truncated in the record.
This should get the full content, which can then be truncated in HTML:
{$record->_content|raw}  

Good catch, @Nathan Explosion. Setting the truncate type to hide and then getting the full content resolved the issue. Thanks!

Each user can control that functionality individually in their control panel.

This was brought up internally already for discussion. I can't say when or if it might be done, but just wanted to note your suggestion was seen.

You could either (1) create new form helper classes to facilitate custom inputs (we do this in Pages), or (2) use a custom form template to output the end result HTML however you want. There is also a Custom helper which lets you completely define the HTML and validation.
$form->add( new \IPS\Helpers\Form\Custom( 'comments_meta_color', 'none', FALSE, array( 'getHtml' => function( $element ) { return \IPS\Theme::i()->getTemplate( 'forms', 'core', 'front' )->colorSelection( $element->name, $element->value ); } ), NULL, NULL, NULL, 'comments_meta_color' ) ); // \IPS\Output::i()->output = $form->customTemplate( array( \IPS\Theme::i()->getTemplate( 'forms', 'core' ), 'popupTemplate' ) ); Not out of the box, but again if you create your own form helper classes you could.
As per the first question, you can use custom form templates to completely adjust the form HTML. We do this when generating a topic (although we still use the regular form helper row HTML).
I would strongly recommend to use the Upload helper, but it's not a requirement if you have a compelling reason not to. Note that the Upload helper does a ton of stuff to facilitate uploads including chunking the uploads if they're too big, performing security checks on the uploaded files, storing files in the appropriate area (S3, database, filesystem, etc.). You'd have to keep those things in mind if you don't use the helper but still want to distribute your work.

This was brought up internally already for discussion. I can't say when or if it might be done, but just wanted to note your suggestion was seen.

We can't indicate read/unread status in widgets because they are cached and reused for all users, and naturally what is read or unread for you is different from the next user.

Yes, the eval field is to determine whether to show the setting or not. You can't modify the form helper in this manner. I've raised your suggestion internally but there is no option to do what you are attempting to do at present.

I've submitted a change request to get this fixed. Thanks for reporting!

@ReyDev you should be able to contact support now, sorry for the wait.
@Ziv Grosu you don't seem to be affected by the same issue. Have you tried emailing support directly and/or submitting a ticket from your AdminCP using the support tool?

I've submitted a change request to get this fixed. Thanks for pointing it out.

Will answer my own question....this can be found unders Members---->Groups---->Usergroup you want to make the change in.

Your support account should be fixed now. Sorry about that!

This is correct. Note that it's used globally for "lists".

Since 4.5 users can configure where they want to be redirected https://invisioncommunity.com/settings/links/
 

Go to languages > look for: _list_format_ string. The original sentence is a, b and c , it has to be a translated to a, b yourword c
Put another word instead of "yourword" something that links to the "third" member. now it's working!
 
This has solved my problem.

We made changes for Community In The Cloud customers that allows you to disable this feature unless your site is over a certain size threshold.

I see you have an opening <?php tag there...are you doing this in an actual PHP file somewhere, instead of in a template?
Within templates you can use "theme.setting_key" as a shortcut, and this gets expanded to valid PHP code. If you are using this in an actual PHP file you will need to do this instead:
if( \IPS\Theme::i()->settings['setting_key'] == 'value' ) Note that you need to have the framework available. If this were in a standalone file (again I see you have an opening PHP tag there), that would require loading the init.php file and getting an instance of the external dispatcher.
<?php require 'init.php'; \IPS\Dispatcher\External::i();  

I'm going to tag @Ehren to check what you're doing here. I don't work too much with themes or custom theme settings so he'll have more familiarity than I with this area.

By default the search settings are set to 365 days for your search index, if you have changed that and increased it, that may explain the higher usage, you can limit search as needed to adjust the size of this as needed.  This is changed in your admincp > system > search settings.