Juho Jaakkola

About me: Elgg core team member, Web developer at Mediamaisteri Oy
Location:

Activity

  • Juho Jaakkola commented on the plugin Notifier
    Please tell what exactly is broken and how. Attach also possible error logs. Otherwise I cannot help you.
  • Juho Jaakkola commented on the plugin PDF export
    I don't know. Can you? ;) There are no technical reasons why the user profile page couldn't be exported to PDF.
  • Juho Jaakkola replied on the discussion topic adserver
    Are you serious? No-one in their right mind would actually help anyone find ways to spam Elgg sites. Quite the contrary. :) view reply
  • Juho Jaakkola replied on the discussion topic How to upgrade Elgg using composer?
    Further reading: https://ilikekillnerds.com/2014/09/should-you-commit-composer-lock-into-your-git-repository/ https://blog.engineyard.com/2014/composer-its-all-about-the-lock-file See also the starter project of the elgg.org site... view reply
  • Juho Jaakkola replied on the discussion topic How to upgrade Elgg using composer?
    After running "composer update" in a development environment: Commit both composer.json and composer.lock to git Go to your production environment, pull the changes from git Run "composer install" to install the updated... view reply
  • Juho Jaakkola replied on the discussion topic How to upgrade Elgg using composer?
    You can update single package (plugin, library, elgg core) with: composer update foo/bar Or you can update all packages with: composer update The version constraints in composer.json define how much newer version the command is... view reply
  • Juho Jaakkola replied on the discussion topic Help troubleshooting composer upgrade
    The 'Elgg\Composer\Event' class has been replaced by 'Elgg\Composer\PackageEvent': https://github.com/Elgg/Elgg/commit/be4235a0a75d6bbb8f95f823dd5eff52ed27c2d6 The problem is that the post update hook is trying to use a... view reply
  • I think I would implement this by creating a relationship between the user and the piece of content: add_entity_relationship ($user_guid, 'has_read', $content_guid) This way I could always get the latest data. Consider... view reply
  • Juho Jaakkola replied on the discussion topic New upgrading feature for Elgg 3
    @iionly you have also been maintaining a lot of plugins. Any feedback about the interface? view reply
  • Juho Jaakkola replied on the discussion topic New upgrading feature for Elgg 3
    Yes, I've already been planning something like that. It can however be implemented later. Currently I just need feedback about the general structure of the plugin-facing Elgg\Upgrade\Batch interface. Do you as a plugin dev find it easy... view reply
  • Juho Jaakkola added a new discussion topic New upgrading feature for Elgg 3 in the group Feedback and Planning
    I'm working on a new object interface that allows plugin developers to easily write long-running upgrades that have a nice admin UI. Each upgrade will display: Total number of items Progress bar Estimated duration Number of...
    • @iionly you have also been maintaining a lot of plugins. Any feedback about the interface?

    • I think the interface looks good. It allows to display a description text and the progress getting displayed is surely helpful for long running upgrades.

      Maybe in addition to the counting of successes and errors and the registering of error messages it could be very useful to add some methods to allow for creation of a log file in the data directory (<dataDirectory>/UpgradeLogs/<UpgradeClass>/run_YYYYMMDD_timestamp.log). Error messages are rather a short-term help only and might not be of much use if there are too many errors happening. A log file could be useful if something goes wrong for whatever reason and some rescue action is necessary. Matt made a contribution to Tidypics that adds a clean-up routine to find image entries without image files and this routine logs the results in such a logfile.

      Is there a mechanism to stop the batch loop if some condition occurs and to marks the upgrade as not finished? For example, an update would come across a file in the data directory it needs to move but can't due to file permissions. Would it really make sense in such a case to continue (maybe with coming across the same problem again) and then maybe even mark the upgrade as finished successfully or wouldn't it make more sense to stop the execution immediately, still display this upgrade as pending and output an error message to the admin of what to do to fix the problem?

      I like it that you can define dependencies between upgrades. I had the problem in Tidypics on the upgrade to Elgg 1.9 that I had to warn people to first run the pending core upgrades before running the Tidypics-upgrades but I had no way of simply preventing the execution in the wrong order.

      Is it possible to use the new upgrade feature also for non-batch upgrades to have a unified upgrade mechanism for everything? I guess you could always implement a run() method even if it doesn't use an ElggBatch. But it might not make sense to display a progress bar (maybe only for a fraction of a second) if an upgrade will not take long.

      How is the upgrade level of a plugin managed? If I'm not mistaken the time of sucessful execution of each individual upgrade is saved in the database. But how can you convert existing upgrade scripts into a class and let Elgg know if they need to be run or not? For example Tidypics handles the upgrade level using a "version" plugin setting that gets updated after an upgrade script has finished. So, the "Upgrade" button is only displayed if there are newer upgrade scripts in a new version of Tidypics that need to be run. If the existing scripts would be converted to classes, a pending upgrade for each of them would be displayed if there's no plugin-central upgrade level control.

    • It's clear and looks easy to implement, I like it

  • Juho Jaakkola replied on the discussion topic Kill the friendspicker?

Group membership