Implement plugins manager structure

[shahryarjb]

After talking to @pouriya, I have decided to research about ejabberd plugins manager solutions. Then we stop doing all updates out of our issues and start learning and implementing a basic structure of plugins manager.

This structure should force developers to work in a prepared template, which is introduced by MishkaCMS core in its documents

---

• Stop the Deadlines
• Send a post about it to Elixir forum
• Create a schema and graph about implementing
• Considering Joomla events → Implement plugins manager structure #148 (comment)
• Change version 0.0.2 plans of Projects (Project 0.0.2)
• Register Hook v1
• Start Hook v1
• Restart Hook v1
• Stop Hook v1
• Delete Hook v1
• Unregister Hook v1
• Call init of developer's plugin functions, when server is started
• Call Hook v1
• ensure_event? Hook v1
• Test Hook
• Test state
• Implement plugin system
• Check libgraph for dependencies and plugin connections mishka-group/mishka_installer#2
• Start creating tests
• Create db of plugins
• Force mishka_installer just includes {mishka_database, mishka_translator} #168

It doesn't matter we should duplicate activity of mishka_content because it helps us to delete circle of deps

• Identify some predefined behaviors and callbacks
• Add depends callback, based on Implement plugins manager structure #148 (comment)
• Specify event naming structure
• Create plugin system documents #163
• Put plugin caller into API side with conn output #164
• Put plugin caller into HTML side with socket output #165
• Create Genserver state #155
• Create Genserver Supervisor
• Create Genserver Binding from beginning starting server
• Create all events call back v1 #160
• Define developer's custom plugins events #154
• What we should do for custom installation of template? #153
• What we should do for custom installation of new sub-system or import new event name for new template? #161
• Separate some modules and convert them as a new plugin! #166

1. Register and Login sending email
2. Date converter, Jalaali

• New features?

1. what we should do about router? (the plugins need to import routers)
2. Decide how to inform admin to update the plugins which have new versions (What is the policy for the development of this repository? hexpm/hexpm#1124)
3. Add a better way to remember all the plugin added in Application to restore them.

I will update this post , connect this to some pull requests

---

Initial diagram

---

Talks:

1. Start the proposal and the topic raised --> https://youtu.be/FPDxyX4RzZc (Persian)
2. Suggestion to bind dynamic supervisor form starting server --> https://elixirforum.com/t/45419

---

Refs:

1. https://github.com/processone/ejabberd/blob/master/src/gen_mod.erl#L89-L92
2. https://hexdocs.pm/plug/Plug.Conn.html
3. https://www.ejabberd.im/
4. How to add and install deps without stopping phoenix server (hex package)
5. How to create Ecto temporary tables for test a library
6. Need advice to implement custom extension and template installation in an elixir CMS
7. How to check a macro was called in a module
8. https://docs.joomla.org/Plugin/Events
9. https://developer.wordpress.org/plugins/hooks/actions/
10. https://elixirforum.com/t/how-to-get-ecto-stream-respond-in-exunit/46138
11. https://elixirforum.com/t/genserver-doesnt-consider-ecto-sandbox/46105
12. https://elixirforum.com/t/dynamicsupervisor-terminate-genserver-state-in-transient-restart-method/45932/2
13. https://elixirforum.com/t/genserver-terminate-strategy-and-re-bind-data/45779
14. https://elixirforum.com/t/how-to-send-sandbox-allow-for-each-dynamic-supervisor-testing/46422/4
15. What is the policy for the development of this repository? hexpm/hexpm#1124

[mojtaba-naseri]

With this pattern, we need strong documents. Do you have a plan to import new event names for custom sub-system now?

[shahryarjb]

@mojtaba-naseri, unfortunately I have no plan for new component or sub-system what developers create, but I added it as a TODO for re-search in first post

[iArazar]

If we prepare extra arguments to implement dependencies and priority to load plugins can be helpful, for example:

• Priorities of plugins registered in an event
• Does a plugin need another high-priority output?
• Just load the plugins in order, or we drop them?

[pouriya]

In Ejabberd modules there is a callback function depends with return value in form of:

[{another_module, hard}, {foo_module, soft}]

hard means this module needs another_module to be configured and started and soft means this module only calls some utility codes of foo_module So we need to install foo_module but not to start it.

And the module manager system makes a direct graph for modules to start them here.

[shahryarjb]

@pouriya Thank you, it is an excellent idea and solution. This makes developers more organized and also gets more information from a plugin. Infrastructure (plugin system manager) can also be more secure when running a product. I added this guidance to first post's TODO list.

Sincerely yours.

[shahryarjb]

@iArazar I will consider high-priority of plugins output

[shahryarjb]

@pouriya, Hello again, I have read about your comment below, but I have not understood what is it? I think there is a different keyword in elixir. Would you mind explaining about this feature?

And the module manager system makes a direct graph for modules to start them here.

[pouriya]

you mean the digragh library? it's for dependency detection and prevents circular dependency between plugins

[shahryarjb]

Thank you @pouriya, I think ‍‍‍‍mix in elixir does this job 🧐 🤭, but I will test it.

you mean the digragh library? It's for dependency detection and prevents circular dependency between plugins.

Thank you again for all your efforts, I am appreciated.

[shahryarjb]

In the first phase, about 32 events were selected from Joomla!; it is without MishkaCms custom events.
Each event targets a part of the CMS and can be an HTML view or just doing something.

Updated, some events were deleted

  @spec system_events :: [event]
  def system_events do
    [
      # Content
      %Event{name: :on_content_prepare, section: :mishka_content, reference: Ref.OnContentPrepare},
      %Event{name: :on_content_after_title, section: :mishka_content, reference: Ref.OnContentAfterTitle},
      %Event{name: :on_content_before_display, section: :mishka_content, reference: Ref.OnContentBeforeDisplay},
      %Event{name: :on_content_after_display, section: :mishka_content, reference: Ref.OnContentAfterDisplay},
      %Event{name: :on_content_before_save, section: :mishka_content, reference: Ref.OnContentBeforeSave},
      %Event{name: :on_content_after_save, section: :mishka_content, reference: Ref.OnContentAfterSave},
      %Event{name: :on_content_prepare_form, section: :mishka_content, reference: Ref.OnContentPrepareForm},
      %Event{name: :on_content_prepare_data, section: :mishka_content, reference: Ref.OnContentPrepareData},
      %Event{name: :on_content_before_delete, section: :mishka_content, reference: Ref.OnContentBeforeDelete},
      %Event{name: :on_content_after_delete, section: :mishka_content, reference: Ref.OnContentAfterDelete},
      %Event{name: :on_content_change_state, section: :mishka_content, reference: Ref.OnContentChangeState},
      %Event{name: :on_content_search, section: :mishka_content, reference: Ref.OnContentSearch},
      %Event{name: :on_content_search_areas, section: :mishka_content, reference: Ref.OnContentSearchAreas},
      # Captcha
      %Event{name: :on_init, section: :mishka_user, reference: Ref.OnInit},
      %Event{name: :on_display, section: :mishka_user, reference: Ref.OnDisplay},
      %Event{name: :on_check_answer, section: :mishka_user, reference: Ref.OnCheckAnswer},
      %Event{name: :on_privacy_collect_admin_capabilities, section: :mishka_user, reference: Ref.OnPrivacyCollectAdminCapabilities},
      # User
      %Event{name: :on_user_authorisation, section: :mishka_user, reference: Ref.OnUserAuthorisation},
      %Event{name: :on_user_authorisation_failure, section: :mishka_user, reference: Ref.OnUserAuthorisationFailure},
      %Event{name: :on_user_before_save, section: :mishka_user, reference: Ref.OnUserBeforeSave},
      %Event{name: :on_user_after_save, section: :mishka_user, reference: Ref.OnUserAfterSave},
      %Event{name: :on_user_after_delete, section: :mishka_user, reference: Ref.OnUserAfterDelete},
      %Event{name: :on_user_login, section: :mishka_user, reference: Ref.OnUserLogin},
      %Event{name: :on_user_login_failure, section: :mishka_user, reference: Ref.OnUserLoginFailure},
      %Event{name: :on_user_after_login, section: :mishka_user, reference: Ref.OnUserAfterLogin},
      %Event{name: :on_user_after_logout, section: :mishka_user, reference: Ref.OnUserAfterLogout},
      %Event{name: :on_user_after_save_role, section: :mishka_user, reference: Ref.OnUserAfterSaveRole},
      %Event{name: :on_user_after_delete_role, section: :mishka_user, reference: Ref.OnUserAfterDeleteRole}
    ]
  end

[shahryarjb]

In this time, we tested an event and 2 status of a hook plugin {:reply, state()} | {:reply, :halt, state()} 🖤

---

Update new event:

%Event{name: :on_user_after_save_failure, section: :mishka_user, reference: Ref.OnUserAfterSaveFailure}

[shahryarjb]

We separated Elixir system plugin manager to new Repo

[shahryarjb]

Done!