Who is viewing this topic [Deleted]

[Chris D]

The issues mentioned will definitely need to be addressed.

We don't explicitly have a rule about using phrases but there is a fairly strong expectation that phrases should be used because many people using the add-on will need to localise it or it just isn't viable for them to use it.

 

[RisteDimitrievski]

If this is an add-on for you, why was it posted here?

If you did not receive errors, this does not mean that your add-on cannot cause them. I see that a bunch of errors will fall down here in any non-standard situation.

Anyway, maybe @Chris D can help decide who's right ...?

On XFCP_Thread controller already has parent so it did not overwrite the original controller.
On entities itself already has parent and relationship extended.
if i'm not right @Chris D can tell me.

 

[Chris D]

You are not right, unfortunately.

Your approach for the Thread entity extension breaks the class proxy chain. But even so it's only one of the issues. You don't have a class extension for the XF\Entity\User class so the code you have in there isn't doing anything.

The issues with the thread controller and the reply object are valid too. It may be possible to run into issues calling setParam and other methods if the controller action doesn't return a view reply which may or may not happen by default but could happen if other add-ons are extending the same code.

We talk a bit about class extensions and extending controllers in the dev docs:

General concepts | Developer Documentation | XenForo

Developer documentation for XenForo

xenforo.com

Controller basics | Developer Documentation | XenForo

Developer documentation for XenForo

xenforo.com

If you need further support, please create a thread in the XenForo development discussions forum.

 

[RisteDimitrievski]

You are not right, unfortunately.

Your approach for the Thread entity extension breaks the class proxy chain. But even so it's only one of the issues. You don't have a class extension for the XF\Entity\User class so the code you have in there isn't doing anything.

The issues with the thread controller and the reply object are valid too. It may be possible to run into issues calling setParam and other methods if the controller action doesn't return a view reply which may or may not happen by default but could happen if other add-ons are extending the same code.

We talk a bit about class extensions and extending controllers in the dev docs:

General concepts | Developer Documentation | XenForo

Developer documentation for XenForo

xenforo.com

Controller basics | Developer Documentation | XenForo

Developer documentation for XenForo

xenforo.com

If you need further support, please create a thread in the XenForo development discussions forum.

The User entity making relationships between User and UserGroup which i use 'em in template modification to display correct css colors based on group css.

Alright, ill try to use proxy classes and then extending 'em. The same rule applies to the controller Thread too ?

 

[Chris D]

The User entity making relationships between User and UserGroup which i use 'em in template modification to display correct css colors based on group css.

But you don't have a class extension for that class, so there's nothing to tell XF that it needs to extend the class with the code in your class:

<?xml version="1.0" encoding="utf-8"?>
<class_extensions>
  <extension from_class="XF\Pub\Controller\Thread" to_class="whoviewtopic\XF\Pub\Controller\XFCP_Thread" execute_order="10" active="1"/>
</class_extensions>

Only the Thread controller extension is there.

 

[RisteDimitrievski]

But you don't have a class extension for that class, so there's nothing to tell XF that it needs to extend the class with the code in your class:

<?xml version="1.0" encoding="utf-8"?>
<class_extensions>
  <extension from_class="XF\Pub\Controller\Thread" to_class="whoviewtopic\XF\Pub\Controller\XFCP_Thread" execute_order="10" active="1"/>
</class_extensions>

Only the Thread controller extension is there.

If i use class extension on whoviewtopic:User entity then it breaks other addon's for some reason that's why i did not use class extension via xenforo admin panel. I'm sure that inside my class in user entity did not break other relationships see an example:

<?php
namespace whoviewtopic\Entity;
use \XF\Mvc\Entity\Structure;
class User extends \XF\Entity\User
{
    public static function getStructure(Structure $structure)
    {
        $structure = parent::getStructure($structure);
        $structure->relations['UserGroup'] = [
            'entity' => 'XF:UserGroup',
            'type' => self::TO_ONE,
            'conditions' => 'user_group_id'
        ];
        return $structure;
    }
}
class ThreadViews extends Entity
{
    public static function getStructure(Structure $structure)
    {
        $structure->table = "thread_views";
        $structure->primaryKey = 'id';
        $structure->columns = [
            'id' => ['type' => self::UINT,'autoIncrement' => true,'primaryKey' => true],
            'user_id' => ['type' => self::UINT],
            'thread_id' => ['type' => self::UINT],
            'read_date' => ['type' => self::STR]
        ];
        $structure->relations = [
            'User' => [
                'entity' => 'whoviewtopic:User',
                'type' => self::TO_ONE,
                'conditions' => 'user_id'
            ]
        ];
        return $structure;
    }
}

I use it in this manner see an example:
Inside my Thread controller that extends oriinal

$userswhoread = \XF::finder('whoviewtopic:ThreadViews')->where('thread_id','=',$params->thread_id)->with('User')->fetch()->toArray();
$view = parent::actionIndex($params);
$view->setParam('users',$users);
$view->setParam('userswhoread',$userswhoread);
return $view;
// just explaination how it will access via magic method Thread -> User -> UserGroup entity via relationships.
foreach($userswhoread as $key => $item){
$item->User->UserGroup['username_css']; // magic methods i use foreach inside template modification see in admin panel.

Controller thread has parent::actionIndex($params); Even setParam on $users would break if variable is null, but that i fixed the problem inside template modification.

 

[inzanty]

If i use class extension on whoviewtopic:User entity then it breaks other addon's for some reason that's why i did not use class extension via xenforo admin panel. I'm sure that inside my class in user entity did not break other relationships see an example:

<?php
namespace whoviewtopic\Entity;
use \XF\Mvc\Entity\Structure;
class User extends \XF\Entity\User
{
    public static function getStructure(Structure $structure)
    {
        $structure = parent::getStructure($structure);
        $structure->relations['UserGroup'] = [
            'entity' => 'XF:UserGroup',
            'type' => self::TO_ONE,
            'conditions' => 'user_group_id'
        ];
        return $structure;
    }
}
class ThreadViews extends Entity
{
    public static function getStructure(Structure $structure)
    {
        $structure->table = "thread_views";
        $structure->primaryKey = 'id';
        $structure->columns = [
            'id' => ['type' => self::UINT,'autoIncrement' => true,'primaryKey' => true],
            'user_id' => ['type' => self::UINT],
            'thread_id' => ['type' => self::UINT],
            'read_date' => ['type' => self::STR]
        ];
        $structure->relations = [
            'User' => [
                'entity' => 'whoviewtopic:User',
                'type' => self::TO_ONE,
                'conditions' => 'user_id'
            ]
        ];
        return $structure;
    }
}

I use it in this manner see an example:
Inside my Thread controller that extends oriinal

$userswhoread = \XF::finder('whoviewtopic:ThreadViews')->where('thread_id','=',$params->thread_id)->with('User')->fetch()->toArray();
$view = parent::actionIndex($params);
$view->setParam('users',$users);
$view->setParam('userswhoread',$userswhoread);
return $view;
// just explaination how it will access via magic method Thread -> User -> UserGroup entity via relationships.
foreach($userswhoread as $key => $item){
$item->User->UserGroup['username_css']; // magic methods i use foreach inside template modification see in admin panel.

Controller thread has parent::actionIndex($params); Even setParam on $users would break if variable is null, but that i fixed the problem inside template modification.

This code practice is very bad. The good thing is to follow to coding standards.
Firstly, you should use something like that: Classname of extension must be equals to original, after that extend XFCP_classname, where classname - original classname of extension.

 

[Chris D]

If i use class extension on whoviewtopic:User entity then it breaks other addon's for some reason that's why i did not use class extension via xenforo admin panel. I'm sure that inside my class in user entity did not break other relationships see an example:

Never do this. You must always extend classes properly and if you run into issues those issues need to be figured out. Generally nothing is so insurmountable that typical standards should be ignored.

 

[RisteDimitrievski]

This code practice is very bad. The good thing is to follow to coding standards.
Firstly, you should use something like that: Classname of extension must be equals to original, after that extend XFCP_classname, where classname - original classname of extension.

Something like this:

class XFCP_Thread extends \XF\Pub\Controller\Thread{}

After that

class Thread extends \whoviewonline\XF\Pub\XFCP_Thread
{
// code here
}

After that registering the XFCP_Thread in class extension in admin panel XF ?

 

[inzanty]

Something like this:

class XFCP_Thread extends \XF\Pub\Controller\Thread{}

After that

class Thread extends \whoviewonline\XF\Pub\XFCP_Thread
{
// code here
}

After that registering the XFCP_Thread in class extension in admin panel XF ?

It makes no difference.

<?php
 
namespace YourAddon\XF\path_to_original_classname;

class OriginalClassnameOfExtension extends XFCP_OriginalClassnameOfExtension
{
    // code of extension here
}

Based on this, the extension class should be named like the original class.

 

[RisteDimitrievski]

It makes no difference.

<?php
 
namespace YourAddon\XF\path_to_original_classname;

class OriginalClassnameOfExtension extends XFCP_OriginalClassnameOfExtension
{
    // code of extension here
}

After that, what you are registering/extending in admin control panel class extension.
assume this

class Thread extends XFCP_Thread {}

Where controller thread is in namespaceofaddon/Pub/Controller folder
and XFCP_Thread is in namespaceofaddon/XF/Pub/Controller folder

What you put inside of XFCP_Thread for an example? should that extends something or is that listener where you put structure of an entity there ?

 

[inzanty]

After that, what you are registering/extending in admin control panel class extension.
assume this

class Thread extends XFCP_Thread {}

Where controller thread is in namespaceofaddon/Pub/Controller folder
and XFCP_Thread is in namespaceofaddon/XF/Pub/Controller folder

What you put inside of XFCP_Thread for an example? should that extends something or is that listener where you put structure of an entity there ?

For example:
Base class: XF\Pub\Controller\Thread
Extension class: YourAddon\XF\Pub\Controller\Thread
The extension runs the code that you want to extend, which is logical.

 

[RisteDimitrievski]

For example:
Base class: XF\Pub\Controller\Thread
Extension class: YourAddon\XF\Pub\Controller\Thread

And where is that class XFCP_Thread ?
Does that needs a listener, and if yes for what is being used? for defining relationships?

 

[inzanty]

And where is that class XFCP_Thread ?
Does that needs a listener, and if yes for what is being used? for defining relationships?

XFCP_Thread is a class extension stub that is created by XenForo itself after the extension is created in the admin panel.
The listener is not needed here, this is completely different. I advise you to read the documentation carefully to understand the difference.

 

[RisteDimitrievski]

XFCP_Thread is a class extension stub that is created by XenForo itself after the extension is created in the admin panel.
The listener is not needed here, this is completely different. I advise you to read the documentation carefully to understand the difference.

So in admin panel i'm creating class extension:

Base class: XF\Pub\Controller\Thread
Extension class: myaddon\XF\Pub\Controller\Thread as i understand. Then after that it should add XFCP_Thread and in my controller i should extend XFCP_Thread right?

 

[inzanty]

So in admin panel i'm creating class extension:

Base class: XF\Pub\Controller\Thread
Extension class: myaddon\XF\Pub\Controller\Thread as i understand. Then after that it should add XFCP_Thread and in my controller i should extend XFCP_Thread right?

Yep, but you do not need to manually add the XFCP_Thread. Your extension must extend XFCP_Thread. XFCP_Thread will create XenForo itself for your extension. See _data/class_extensions for more details. Also, after adding it in the admin panel, metadata for the extensible class will be available in your IDE.

 

[RisteDimitrievski]

Yep, but you do not need to manually add the XFCP_Thread. Your extension must extend XFCP_Thread. XFCP_Thread will create XenForo itself for your extension. See _data/class_extensions for more details. Also, after adding it in the admin panel, metadata for the extensible class will be available in your IDE.

Entities for addons always should be inside XF right or ?
for those Entities which extends existing should also follow the same principe?
Thank you

 

[inzanty]

Entities for addons always should be inside XF right or ?
for those Entities which extends existing should also follow the same principe?
Thank you

In XF must be XenForo classes which you extend. In another case you create Entity folder in root directory plugin.
Extending principle working for all classes.

 

[RisteDimitrievski]

In XF must be classes which you extend. In another case you create Entity folder in root directory plugin.
Extending principle working for all classes.

Ok then, that was an easy job then. Thank you guys. I will address this.

 

[RisteDimitrievski]

RisteD updated Who is viewing this topic with a new update entry:

Fix potentional issues and bugs that may affect other addons

• Fixed issue where in some cases can break other addons.
• Improved code to follow XenForo Resource standards.

Read the rest of this update entry...