teraßyte

When adding a Date Field to a database that stores revisions, the comparison shows the timestamp rather than a formatted date. Here's an example: A revision showing the above doesn't help, especially if the user doesn't know that that "weird number" is actually a timestamp. A formatted date using the member's locale should be shown instead, including the time if the field option is enabled.

Here's the setup needed to reproduce the issue: Enable the setting Store revisions in a CMS/Pages database. Add a field to the database (any kind works), and enable the setting Editable when viewing a record in the Display options tab. WORKS: Add a record, and edit it in the normal form (Record actions > Edit). A revision is added to the database. DOESN'T WORK: When viewing the same record, use the quick edit form at the bottom to change the field value, and click the Update button. No revision is added for the change. === Tested on a fresh install using default templates.

While adding new fields to a CMS/Pages database, if you go to the Display options tab, the Show Map & Map Size fields (for both listing and display views) are always shown. Those 4 fields are supposed to be visible only if the field type is Address. 🙄

The developer is not around anymore (at least for now?). Unless they renew their license, their modifications won't be available for purchase. For more details, check the topic linked in the reply above.

Try using zh_CN.utf8 instead.

I was thinking more of hiding the fields by adding some rules to custom.css, but yeah, I guess including a separate CSS file would work, too. That wasn't the point though:

There is no option in the software to create new widget areas. These are the only options I can think of: If you have the Pages/CMS app, create new blocks based on the widget, and then edit the template to place the blocks there. Have a custom modification made to add widgets in that area using hooks. Have a custom modification made to add new widget areas (not sure if it's possible).

Well, yes, I could remove them. But if the field is missing, the value is not submitted, and the backend might throw errors about some array keys not existing or some other problem. That's why I think it's important to be able to alter the form fields directly rather than relying on CSS/JS "tricks" to hide or remove them. Yeah, I've been really holding back on saying too much for now. (Really! I had to say it twice.) But, from what I've read, my problem is that I can't do most of the things I need. 🤷‍♂️ Fingers crossed. 🤞

Unfortunately, that won't work: CSS is not an option because it would hide the fields for everyone, not just specific members/groups. In any case, they'd still be there in the output. Javascript would allow hiding the fields based on some extra JS variables in the output. Again, they'd still be there in the output. Since the fields are in the output, a person with some knowledge or a bot can still fill them in without trouble. Removing them completely, and not processing the values when the form is saved were requirements for the modification. (Don't ask me why it needs to be like that, but that was the request.) Being able to easily extend all forms and adding new fields to them is nice, but being unable to alter the other fields is a severe limitation.

@Esther E. Based on what I'm reading, we won't be able to alter the current form fields, only add to them. Is that correct? For example, I have a custom modification that hides some fields when submitting a new Event in the Calendar app. The client wanted those fields to be available only to certain groups. That's not something we can do using UI Extensions, and we can't overload anymore any methods. 👀 Another example in the marketplace is this one instead: It has the option to require the user to enter a message, and even require a minimum number of characters. With UI Extensions I won't be able to update this modification since I can't access the existent form fields.

There's a really easy way to avoid breaking methods: use a single array for every method and pass all values in that array. Need to add a new value? The array has a new index. 😋 😹

No issues there. He won't be able to upgrade 2/3 of them. Lots of time saved! 😂 Seriously, I have several apps and plugins extending classes in the /system folder. That means they're all dead for v5. So far, I don't like the direction v5 is taking at all. No matter what awesome tools you may have in place, being unable to overload (almost) all classes like before is a huge issue. Well, that's it for me for now. I won't say anything further until there is more info about those "awesome tools" you mentioned. But I don't have much hope for them.

To log the download, I have an hook on \IPS\File. I see no way to access it with Listeners? Guess I can only wait and see what comes next for now... 🙄

The second plugin is something that should be included by default really, but, leaving that aside, my main issue is the first one I linked. I have plenty of similar (custom) modifications. That's the biggest problem, and your reply doesn't help at all, unfortunately. 😔

I was silent so far, hoping for some revolutionary idea, but I have to agree with Adriano: with these changes modding is dead. Listeners are basically the old Library hooks from 3.x, and we can no longer overload any other methods (unlike before). I won't be able to update 85%+ of my modifications with this system. @Matt As an example, I see no way to update these plugins for 5.x: Unless I'm missing something, or you have more coming to still allow them.

@Matt Taking a look at the included images, I see you guys are still using that same long-ass code for language strings: Member::loggedIn()->language()->addToStack( LANG_KEY ); Can't you make it more simple with something like: # Automatically uses Member::loggedIn() Language()->addToStack( LANG_KEY ); # Make it use another member Language( $member )->addToStack( LANG_KEY ); It's always been something that annoyed me. 😋

On a site with a lot (really a lot) of clubs, the function \IPS\Member\Club::clubs() becomes rather slow because there are no indexes for the suggested columns in the phpDoc text: /** * Get all clubs a member can see * * @param \IPS\Member $member The member to base permission off or NULL for all clubs * @param int $limit Number to get * @param string $sortOption The sort option ('last_activity', 'members', 'content' or 'created') * @param bool|\IPS\Member|array $mineOnly Limit to clubs a particular member has joined (TRUE to use the same value as $member). Can also provide an array as array( 'member' => \IPS\Member, 'statuses' => array( STATUS_MEMBER... ) ) to limit to certain member statuses * @param array $filters Custom field filters * @param mixed $extraWhere Additional WHERE clause * @param bool $countOnly Only return a count, instead of an iterator * @return \IPS\Patterns\ActiveRecordIterator|array|int */ The description for $sortOption mentions 4 columns (last_activity, members, content, created), but the only indexes available are created and members. The other columns, including name (which isn't even listed in phpDoc), have no index, and any query ordering results by those becomes slower the more clubs the site has. Not to mention that there are queries based on club type, and the type column doesn't have an index either. And finally, there is an index on location_lat, but none on location_long. If you're trying to filter clubs based on location, you'd probably need an index on both columns, not just one. 🤨 We noticed the issue because the site has several Pages blocks that load clubs (2000+) based on various specific queries. P.S.: It would also be nice to have the option to filter the clubs based on their type in case you want to load only public or open clubs only. But that's more feedback that a bug. Just something to consider if you end up updating the clubs() function. (Or maybe look into it for v5. 😉)

Those functions cannot be disabled in php.ini for a single site's folder. They need to be disabled at the server level.

@Matt Another big issue that comes to mind is forms. Currently, it's really difficult to add new fields to most forms (or even modify them), and it's even worse trying to manipulate the values after the form is submitted because there are no hook points available inside the $form->values() IFs that are executed on submission. If each form had a unique ID, with preDisplay() and preSave() hook points, it would save a lot of trouble. We could extend the form class and target the unique ID more easily. I've had to get really creative in some instances to add fields to some forms in 4.x... 🙄

Since you're asking nicely, and leaving aside things already mentioned (like not being able to overload trait functions), the biggest problem I can think of is that extensions are useless or not properly implemented. The system has several issues: Extending the Member and Group classes: before it was easy enough, but then IPS forbid adding extra columns to the default tables. Now we have to implement our own code to save the fields in an extra table, add a join to load the data together with the load() function, etc. Those extensions should be updated to automatically take care of all that for us, without the developers having to implement their own code each time. It's seriously time-consuming and annoying, even more so because we have to add hooks all over to handle it. Share Links: to add new share link options, we have to hook into a function that contains a hardcoded array of options. This should be handled with extensions, too. Why do we have to search in the code for the function to overload with a hook to add them? Payment Gateways: Same issue as Share Links (#2). Payout Gateways: Same issue as Share Links (#2). Account Settings: there are plenty of applications that add new tabs/sections in this area. IP.Board 3.x had an extension for that, but it was removed in 4.x and never re-added. This is the same situation as #1. Why do we have to handle everything by adding hooks all over? This should be made into an easy-to-add extension, too. User Menu: Again, plenty of applications add new links in the logged-in user menu. Right now we have to rely on theme hooks to add new options, and sometimes themes are so modified that the hook fails to work. If we had an extension that passed the links together with the default ones it would make things much easier. I'm certain there are more examples I could mention, but nothing else is coming to mind right now.

Well, that's what I would have liked to see asked before you guys started working on v5. Nothing's going to change at this point, even if we answer. 🤷‍♂️

There is nothing you can change by default. If you want, I made a modification that adds some extra options for banned members: With it, you can block access to banned profiles and you can also automatically move them to a new group to highlight their banned status.

Do not delete them with a SQL query. Member data is all over the place in multiple tables, if you delete it only from the members and topics/posts tables you'll be in for a lot of weird issues all over the place. The best solution I can give you is to create a new group in ACP (call it TO DELETE or whatever), and then update the member_group_id column for all those members you've identified to the ID of that new group. Once that's done filter your members in ACP based on the group, and then prune them from the member search results page.

Check everything in the guides under the Themes and Customizations > Template syntax group: https://invisioncommunity.com/4guides/ This is a link to the guide specific to "request" and other similar shortcuts: