All Site Activity
Jeroen Dalsem commented on the blog Elgg 6.0.0-beta.1 has been released- Jeroen Dalsem replied on the discussion topic Theme sandbox : Long textarea input without a visual editor activated by default
iionly released a new version of the plugin [Elgg 1.5-1.12 & 2.X - 5.X: Tidypics]
Nikolai Shcherbin released a new version of the plugin IndieWeb- Nikolai Shcherbin released a new version of the plugin IndieWeb
- iionly commented on the blog Elgg 6.0.0-beta.1 has been released
Hermand Pessek replied on the discussion topic Theme sandbox : Long textarea input without a visual editor activated by default- Nikolai Shcherbin released a new version of the plugin IndieWeb
- Nikolai Shcherbin commented on the blog Elgg 6.0.0-beta.1 has been released
- Jeroen Dalsem published a blog post Elgg 6.0.0-beta.1 has been released
Great! Thanks for your efforts!
Am I happy about the upcoming Elgg 6?
Yes. Great to see it going forward.
Am I happy about the upcoming Elgg 6?
No. Sorry, not at all. I don't know who is supposed to be able to keep up development pace requiring some 100 hours per year not to implement any new functionality into plugins but just keep them compatible with the new yearly major release. I don't get paid for this work. I don't want to get paid anyway. But it's simply an impossible task trying to do that work in the evenings or on weekends "just for fun". I don't know if it makes any sense anymore with these yearly BC breaks. New features? Fine!!! But it just doesn't work this way.
@iionly as core developers we always have to balance the need for features and the ease of upgrading plugins. You are not required to update your plugins every major release. Breaking is needed for progress, but we do our best to keep the impact for plugin developers as little as possible. If we break we also give pointers in the upgrade notes about how to changes/update your code. As we have a lot of plugins ourselves we personally also benefit from as little work as possible. Our experience is that with every release of Elgg plugin development gets easier and requires less work updating them.
- Jeroen Dalsem replied on the discussion topic Theme sandbox : Long textarea input without a visual editor activated by default
- Hermand Pessek added a new discussion topic Theme sandbox : Long textarea input without a visual editor activated by default in the group Beginning Developers
hmmm this might be a remnant from a time where there was a toggle to show/hide the editor. This is no longer a feature, so this might not be possible anymore.
What would be the usecase for being able to 'later' toggle an editor?
Hi,
Thanks a lot for your answer.
A toggle to show/hide the editor was I unbelievable feature from my point of view, especially for modern special media platform.
Nowadays, almost all the web social media offers such functionality because in most cases, users just need a "textarea" when they want to comment on articles or wall. However, they also need to be able to switch (toggle) from "textarea" to modern editor based on their need. That's why I think the feature was really useful.
I will need some guidance if possible to re-implement the toggle to show/hide the editor
Regards,
I had a look at the code. I was correct. The 'visual' toggle was removed when we switched to CKeditor 5 (when we released Elgg 5).
If you want ckeditor to not initialize when using a longtext input field you can pass 'editor' => false to the view, but currently there is no way for the user to activate the editor afterwards. If you do not want a editor at all you can use the plaintext input field.
We do not think the usecase is strong enough to have this kind of feature present in Elgg by default. You are free to develop such a feature yourself of course. For inspiration have a look at this: https://ckeditor.com/docs/ckeditor5/latest/features/restricted-editing.html#demo
Ronald replied on the discussion topic Getting cronjobs to work
Jerome Bakker replied on the discussion topic Getting cronjobs to work- Ronald replied on the discussion topic Getting cronjobs to work
- Nikolai Shcherbin replied on the discussion topic Getting cronjobs to work
- Jerome Bakker replied on the discussion topic Getting cronjobs to work
Thanks for your responses.
I still don't get it to work...
I found that I can get a PHP-file activated at
/bin/sh: /home/<USERNAME>/domains/elgg.<OURDOMAIN>.nl/public_html/elgg/<MYPHPSCRIPT>.php
I had to set permissions for that file, to refrain from getting 'Permission denied'However, when I put
/bin/sh: /home/<USERNAME>/domains/elgg.<OURDOMAIN>.nl/public_html/elgg/cron/minute/
or
/bin/sh: /home/<USERNAME>/domains/elgg.<OURDOMAIN>.nl/public_html/elgg/cron/minute
in a cron job, I get 'No such file or directory'.Do I have to set specific rights to a certain file? Do I have to run anything? There is no file nor directory 'cron' in my elgg-directory.
The server I currently use is not yet available on the internet without redirecting in my hosts-file, but that should not prevent it from working with its own cron jobs, should it?
Thanks for (more) help...
Ronald
However, when I put
/bin/sh: /home/<USERNAME>/domains/elgg.<OURDOMAIN>.nl/public_html/elgg/cron/minute/
or
/bin/sh: /home/<USERNAME>/domains/elgg.<OURDOMAIN>.nl/public_html/elgg/cron/minute
in a cron job, I get 'No such file or directory'.You need to do a wget https://elgg.mydomain.nl/elgg/cron/minute
This is not the same as executing a .php file. Please read the documentation carefully. Or read Nikolai's comment again that does the same as the documentation.
Thanks, Jerome Bakker.
The cron job now gets activated every minute.
However, the output (send in mail, while testing) says 'Scheme missing'. It does not seem to handle the expected function(s). Do you have any clue where I should look to solve this?
Ronald
- Ronald joined the group Elgg Technical Support
- Jeroen Dalsem replied on the discussion topic Users change theme