teraßyte

3 minutes ago, Esther E. said:

Just dropped.

I assume templates are wiped (since they're completely different?), but this will leave a lot of unused settings, tasks, widgets, etc, around in the database then. 🤨

1 hour ago, Esther E. said:

Plugins will be deleted completely, as the entire table is dropped. Your local files should still be present, though. 

Will plugins be "uninstalled" (deleting all settings, templates, etc) or is the table simply dropped in the upgrade step?

I'm not sure how the scanner works right now, but I guess it scans the used language strings and checks if they exist in the lang.php file? If so, it should also check for required language strings that the system expects when you add a specific extension/feature/node/etc.

For example, when you add a Node/Item that supports search, you need to add specific language strings for the quick search menu, contextual search menu, etc. All those language strings are not documented anywhere. Another thing to check are the required language string for admin/moderator restrictions in ACP.

There are a few more areas, but I can't remember them now.

11 minutes ago, Esther E. said:

Technically the cart will accept any item, you'd just have to add the button on your end to add it to the cart.

What about the ACP? For example, when creating an invoice manually in 4.x it's impossible to add a Downloads file right now.

I also hope Custom packages are heavily reviewed for v5, since they have several bugs.

Rather, I've reported plenty of bugs (for Commerce and all other apps), and several are still open and untouched even with fixes provided in them (some since 2021-2022). 🤷‍♂️

If that area is not covered, it definitely should. I have plenty of modifications that add buttons there. An example would be my (TB) Bump Up Topics plugin.

8 hours ago, Daniel F said:

You can still run the group check and include the necessary js/css files, or set the JS variables only when it’s needed.

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:

12 hours ago, teraßyte said:

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.)

10 hours ago, teraßyte said:

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.

11 minutes ago, Esther E. said:

In theory you could remove them entirely using JS, not just hide them. 

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.

13 minutes ago, Esther E. said:

As Matt has said in previous entries, there are things that you will no longer be able to do, and that's intentional. 

You will be able to do most things, but not all. 

That said, I can think of some ways to do what you're asking, but let's wait until we have all the dev tools announced and then I'm happy to discuss. I don't want to start giving suggestions about things I can't show you in full. 

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. 🤞

5 minutes ago, Esther E. said:

That's correct, but you can always use Javascript and/or CSS to hide fields.

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.

18 minutes ago, Matt said:

But it can’t continue. In the past, we’ve changed the signature params in getItemsWithPermissions() and had to patch the release as tickets pile up as apps which overload that just break.

Internally we have a rule not to touch function params of commonly hooked methods. It means we can’t make changes to our PHP code without breaking loads of client sites. This means we can’t clean up and modernise our own code.

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. 😋 😹

1 minute ago, SeNioR- said:

Controversial topic, I like it. 🫢 Adriano, good luck with the update over 300 resources 😁

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.

4 minutes ago, Esther E. said:

Without looking at the source code of your modification, I am pretty sure it can still be done. Just from looking at the screenshots and the feature list.

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... 🙄

1 minute ago, Daniel F said:

Not sure about your first example, but the "Delete All System Logs Button" won't be a problem at all!

As Matt or Esther said, just wait for our further blog entries, especially about the new UIExtensions

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.