XF 2.1 What's new for developers in XF 2.1?

It's ok, developers, breathe a sigh of relief... We do have some good things for you in XF 2.1 but at a slightly smaller scale than the changes we introduced in XF 2.0 šŸ˜‰

Welcome to the seventh (admittedly developer oriented) "Have you seen...?" thread for XF 2.1. As ever, if you've not yet seen the previous entries, (why not?!) you can check them out here.

To ensure you're kept up to date, we strongly recommend giving that "Watch forum" link a scare and make sure you enable email notifications if you haven't done so already šŸŽƒ
 
Thanks Chris

When I upgrading from XF1.5 to XF2.1, will ā€œLikesā€ be imported into Reactions system? I am talking about XF Likes only.
 
@ChrisD with the withAliases do we just chain more closures to the array for a context with each additional add-on? The example isn't 100% clear.
Not totally sure I follow what you're asking, but if you want to add things for an add-on, you can just add additional elements to the array, either strings or closures if you need conditional behavior.

The "context" isn't really add-on specific, though you can use it like that if you are making a particular request in an add-on. That isn't really viable if you want to include extra things when a thread is fetched for the list display, for example. The full vs fullForum / full|forum example is basically showing that options can be passed in based on other things you may want to be fetching. In this case, in some contexts, we need to fetch the forum info for a thread (such as when viewing it directly or on something like what's new), but in other cases, we don't want these joins at all (like when listing the threads in a particular known forum). It isn't really assumed that add-ons would be changing the context/options in core code, but reacting to them if needed.
 
New XF:Delete controller plugin
tenor.gif


Entity withAliases
hd7rC6V.gif


Improved Composer support for add-ons
tenor.gif



---
The arguments passed into the controller plugin are simply the entity being deleted, the link to your controller action, a relevant edit/view link for the content, the URL to redirect to after deletion and the title of the content. There is an optional sixth argument so you can pass in a custom template, if needed.
Just to be clear, you do need an optional seventh parameter that allows you to pass extra $viewParams to the custom template.

Use case: Let's say you're deleting a piece of content that has sub-content, e.g. "Deleting this calendar will also delete 5 event(s). Are you sure?"

1540899247714.webp


Also, I don't think this action supports states? Ideally, you should make it so the deletion popup can offer either the plain deletion like you show, or this:
1540899119017.webp


Perhaps a new deletion plugin action that can also handle a closure for the "notify" checkbox? I feel like this would be useful in the core XF as well, nor just 3rd party plugins.


Fillip
 

Attachments

  • 1540899083386.webp
    1540899083386.webp
    9.9 KB · Views: 59
Just to be clear, you do need an optional seventh parameter that allows you to pass extra $viewParams to the custom template.

Use case: Let's say you're deleting a piece of content that has sub-content, e.g. "Deleting this calendar will also delete 5 event(s). Are you sure?"

Also, I don't think this action supports states? Ideally, you should make it so the deletion popup can offer either the plain deletion like you show, or this:
The deletion plugin is really for simple cases. If you have more complex needs, then it's not really expected that you'd use the plugin.

While not explicitly tied to the ACP, it's more targeted at the D part of simple CRUD actions.
 
The deletion plugin is really for simple cases. If you have more complex needs, then it's not really expected that you'd use the plugin.
I can see that for the state part, but I don't think that should apply to the "extra viewParams" part. Alerting users they may be deleting more than they potentially want isn't really too complex.

I know you can technically fetch the information via calls to repositories in the custom template, but then you'd potentially be creating an entirely new repository method for something that only happens on this exact deletion page, which seems a bit silly.


Fillip
 
Yeah there's one, maybe two places in XF we don't actually use it, but it should be good for the majority of cases.

Theoretically, it's possible to hook into it in terms of detecting whether you're in the GET or POST part of the request, and it returns a view or a redirect so you can check what the plugin returns and take different actions, add different view params etc.

But then by the time you've done all that, you might as well have just written your own delete action ;)
 
View attachment 186584

(I still think the additional seventh custom viewParams argument is a good idea even for simple delete actions šŸ˜)


Fillip
Well, again, you can already do it, just not through a seventh argument. It's really not what we're targeting so if you need to do something special you'll have to stick with a custom approach. This is a workaround if you feel it's absolutely worth it:
PHP:
public function actionDelete(ParameterBag $params)
{
   $notice = $this->assertNoticeExists($params->notice_id);

   /** @var \XF\ControllerPlugin\Delete $plugin */
   $plugin = $this->plugin('XF:Delete');

   $reply = $plugin->actionDelete(
      $notice,
      $this->buildLink('notices/delete', $notice),
      $this->buildLink('notices/edit', $notice),
      $this->buildLink('notices'),
      $notice->title,
      'my_custom_template'
   );

   if ($reply instanceof \XF\Mvc\Reply\View)
   {
      $reply->setParams([
         'customParam' => true
      ]);
   }

   return $reply;
}
 
It's really not what we're targeting so if you need to do something special you'll have to stick with a custom approach.
A bit frustrating to have to do that when it could be solved by something as simple as
PHP:
$viewParams = [
   'entity' => $entity,
   'title' => $title,
   'editLink' => $editLink,
   'deleteLink' => $deleteLink
] + $params;
but okay :P

Given it'd be an optional parameter, and it doesn't really add any time in terms of additional QA, I'm not sure I understand the resistance to adding this, when it would eliminate the need for workarounds.


Fillip
 
A bit frustrating to have to do that when it could be solved by something as simple as
PHP:
$viewParams = [
   'entity' => $entity,
   'title' => $title,
   'editLink' => $editLink,
   'deleteLink' => $deleteLink
] + $params;
but okay :p

Given it'd be an optional parameter, and it doesn't really add any time in terms of additional QA, I'm not sure I understand the resistance to adding this, when it would eliminate the need for workarounds.


Fillip
Fine. It's done. Now let's all move on with our lives :p
 
OK, most of that goes over my head... :D But it all looks to make creating new themes and add-ons easier.

IE9 and IE10, on the other hand, haven't been around since the days of Windows 7 and Windows 8 respectively. Even Internet Explorer 10 was first released over 6 years ago.
Oh, the days I used to spend having to make old sites compatible with IE6 and Netscape 4.7! With the latter, it used to make <textarea> boxes disappear on some sites, including on the WebBBS forums I used to run! 4.7 was the worst version of any browser I came across in terms of breaking sites! IE6 was just a constant pest--sites would look good in every other browser, then IE6 would break them, requiring all sorts of flaky workarounds to get them to comply. (Those were the days before web standards found their way to IE.) It was also the most persistent browser--we'd think that after years it would be outdated, yet our logs would show a substantial number of visitors still using it. And if we ever introduced something new to a site or forum, sure enough, someone with IE6 would start complaining we had "broken" something. IE6 was more common than bedbugs in Detroit...
 
Back
Top Bottom