Use of composer

As I´m reading in the community, composer is the future in Elgg, but i´m not sure if I must use it now and how.

I´ve Elgg 1.10 release, and for now I don´t develop plugins. I download plugins from the Elgg community and from Github and I´ve tried to use the composer:

In mod/plugin_dir I do:

curl -sS https://getcomposer.org/installer | php

and 

php composer.phar update

...and I see vendors are updated but, that's all I must do with composer in my installation???

 

  • I also have found plugins like https://github.com/hypeJunction/hypeWall/tree/4.0, and I realized the structure is different than standard plugins (for example start.php doesn´t contain the usual code...), these new plugins must be installed with composer??

  • You are clearly confused what exactly composer is and how it works. Start by reading composer's own documentation: https://getcomposer.org/doc/00-intro.md

  • Composer must be useful  if Devs are finding it so, but, imho, use of it loses the perspective of plenty of users like me (hobby and not-so-hobby users) who have been so long happily downloading zip or tar.gz, uploading, and creating websites.

    Creating and maintaining website itself takes away time for content and user generation. Thus if anything new happens in the backend  and if that is not known already, or intuitive or as easy as things have been in the recent past, people tends to stick with older versions and new adoptions are less and less (even more less in a world which depends more on fb even for having a new web presence instead of a new website)

    While reading the composer doc, things are not at all clear to me, for example

    "To install packages from sources instead of simple zip archives, you will need git, svn or hg depending on how the package is version-controlled. - for example what is svn or hg or all that? Why I need it? What is wrong with my "old" ways of doing things?

    "Installing Composer locally is a matter of just running the installer in your project directory:
    curl -sS https://getcomposer.org/installer | php"
    What the "heck"? I have been comfortable using ftp and running things from website interface, or using cpanel occasionally, and tweaking php code here and there for years and I do not follow all these jargon. If you say I must not be lazy and I must learn all these you may be right but I may just move away like many users are doing. I cannot explain enough all the problems unless you are in my shoes. The key question is "are you breaking my ease of use and my learning that has evolved over the years"? Answer is probably, Yes. There might be least botheration if users like me are lost as there may new users who will like this but believe me new users are getting rare and rarer these days. No more scripts like Drupal Wordpress or Elgg are being created in a wold dominated by fb and Apps and we may ostriches in our own sand-pockets, but the truth is that less kids are using these scripts as more and more of their time is already being consumed elsewhere.

    Do not forget the easiness and ease of php projects has been the cause of its enormous adoption. Surely a single voice like me will get drowned but many people who bother or care are not just using their voice at all. Userbase for projects like this is dwindling because of many causes and trying to be too modern or too upto-date will see more downfall ( in usage) in near future.

  • who have been so long happily downloading zip or tar.gz, uploading, and creating websites.

    You will continue to be able to do this. Even better, Composer provides the kind of foundation the could potentially let us let you install plugins straight from inside the Elgg admin area, instead of hunting around the community, downloading a zip, ftping to your server, unzipping, making sure the name and location are correct, etc. etc. blah blah blah. Too much effort before. Now we have a chance at streamlining that experience.

    You should just be able to point and click from a UI, right? Composer support potentially makes that possible for us to do straight from Elgg without the core team writing so much of our own code from scratch.

    Creating and maintaining website itself takes away time for content and user generation.

    Ironically, perhaps, this is exactly the reason we are giving first-class support to Composer in Elgg 2.0+ to begin with! Finding, downloading, manually installing and unzipping, testing, finding upgrades, upgrading, ugh. What a hassle -- Wordpress certainly has their UX right on this. Site admins basically do nothing and get upgrades automatically. Plugins and themes can be browsed and installed right from the admin area. Hard to beat that in terms of maintenance overhead! Composer gives us a shot at getting close to this because now we don't have to write all the code that does that behind the scenes. 

    what is svn or hg or all that? Why I need it? What is wrong with my "old" ways of doing things?

    https://en.wikipedia.org/wiki/Revision_control

    What the "heck"? I have been comfortable using ftp and running things from website interface, or using cpanel occasionally, and tweaking php code here and there for years and I do not follow all these jargon

    https://en.wikipedia.org/wiki/Command-line_interface

    If you say I must not be lazy and I must learn all these you may be right

    I can understand how you might be afraid of someone saying that, but let's just be clear that we're not saying that and haven't said that. The goal here is to make managing an Elgg site lower-maintenance for everyone, even if you don't want to or don't have time to learn how to wield the command line.

    I may just move away like many users are doing. I cannot explain enough all the problems unless you are in my shoes. The key question is "are you breaking my ease of use and my learning that has evolved over the years"? Answer is probably, Yes.

    We'd like to avoid breaking your ease of use! When we start releasing alphas, please do report bugs and get back to us with ideas of how to make the experience better.

    No more scripts like Drupal Wordpress or Elgg are being created in a wold dominated by fb and Apps...

    Actually to me it feels like there are more frameworks/scripts than ever. Laravel, for example, has risen to quite some popularity in a rather short period of time only recently. PHP ecosystem and community is healthier than ever, not dying. Don't freak out.

    trying to be too modern or too upto-date will see more downfall ( in usage) in near future.

    Modernizing for modernism's sake is of course a waste of time, but some of the reason modern things are modern is that they are objectively better than the legacy approach for various reasons.

  • So as I have understood, composer helps to install/update extra code (packages) needed in Elgg (or wherever) plugins. Composer simplifies plugin development, but I don´t understand this:

    Composer provides the kind of foundation the could potentially let us let you install plugins straight from inside the Elgg admin area.

    How??, transforming an Elgg plugin like a composer package??, it changes the actual plugin structure (like  https://github.com/hypeJunction/hypeWall/tree/4.0)??

    In the other hand, for me is not useful the "automatic" updating of plugins because 80% of 3rd party plugins I have installed has code customizations (not all customizations can be applied through helper plugins without complicate in excess the site structure

     

  • In the other hand, for me is not useful the "automatic" updating of plugins because 80% of 3rd party plugins I have installed has code customizations (not all customizations can be applied through helper plugins without complicate in excess the site structure).

    :(

  • not all customizations can be applied through helper plugins without complicate in excess the site structure

    I find it a very rare occurrence when can't do something through a helper plugin. 

  • @Evan @Matt, I´ve more than 60 3rd party plugins enabled and use 6 helper plugins to customize Core and 3rd party plugins, but some customizations like functions, actions or classes are not easy for me to modify through helper plugins, or is a small customization and not worth to ravel (and I have hundred of small customizations).

    Sure experienced Elgg developers can achieve an ideal structure where auto updating can be possible, but I think not for a lot of Elgg users like me.

    Anyway, any Elgg improvement is welcome whenever it helps and do not "disturb" old maintaining procedures we are accustomed to use.

     

     

  • I downloaded the social-signin plugin and installed by the normal method. unzip/upload/activate - nope that does not work. It does not have a vendor folder with autostart in it.  I am guessing that is something that composer creates.

    I moved away from elgg at version 1 and went to dolphiin and oxwall because I kept losing my sites because of backward incompatibility and I see now that 3.0 does not have an upgrade path. Is that so?

     

  • Where did you download it from? Unless the author has uploaded a dist package, you have to use composer to install the plugin, or run "composer install" from the plugin root after uploading it. Composer is really easy to learn and will save you a ton of time, especially when upgrading Elgg versions and all the plugins.

    Whatever "upgrade path" means. Major releases are major releases because they come with breaking changes. Most likely, you will not be able to plug and play any plugin without making changes to it. Elgg 3 overhauls the database schema, changes routing pricinciples and does a lot more things in a different, more efficient, more developer friendly way. We kept things backwards compatible, where we could, but it's not always possible where decisions made 10 years stay on the way of progress. Ultimately, noone is forcing you to upgrade, and Elgg 3 isn't even in beta yeat, I suppose Elgg 2 will be around for a while, you and others interested in keeping Elgg 2 alive longer can also contribute time to maintaining it.