SocialEngine / phpv4-feature-requests

The purpose of this repository is to collect SocialEngine PHP public feature requests.
https://www.socialengine.com
1 stars 0 forks source link

Update Core Libraries #94

Open DonnaScriptTechs opened 7 years ago

DonnaScriptTechs commented 7 years ago

From @Elshara on April 14, 2017 4:15

(Thanks for reporting an issue! Please make sure you click the link above to view the issue guidelines, then fill out the blanks below.)

What are the steps to reproduce this issue?

  1. … Zend has been updated in 4.9 however many libraries besides tinymce have not.
  2. … Some of the most pressing are required for better, faster access.
  3. … Doing so will make a world of difference in performance.

What happens?

… Slower servers have trouble with file performance. Especially if the files themselves pass through many different libraries to be served to users. Most notably, mootools, chootools, flowplayer, have all received updates. Other libraries includes but aren't limited to, Autocompleter, Calendar, Desktop Notify, Fancymenu, Fancyupload, Firebug, html5media, mdetect, Moocomet, Moocrop, Moolasso, Mootree, Musicbox-Font, Open Flash Chart, Smoothbox, Soundmanager, Swfobject, Tagger, Tinymceres, Wysihtml5, Bootstrap, Engine, Facebook, Janrain, OFC, Pear, PHPUnit, Scaffold, Session, User Authorization, CSS 3 Styles, Vector Graphics, Language Fields and maintenance functionality. This is just for the core product, not to mention widget functionality is out of date in many plugins or modules as well as the entire modular structure is reliant on far too many database queries. Such as the mobile plugin for example.

What were you expecting to happen?

… All of the above to receive attention, or refined with newer, modern code standards.

Any logs, error output, etc?

(If it’s long, please paste to https://ghostbin.com/ and insert the link here.)

Paste Log Here

Any other comments?

… The web deserves accessible, performance driven sites to empower people to use them. It is worth mentioning search engines refuse to index social engine sites for such reasons being too heavily involved in modular structures for coding practices. Too many .htaccess files, core dependencies and database draws, make such an impossible task to complete without error or problems. Hence my reason for posting such here. In hopes it will be considered.

What versions of software are you using?

Operating System: … Windows 10 personal. Linux web server.

SocialEngine PHP Version: … 4.8.13

Copied from original issue: SocialEngine/phpv4-issues#665

DonnaScriptTechs commented 7 years ago

From @SpiritWolfie on April 18, 2017 15:53

Agreed, Moo is also super out of date, and this could be causing problems, when things are left super out of date and those tools have been updated to include fixes for countless things, which could be fixes for problems we're having issues with,

they shouldn't be X years old.

it might be wise to provide a way for us to safely update them, Multiple other platforms offer ways to update modules like these safely, so it can be done.

DonnaScriptTechs commented 7 years ago

From @Elshara on April 18, 2017 18:12

That's why I posted it. Buddy I'm just tired of upgrading to do it again in a month without significant maintenance releases in the mean time due to all of this stuff.

On 18/04/2017, SpiritWolfie notifications@github.com wrote:

Agreed, Moo is also super out of date, and this could be causing problems, when things are left super out of date and those tools have been updated to include fixes for countless things, which could be fixes for problems we're having issues with,

they shouldn't be X years old.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/SocialEngine/phpv4-issues/issues/665#issuecomment-294889367

DonnaScriptTechs commented 7 years ago

From @gsf00001 on April 19, 2017 16:33

Leapfrogging is seldom a good when it's an indefinite process.

Yes, a lot of good things have been added/fixed/updated with 4.9 and I thank SE for all their hard work and (I'm sure) many extra evening/weekend/holiday hours to get this out.

My hope is that once 4.9.01 or .02 (sorry - 4.9.1 or .2 - I'm used to zero-padding especially for sorting purposes) is out that some focus/time may be diverted to incorporating more 'current' technology (modules, apps, HTML5, newer Zend, etc. etc.) into an upcoming release (maybe for 5.0? but I hope sooner, unless the sub-versions move very quickly). It sometimes seems that by the time something is incorporated into SE it's way past it's useful date (ex. using a newer Zend 1 instead of 3.x, even though Zend 1 can incorporate newer security patches). Yes I realize that this would be a very major project/process but sometimes it's better to replace the clutch parts & timing belt & water pump & other stuff all at the same time, rather than piecemeal it and forever be fixing/updating something just to buy a little time until the next update (and wait to see if something more major breaks that could/should have been done earlier).

DonnaScriptTechs commented 7 years ago

From @Elshara on April 19, 2017 16:59

I'm reminded here of a situation similar to if you enter a tour bus with the high expectations, unless the driver gets into an accident, he or she can act like a crazy, get drunk on the job and get away with it because who would complain if they didn't need to?

On 19/04/2017, gsf00001 notifications@github.com wrote:

Leapfrogging is seldom a good when it's an indefinite process.

Yes, a lot of good things have been added/fixed/updated with 4.9 and I thank SE for all their hard work and (I'm sure) many extra evening/weekend/holiday hours to get this out.

My hope is that once 4.9.01 or .02 (sorry - 4.9.1 or .2 - I'm used to zero-padding especially for sorting purposes) is out that some focus/time may be diverted to incorporating more 'current' technology (modules, apps, HTML5, newer Zend, etc. etc.) into an upcoming release (maybe for 5.0? but I hope sooner, unless the sub-versions move very quickly). It sometimes seems that by the time something is incorporated into SE it's way past it's useful date (ex. using a newer Zend 1 instead of 3.x, even though Zend 1 can incorporate newer security patches). Yes I realize that this would be a very major project/process but sometimes it's better to replace the clutch parts & timing belt & water pump & other stuff all at the same time, rather than piecemeal it and forever be fixing/updating something just to buy a little time until the next update (and wait to see if something more major breaks that could/should have been done earlier).

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/SocialEngine/phpv4-issues/issues/665#issuecomment-295335118

DonnaScriptTechs commented 7 years ago

From @SpiritWolfie on April 21, 2017 21:20

@gsf00001 From what I understand anything 5.0 we have to pay to upgrade to the level.. which is crazy considering how much stuff is broken because of out of date technology or choice of modules they are using.. like TinyMC (Which no other platform really uses because of how bad it is)

if we take SE and compare it to some open source platforms, (namely Druple or Joomla) your notice nether of these two use TinyMC, why? because its horrible.... and has been for a long time.

DonnaScriptTechs commented 7 years ago

From @gsf00001 on April 21, 2017 22:4

@SpiritWolfie I understand and can appreciate where you're coming from, especially due to you having so many open issues here at github.

Although there are multiple ways of dealing with updated software costs, the primary two extremes are:

  1. developer develops indefinitely at no charge
  2. developer charges constantly for everything

SE (and sad to say, most/all? of the 3rd-Party Devs) seems to only charge for upgrades at the major level. This is somewhat common practice in the industry, but I'll argue another day about why this is often unfair (to both Dev and client).

Although I'm not at #2 above, I am far far away from #1. I simply don't expect a software developer to work for free indefinitely - even if some issues/faults are on them. Many SE ADMINs seem to not pay for support from anyone - ever, yet expect the support fairies to somehow magically resolve issues. Many SE ADMINS squalk at a $20 Plugin (that would take dozens/hundreds of hours to develop), and then expect (for that 'huge' sum of $20) that the Dev provide free support and updates for years (which I can appreciate better when it's a closed-system; but SE PHP is not, so it's difficult to support something when then have control over only one 'original' piece of it).

I am simply of a different mindset. I'm looking for fair, honest, qualified partners - and want to do my part to keep them around (we need each other). I need people and businesses that produce a decent (albeit expectedly imperfect) product, in this case SE and Dev's Plugins. Do I pay SE for support? I did once, but since another Dev provides support for SE as well as their Plugins (and they are the primary source of most of my Plugins), I'd rather pay them - not because they're better (they may or may not be) but because it eliminates one group (SE in this case) from being involved and in potential any time-wasting finger-pointing.

I believe I treat my primary Devs (3 of them) very well (I have used Plugins from about 7-8 Devs, customizations from about 6 now, but primarily 3 that are more than 50 hours each - one is closer to 400 hours). I feel I have excellent relationships with each of them - I trust them and can count on them (it took me many months of research and then dealings with many Devs to whittle this list down, with much time and $$ spent in the process - which I no longer have to waste ever again now that I've found my core group of Devs). What's this worth to me? What's this peace of mind worth? Would I rather invest dozens/hundreds of hours attempting to fix something, or beat them up expecting them to do it 'now',... or would I rather say 'hey look, this is urgent - please fix'... 'hey, this is not urgent at all - take care of other client issues first'? The point is I have found (in 3 decades of business) that building a relationship (and usually paying for that) is the better way to go, even if I feel there are sometimes something should be provided at n/c (after all, I need it, and can either argue about it or be grateful I have experts willing to solve the problem at a reasonable cost - and then maybe use this as a learning example for both of us in the future).

I have actually asked SE via email if they would be wiling to either crowdfund certain features/functionality into Core, or accept paid customizations (although some Devs will modify Core I prefer to use whoever developed the piece of software). They haven't replied. Yes, yes - I can see where this could go, but this is also how some 3rd-Party Devs work. Some feature requests they will incorporate for all; some they will develop at a cost to you for you only; some times they will charge you a fee and still incorporate the feature into their Plugin. I'd rather pay SE a couple hundred bucks to get 5.0 here soon (if it incorporated the proper updates, etc.) than wait until they get around to it.

Soooo.... yes, I don't like to pay for 'old' technology or for when things don't seem to work. But I can either roll around in the mud and accomplish nothing, or I can often solve the problem by counting on solid, honest, quality relationships and pay for the work I need done. Who pays for what is part of most industries. Sometimes blame/fault can be determined and agreed upon by both parties to be the same thing; some times not.

I guess enough of my thinking out loud. It's simple - if I need something that isn't being provided at n/c to me, then I have to decide how badly I need it and then decide who I'm willing to pay to accomplish it for me. If I feel a company is being unfair (or whatever), then I may choose to continue working with them (complaining about it every step of the way, or hopefully accepting my decision), or simply move on to another company I feel I can develop a better relationship with. I believe it's often better to see if current relationships can be nurtured.

DonnaScriptTechs commented 7 years ago

From @Elshara on April 22, 2017 7:15

I hate to admit this here, but there's one thing you've said which really resonates with me. SE is a paid product, through and through. Would you treat a factory company the same way? SE is making factory products. They aren't your personal developers to make you custom stuff, even though we all wish we could all use as few products as possible to make something worth all our while. If I were a developer, and I had to make maintenance releases for years, based on a product I personally founded to help people, and over time, I didn't pay attention to the developments of technology, or actively hired a team to do so, then I would be dependent on myself to make things work. It's a win win for social engine to keep things stable, because they don't have to worry about the little things if the one they use to develop new stuff, is stable and it works. The problem is, there exists a chain of dependency happening here, and nobody is really finding the source of where the head of, or start and end of such a chain really is founded. Simple answer, it is located and regulated through points of connection. Where the point of connection is client to server. Everything else, is optional data. And this has to be kept in mind, as the server upgrades, so should the point of connection between the server, and the client. The client, being all your users online at any given time, doing things, to keep the information they post, available for both server and clients themselves. Respectively, all web software does, is change the type of connection to be able to alter the relationship of such communications, despite the fact they are bound to happen at some point, which is the goal after all, of any web software, open source, social engine, or otherwise. Maintaining the connection of such should be the top priority of any maintenance release, to upgrade dependencies, and have as few of them as possible, to keep the connection alive and strong within its depths. So if something is working, then strengthen and support it, but don't require it to have its own dependencies and integration with other things, unless they are supporting the connection of said relationship. That's honestly the way I see it. Social engine ought to improve here, as should other software.

On 21/04/2017, gsf00001 notifications@github.com wrote:

@SpiritWolfie I understand and can appreciate where you're coming from, especially due to you having so many open issues here at github.

Although there are multiple ways of dealing with updated software costs, the primary two extremes are:

  1. developer develops indefinitely at no charge
  2. developer charges constantly for everything

SE (and sad to say, most/all? of the 3rd-Party Devs) seems to only charge for upgrades at the major level. This is somewhat common practice in the industry, but I'll argue another day about why this is often unfair (to both Dev and client).

Although I'm not at #2 above, I am far far away from #1. I simply don't expect a software developer to work for free indefinitely - even if some issues/faults are on them. Many SE ADMINs seem to not pay for support from anyone - ever, yet expect the support fairies to somehow magically resolve issues. Many SE ADMINS squalk at a $20 Plugin (that would take dozens/hundreds of hours to develop), and then expect (for that 'huge' sum of $20) that the Dev provide free support and updates for years (which I can appreciate better when it's a closed-system; but SE PHP is not, so it's difficult to support something when then have control over only one 'original' piece of it).

I am simply of a different mindset. I'm looking for fair, honest, qualified partners - and want to do my part to keep them around (we need each other). I need people and businesses that produce a decent (albeit expectedly imperfect) product, in this case SE and Dev's Plugins. Do I pay SE for support? I did once, but since another Dev provides support for SE as well as their Plugins (and they are the primary source of most of my Plugins), I'd rather pay them - not because they're better (they may or may not be) but because it eliminates one group (SE in this case) from being involved and in potential any time-wasting finger-pointing.

I believe I treat my primary Devs (3 of them) very well (I have used Plugins from about 7-8 Devs, customizations from about 6 now, but primarily 3 that are more than 50 hours each - one is closer to 400 hours). I feel I have excellent relationships with each of them - I trust them and can count on them (it took me many months of research and then dealings with many Devs to whittle this list down, with much time and $$ spent in the process - which I no longer have to waste ever again now that I've found my core group of Devs). What's this worth to me? What's this peace of mind worth? Would I rather invest dozens/hundreds of hours attempting to fix something, or beat them up expecting them to do it 'now',... or would I rather say 'hey look, this is urgent - please fix'... 'hey, this is not urgent at all - take care of other client issues first'? The point is I have found (in 3 decades of business) that building a relationship (and usually paying for that) is the better way to go, even if I feel there are sometimes something should be provided at n/c (after all, I need it, and can either argue about it or be grateful I have experts willing to solve the problem at a reasonable cost - and then maybe use this as a learning example for both of us in the future).

I have actually asked SE via email if they would be wiling to either crowdfund certain features/functionality into Core, or accept paid customizations (although some Devs will modify Core I prefer to use whoever developed the piece of software). They haven't replied. Yes, yes - I can see where this could go, but this is also how some 3rd-Party Devs work. Some feature requests they will incorporate for all; some they will develop at a cost to you for you only; some times they will charge you a fee and still incorporate the feature into their Plugin. I'd rather pay SE a couple hundred bucks to get 5.0 here soon (if it incorporated the proper updates, etc.) than wait until they get around to it.

Soooo.... yes, I don't like to pay for 'old' technology or for when things don't seem to work. But I can either roll around in the mud and accomplish nothing, or I can often solve the problem by counting on solid, honest, quality relationships and pay for the work I need done. Who pays for what is part of most industries. Sometimes blame/fault can be determined and agreed upon by both parties to be the same thing; some times not.

I guess enough of my thinking out loud. It's simple - if I need something that isn't being provided at n/c to me, then I have to decide how badly I need it and then decide who I'm willing to pay to accomplish it for me. If I feel a company is being unfair (or whatever), then I may choose to continue working with them (complaining about it every step of the way, or hopefully accepting my decision), or simply move on to another company I feel I can develop a better relationship with. I believe it's often better to see if current relationships can be nurtured.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/SocialEngine/phpv4-issues/issues/665#issuecomment-296316158

DonnaScriptTechs commented 7 years ago

From @gsf00001 on April 22, 2017 17:53

==>"Would you treat a factory company the same way?"

Yes, I agree with you that SE should update many libraries and a bunch of other things to current (at the time it's done) standards. Yet in many ways, I typically do treat software developers differently than a physical product manufacturer (depending on the product), especially when it comes to realistic expectations (of functionality/bugs/costs/etc.).

My reasoning is that with certain products (especially some 'computers' and 'software' that allow integration and other 'stuff' to be 'connected' and 'controlled by others besides the manufacturer') it's much different than buying lets say a watch, because with a watch the the possibilities of introducing bugs/incompatibilities/etc. are not endless. Much of the computer world is much different than that of a physical product - and even some 'computer' products operability can't be controlled by the manufacturer.

The primary points I was simply trying to make:

  1. If I want/expect the latest/greatest to be incorporated into a product, I should be willing to pay for it, rather than complain about it. If I need it, but don't believe I should pay for it, I should either keep what I've got (without ongoing complaints), or move on to another product that I think is better (especially when I'm constantly reminding vendor1 how great vendor2's product is, when all I've done is play around with it a little or read feature lists). I want and expect SE to someday (soon please, please hopefully soon) do as you've mentioned and update to current standards (I don't need them to produce a new theme - I as many ADMINs have done, made a choice after trying almost a dozen paid themes to pick something else - and then still have it customized). I need them to better test their software and put out a more current, higher quality product. BUT I am also willing to chip in $$ to accomplish this.
  2. (not relatated to OP) Producing software (or obviously almost many products) is costly and (as I put in another post somewhere) for the most part (I feel/believe) SE and 3rd-Party Devs don't receive much revenue on their products to cover for forever development & forever support. Site-ADMINs (not just of SE software) often spend dozens of hours complaining about an issue, dozens or hundreds of hours trying to fix something, asking their supposed 'expert' friends/neighbours for help, but refuse to give the Developer $25/50 (or whatever) to resolve the issue. I guess some people have more time than me to waste in life. I feel we should simply do what it takes to get the issue resolved and then figure out who's paying for it later.

Thanks for your input @Elshara - much appreciated on this post and many others :)

DonnaScriptTechs commented 7 years ago

From @Elshara on April 25, 2017 6:48

Here's what I believe.

  1. Developers can't update if social engine doesn't if they develop plugins for existing functionality. Hence the reason why core updates must occur.
  2. Re: Factory companies. Every product social engine releases, I treat as a completely separate physical product. So if bugs and issues are recurring from product to product, I view them as separate, yet relevant issues. Not as a stream line of one issue, passed down from generation to generation as such.
  3. I agree with you about your logic where the core functionality is concerned. We as customers, have the right to our own wants and needs. But we have to work together, developer and customer clients, to make such known and work as one, not one above or below the other. I do think paid functionality ought to be considered as honorable contributions, not something required to get anywhere just because it's something which can be done again and again.
  4. If and where ever version 5 etc comes to pass, I do feel since it has been years since version 4 has come, we won't be required to pay for it. As we already paid for the base package. The contribution we make, provides us with the ability of lifetime updates, and as such, we pay for what we need in other ways during the update cycle which we are apart of. Inactivity, may be considered, as unpaid support, where I could understand a hesitancy. But for active contributors, I do feel we have options available to us, because we are so seriously invested in recent times. I hope it makes sense.
  5. I believe things will improve as such so only compatible third party products will work with current versions of social engine. As the new marketplace limits functionality to have customers get the best, tried and true, experience of any products sold there. This is not to say other developers can't or won't be able to sell on the side, but if enforcement of marketplace products happens where products only from the marketplace can be installed directly from approved sources, then we will see better support despite the fact unofficial plugins exist with probably assumed no support coverage. It would be nice to have social engine themselves support the product (s) they provide via their own marketplace however.
  6. I would really love the ability for third party product developers to be paid handsomely if they donate plugins they sell directly to social engine developers. It would give them incentive to make new designs so either customers or social engine could implement parts of or code packages themselves as addons to the core they already make available. I really appreciate your contributions as well and I always love hearing from you, two.

On 22/04/2017, gsf00001 notifications@github.com wrote:

==>"Would you treat a factory company the same way?"

Yes, I agree with you that SE should update many libraries and a bunch of other things to current (at the time it's done) standards. Yet in many ways, I typically do treat software developers differently than a physical product manufacturer (depending on the product), especially when it comes to realistic expectations (of functionality/bugs/costs/etc.).

My reasoning is that with certain products (especially some 'computers' and 'software' that allow integration and other 'stuff' to be 'connected' and 'controlled by others besides the manufacturer') it's much different than buying lets say a watch, because with a watch the the possibilities of introducing bugs/incompatibilities/etc. are not endless. Much of the computer world is much different than that of a physical product - and even some 'computer' products operability can't be controlled by the manufacturer.

The primary points I was simply trying to make:

  1. If I want/expect the latest/greatest to be incorporated into a product, I should be willing to pay for it, rather than complain about it. If I need it, but don't believe I should pay for it, I should either keep what I've got (without ongoing complaints), or move on to another product that I think is better (especially when I'm constantly reminding vendor1 how great vendor2's product is, when all I've done is play around with it a little or read feature lists). I want and expect SE to someday (soon please, please hopefully soon) do as you've mentioned and update to current standards (I don't need them to produce a new theme - I as many ADMINs have done, made a choice after trying almost a dozen paid themes to pick something else - and then still have it customized). I need them to better test their software and put out a more current, higher quality product. BUT I am also willing to chip in $$ to accomplish this.
  2. (not relatated to OP) Producing software (or obviously almost many products) is costly and (as I put in another post somewhere) for the most part (I feel/believe) SE and 3rd-Party Devs don't receive much revenue on their products to cover for forever development & forever support. Site-ADMINs (not just of SE software) often spend dozens of hours complaining about an issue, dozens or hundreds of hours trying to fix something, asking their supposed 'expert' friends/neighbours for help, but refuse to give the Developer $25/50 (or whatever) to resolve the issue. I guess some people have more time than me to waste in life. I feel we should simply do what it takes to get the issue resolved and then figure out who's paying for it later.

Thanks for your input @Elshara - much appreciated on this post and many others :)

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/SocialEngine/phpv4-issues/issues/665#issuecomment-296390250

DonnaScriptTechs commented 7 years ago

@Elshara - Thank you for your suggestion. We've added it to our list. @gsf00001 - great posts! You hit the nail on the head. Thank you!!

DonnaScriptTechs commented 7 years ago

From @Elshara on April 29, 2017 14:10

Love the expressions used here! Thanks and you're very welcome!

On 27/04/2017, DonnaB notifications@github.com wrote:

@Elshara - Thank you for your suggestion. We've added it to our list. @gsf00001 - great posts! You hit the nail on the head. Thank you!!

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/SocialEngine/phpv4-issues/issues/665#issuecomment-297670152