Sent you PM

Have you looked at https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors

The main reason is the external site (jit.si) doesn't allow the inclusion. No idea why it worked in Elgg 5 and not 6. Maybe the ESM modules (because they are browser native) are more secure than RequireJS was.

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

@Nikolai

That wouldn't work as the session (and session manager) only apply to the logged in user. There is no way that those services can touch other sessions (luckily).

@Hermand

What is your goal? If you wish to perform some maintenance to the server and don't want to have any users only. Simply enable Maintenance mode from the admin side.

With a bit of programming you can truncate the users_sessions table and therefor nobody will be logged in anymore (maybe also truncate the users_remember_me_cookies table to not automatically let users log back in who have Remember me enabled)

@Jerome  I assumed this

@jeabakker and @rivervanrain thanks a a lot I will simply enable Maintenance mode from the admin side.

With Elgg you can do anything (almost). The only question is that there're no existing plugins. So, you'll either have to develop it yourself or hire developers.

If you're using Apache as the webserver make sure the .htaccess is present in the root of your website. Alsa make sure that a .htaccess may be used in your website configuration of Apache (search on Google how to check this).

If you're using nginx as your webserver make sure your have the contents of 'install/config/nginx.dist' in your website configuration.

I try to the link test. So I received ‘success’. But I don’t go forward. 

You should (on the installation page, not the test page) be able to go to the next step.

In Elgg 2.3 the livesearch (used by the userpicker) was more or less an elgg_get_entities() query. In Elgg 3.3 the livesearch was changed to use elgg_search().

elgg_search has more hooks and thus other plugins could change how it works. If you don't have any plugins that change the search behavior than it still is an elgg_get_entities() query, but because of changes to the database the query can be more complex.

The size of the metadata table has an impact on the performance of the search queries.

If you enable DEBUG logging you can get the SQL query related to your userpicker query, you could than try to find out if the problem is the database or the webserver. If the database takes up most of the response time than you could look into whats wrong there.

Please note, both Elgg 2.x and 3.x are end-of-life ;)

Thank you Jerome for the explanation.

That makes sense. I have several plugins that have their own search and they might change the search behavior as you mentioned.

Also, thanks for the trick on debugging SQL query.

I know that I am 2-3 versions behind :)