I believe there is no way that 3rd party plugins can be 100% compatible.

But in some cases it can be done where the requirement is clear. For example, all my plugins are 100% compatible with Profile Cover plugin as it's clear what other developers should do to make it compatible with it.

So something clear like that Profile Cover plugin will only help. If not I can't do anything.

Hope Matt understands my situation.

Perhaps not 100% compatible - but other developers are helping their clients and working together.

I understand everyones situation. But no one seems to understand mine. The customer. I need the features, and the 2 plugin developer both say no.

And meanwhile - it simply takes a developer to make the changes, which would be quite quick. 

If someone would even say - look its gonna take 2/4/6/$ hours at $50 per hour - then I could understand. But all I have for now, is a flat no.

As a customer, it is not a good experience.

Kind regards, with understanding, but also frustration,

Matt

And its funny, because I work for business clients - so when I cannot provide what they need - (and they can read this public forum) Oxwall gets a bad rep, and they ask for a different solution. 

Yes, I could hire a programmer - but my clients are not huge, and their budgets are tight (have you heard of the recession?)  And the idea of this platform is a plugin base - so in effect I would need to develop forks of all of the plugins to get the rich feature set. Which defeats the object and purpose of the oxwall platform/core of being based around plugins.

So if my suppliers let me down?

That affects us all!

Why does basic business need explaining?

I don't agree that I am not helping. I find it rude and hurts when I am trying to help wherever possible. Is there any other situation where I have let you know when you come to me with an issue or question?

It's not my part to make his plugin compatible.  If you are developer you should understand that I can't peek it to his plugin and post an update in the store in his name.

Message me your requirements in details and I will look on it.

But I repeat.. without looking on the logic of the other plugin ( which I don't have), I can't make my plugins compatible.

First, I need to analyze the other plugin and understand it so that I can work on my plugin.. So it involves time and cost.

Please don't take it personally Purus - I apologise unreservedly if I have offended you in any way. That is not my intention. My comments are for both you guys and for the Oxwall team generally.

I appreciate that everyone is trying to help - but no help has been forthcoming on this issue (for over 1 year now)

Sergey and yourself make a great case for the developer perspective. And I, as the customer, am giving the experience from this side of the payment. 

My requirement is simple, that the mcompose plugin work with eventx standalone.

The features of Event x stand alone are requirements for my clients and the feature of messaging event attendees is also a requirement.

I don't think Sergey has a problem with you seeing his plugin? Because I already give you access to my system, so you can see his code, anyway) and this is the case for all devs looking into an oxwall setup with a mix of plugins.

Please look at the code, and let me know the cost for your time, as a quote. I will send you a purchase order, and with the fix, I can send the payment via paypal.

Kindest,

Matt

I don't mind if Purus review the plugin code. But I would suggest to do it after Oxwall 1.7.2 release and new "Compose Message" update. New programming API will be added to Oxwall Events plugin which allows to add buttons to an event action bar. It will need to be migrated to "Extended Events", then the Send message button will appear. Also, several event handlers need to be implemented in the Extended Events plugin. Example: mcompose/classes/events_bridge.php.

So perhaps it might be an idea for developers to have a place where they can share each others code base - so those that want to, can see how and where there plugins will and will not co-operate with other relevant plugins by other developers.

I realise that 1.7.2 is coming out Sergey, and Purus is great at supporting his plugins, and will no doubt be updating it to work with the new core and base events.

Extended events and mcompose can work easily together - the time needed for collaboration on either side is not great. But it has taken over a year to have this conversation, all the time with multiple clients watching.

If oxwall allows a fork into the store - then oxwall should stand by the plugin as well as the developer. 

So if the oxwall team do not listen to the core devs (presumably you might have objected to extended events getting through, although we assume you are not on the review board, as a 3rd party dev, yourself) then they (the Oxwall team) need to suck it up. 

The fact is - Purus extended events has great features and is well built and is seen as essential by all clients who I install it for.

The fact is - mcompose adds a great feature set, is well built and is seen as essential by all clients who I install it for.

The clients simply don't understand why I/they  would need to maintain a fork of either plugin, just so the can send messages to the event attendees.

I would suggest that all developers try to remember the end client in all of this.

regards,

Matt

Guys , It's there any progress?  .. I'm also hope this plugin can be 100% compatible with extended event standalone ..