How to change core module files in socialengine4 - php

I am developing modules in socialengine4. Now I need to change the core functionality of the application. I need to make some changes in user signup process by adding some core features like proving auto complete fields.
I know this is a core feature of User module of SocialEngine. But This is not a good practice because any update of socialengine will override my changes.
I have searched the solution but couldn't be able to find any thing. I know if you want to change any thing in core modules of magento, it directs us specific way to do that. Similarly I want to know the process, how can I change in socialengine?
Regards

It depends on what you want to change on SocialEngine core.
To change the signup process (for example add a new step), you have to add a new row in this table engine4_user_signup and implement your new step.
If you just want to add some actions after a user signup successfully, you can add a Hook in your custom module.
To implement a hook in Socialengine, following these steps:
Define hook in manifest file, will be something like below
'hooks' => array(
array(
'event' => 'onUserCreateAfter',
'resource' => 'YourPluginName_Plugin_Signup',
),
),
In the plugin class YourPluginName_Plugin_Signup, add this method onUserCreateAfter
public function onUserCreateAfter($payload)
{
$user = $payload->getPayload();
//Do whatever you want
}
Hope this can help you.

I'm not the slightest bit familiar with Social Engine, but seeing that it offers plugins:
http://www.socialengine.com/customize/se4/plugins
… I feel rather safe to suggest that there's some kind of API that allows you to hook into, and probably override, whatever core functionality you're not entirely happy with.
If it's anything like Symfony, Drupal or WordPress, there more often than not is some kind of event, hook, action, filter, whatever, at a key step in the process. It should allow you to catch whatever core has come up with to that point, trash it, and entirely override and "redo" it. The key here is to have a thorough understanding of the APIs involved — no amount of asking SO questions will spare you from reading the docs.
What occasionally happens, that being said, is that the only plausible candidate event is uncooperative, in the sense that it comes too late and only allows you to "add" something extra to what has been done already. In this case, you can take the higher ground and fight back by finding an earlier event. Start an output buffer on it, and trash this buffer in the uncooperative event. Now, you redo things as the way you want them, without losing your changes during upgrades.
Note that doing the latter is not risk-free, though. If anything, it adds a huge burden on you: if core changes anything in this area that you've redone from the ground up, you need to make sure that your overriding it doesn't break when you upgrade the application.

Related

Plugin with Observer Pattern

I have recently look into observable pattern and I understand how things work and the concept. I also played with it in my application but I want to find out how to use it when you want to make a plugin in a php application, because that was my main purpose.
I haven't found any decent example until now. I want to understand the concept of making plugin with observable and also a good and easy example would be nice.
By making a plugin I mean to have a standard application and want to do some particular stuff for every client, because not all the clients ask the same things I can't give them all the same application, so the ideas so to make a standard application and configure it for every client and I understand that something like that is called to make a plugin and It can be done with observer.
Observer/Observable pattern would be a good fit if you want to implement some kind of custom triggers/actions based on user or application/service actions.
For example, an identity/authentication service might implement a pluggable architecture using some kind of observer to let third-party plug-ins do something when some user authenticates, or some user is registered...
Also it should work in the UI, because you might be able to show a menu or add some visual component based on user interaction.
If you want to make a very free plugin based application, you might want to do a slightly different version of this.
Implement a centralized event control.
Each Plugin (serving as your controllers) registers there to be notified for certain events.
Now if you want to access some functionality, just dispatch a specific event through that central event control. You no longer need to know what plugin will respond to your event, you only need to know the interface of said event and the form of response you will get.
Now multiple plugins can register on a event, overriding or extending the results of other plugins. Or just allow completely new events.
This application structure takes a bit of patience to properly create all needed classes, but the end product is extremely decoupled -> flexible. Think of it as a form of MVC where the controller(s) dont need to know each other, they just know where to ask in a very generic form.
(I heard Zend2 tries a similar approach?)

PHP Plugin System: where to create plugin hooks in my application?

I want to add a plugin system to my PHP application.
I'd like to create a hook system where my plugins register themselves to these hooks. So for so good. The problem is knowing from start what kind of hooks to create.
Are there any guidelines on how to do this? Should I have a hook for every point in the app where I might want to update data? Hooks for outputing data?
Would I need to have a hook for something like "before_script_ends", "before_avatar_output"?
This seems pretty opinion based...
I'd start with requirements of what your developers are asking for in this plugin system. Try just kicking it off thinking about minimum viable product. What things would be most beneficial. I'd vote with routing type features so probably create hooks for that. That may actually be all you need.
Also decide if a plugin system is what you want. You might prefer more separated apps. In which case a rest based/oauth like approach might be more appropriate.
It is hard to say with out some specific use case.

PHP: Creating Extensible CMS System [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have been given a new task from the client which is basically creating a CMS for actors/singers and the like that client will be selling out to them.
It will basically be a package and would work out-of-box pretty much similar to WordPress, you just hand over to whoever buys it but of course this is not going to be a blogging platform. It will allow developers to:
Add plugins/widgets
Add templates/themes
I thought the Observer Pattern may be useful but I am not that sure about it. What you guys could suggest to create such flexible/extensible CMS in terms of:
Ability to add plugins (for example like WordPress)
Ability to add themes/templates (for example like WordPress)
Design Pattern
Any other things
Observer's fine, but you're going to have to consider going beyond the basic pattern. The canonical Observer/Subject pattern only sends the Subject object to the Observer, nothing else, not even why it's being notified.
Initially, the solution might seem like also including the reason for the notification to the Observer, but then you might end up notifying Observers that don't care about certain notifications. A better solution might be requiring Observers to also ask for a list of notifications they'd like to receive.
But that also presents a problem. In order for the Observers to actually attach themselves to Subjects, they have to be instantiated. Every single time. Even if they'd never be needed. That's silly.
So, we've quickly reached one of the canonical PHP implementations of plugins: "hooks". Hooks use the same concept as Observer/Subject, but the implementation is different in a very important way: the actual Observers aren't instantiated in order to Observe Subjects. Instead, Subjects send a notification to some variety of central repository. This repository is configured with a list of all installed and activated plugins (Observers), and contains a list of all of the events that each plugin wants to receive. Each plugin and notified only when the event takes place, often through a static method rather than by creating an instance of the plugin and notifying it. call_user_func_array and a good autoloader makes this incredibly trivial.
You can therefore create a simple Interface for all plugins to implement. Methods that you'll need include but are not limited to:
Something to fetch data about the plugin, such as it's name, author, official website, version, etc. Human-consumable information.
A method returning the events that the plugin wants to subscribe to.
An installation method, for things the plugin needs to do in order to install itself, such as manipulating the database.
An uninstallation method might be handy as well.
The (probably static) method that will receive event notifications and return whatever data is needed.
Depending on how far you take the plugin concept, you could end up with plugins that have user configurable options. You might need to take that into account. Down that road lies madness and configuration systems.
In order to make plugins effective, you're going to need to place hooks everywhere, and frequently work with end-users to add new hooks where they are needed.
Widgets can easily work in a similar way, as plugins that get called prior to page rendering.
Themes/templates, oh my. You probably have two big options.
Smarty, or a similar template engine. Or your own not-PHP template engine.
PHP templates.
This decision will be driven by your end users. Smarty is incredibly limiting, but if you want to make sure that only approved code runs in a template, it might be a viable option. Furthermore, it's not unsafe to allow editing of Smarty templates right in the application itself.
On the other hand, one of the reason Wordpress templates work so well is that they're pure PHP. They can call any method exposed in the Wordpress API, and even do their own interesting logic. If you expect your end users to be technically minded, or at least technically competent, then PHP templates are the way to go. On the other hand, allowing editing of PHP templates within the application can open up a huge potential security hole if a malicious user gets into the admin bits. You probably want to restrict editing to the filesystem.
While this covers HTML creation, you should also take CSS into consideration. Will your end-users be able to manipulate CSS directly? Will they want to? If your default templates include enough semantic classes, they can probably do a great deal of styling with not a lot of effort, if they know what they're doing. On the other hand, your end-users might not know what CSS is, so they might want, oh, say, color pickers and pre-built color schemes, and a color scheme chooser, and other such annoying things to build. It's probably best to think about those horrors now.
Miscellaneous things.
No CMS would be complete without the concept of drafts and publish states. I don't have any advice for you here, other than code this first. If your customer or the end-users want any sort of historical archiving, managerial approval mechanism, or anything else that makes draft/published anything but a simple state field, you need to know very soon. (I've been bitten horribly by this one. We'd designed the entire system around a simple published/not-published model, and got about 9/10ths through spec building and related prototype code when we realized it wouldn't work and we'd have to do something far, far more complex to actually meet customer requirements. Rebuilding the rough plan was the single largest time-sink we encountered so far.)
Will you use an ORM? If not, be sure to use a proper database interface library. PDO, or maybe something from PEAR, or maybe Zend_Db. You'll inevitably have a customer that will insist that the code runs on Oracle or MSSQL. Or SQLite. It'll be nice to tell them it can be done (with some effort). Plugin authors will thank you for the sanity as well. Don't roll your own.
(Then again, with your rep level, I expect that you're already familiar with pretty much everything I've said. Ah, the things I do to distract myself while thinking about my own set of coding problems...)

When to develop a new drupal module vs. work with what exists?

This can probably apply to other extensible content management systems, but I've been working with Drupal. Specifically I created an image sharing web application whose functionality relied on more original code than Drupal core code. I used the WebForm module and point its forms at Custom Pages with hard coded php to have nodes created programmatically and other strange voodoo.
Just before I was done I realized I perhaps should have just made my own module, or should I have?
Even in retrospect it's difficult to tell.
What do you use to decide when a new module needs to be written and when the functionality you're seeking can just be kludged together from what's available?
I have a strong opinion on this, which is that all custom coding should be done within custom modules, with only one possible exception (see below):
I discern three cases:
Completely new functionality - this obviously calls for a custom module that encapsulates the new functionality. It makes it reusable and can even turn into an 'official' contributed Drupal module, if the functionality meets popular demand.
Tweaking existing functionality - for every site, I immediately setup a blank, custom module (named after the site). All custom code used for tweaking existing functionality (be it from core or contributed modules) happens within this module. That way, all my customizations are cleanly separated, which makes it much easier to update the core or other modules without constantly having to reapply my customizations to the updated code (of course one has to check if the customizations still work after the update and adjust or remove them as needed).
Fixing bugs/adding missing features - this is the possible exception mentioned above. If my changes are just a bug fix or an addition of an obvious, but missing feature, I might just do that within the original code, submitting my changes as a patch to the original module, hoping that they will get incorporated in a future release, thus making my changes obsolete.
In my experience, the 'overhead' of separating the customizations from the original code isn't really an 'overhead', as the 'one-off' tweaks & fixes usually stick around much longer than anticipated, and have a tendency to grow over the lifetime of a site. Having them separated from the start saves a lot off troubles down the road in maintenance, as applying updates & security fixes, as well as extending the tweaks will be much easier.
Make a new module when you want to share or reuse the functionality easily. There is overhead in doing so, so if it's a one-off it's not worth it.
What i prefer doing is a full-on search on drupal.org for any/all modules that have the functionality that I require. I search drupal.org & groups.drupal.org (& maybe even the forums) with that module(s) name to see what other folks are saying about it. Lastly, I always check drupalmodules.com to see what others in the community are saying about it.
If I can't find exactly what I need, I roll out my own module. Plynx is right also, if you plan to reuse the functionality, create a new module IF it's unique enough to not exist yet.

build a plugin system with php

I'm working on a custom CMS for my own use and was thinking about implementing a plugin system so I could extend the code a little easier. I'm having trouble conceptualizing the architecture and layout though.
I know I could go through a few open source programs that implement similar features but this is really just academic at this point so I really don't want to spend too much time digging through foreign code.
Does anyone have any good ideas of how to proceed? If someone could outline how some of the more popular programs do it that'd be perfect.
Define the functionality you want the plugins to plug into (ie, what will they do and over what)
Define a class hierarchy on which plugins fit, like, all article mangling plugins should inherit from ArticleMangler
Define a physical location for plugins, like /plugins
Import all plugins present in the location
Use either Decorator or Observer patterns to inject the plugin's behavior or to notify the plugins of events occurence. Strategy might be applicable in some cases as well.
PHP makes this fairly easy at a potential cost of making a mess if you're not careful. I like the Observer method where plugins register themselves to a plugin manager which notify them of what happened and wait for their action to happen.
If you don't trust plugins then you'd have to put add controls over which events you are going to allow any plugin to register for.

Categories