pepecyb@hub.hubzilla.hu

citc schrieb:

The personal dream is a server that shows no public domain content _before_ and _after_ sign-in;

So once again, you’re fixated on the pubstream feature. It’s an integral part of Hubzilla, and I don’t think you’ll be able to persuade the lead developers to remove it from the core just because it rubs you up the wrong way.

I still don’t understand why, given your aversion to Pubstream, you chose zotum.net of all places for your channel, where Pubstream isn’t just enabled but is also set as the landing page.

Quite a few Hubs haven’t enabled Pubstream, though… I just typed one at random from the list… e.g. hub.hubzilla.de.

That one behaves exactly as you’d like… Pubstream is off before, during and after registration/sign-in.

None of those now shown on the '...hubzillaserverdomain/pubsites' list.

If you don’t like any of the domain names (and I mean really none of them, as you say), then I suppose you’ve got no choice but to buy a domain you like yourself and run your own hub… without Pubstream, of course… 😉

I don’t know of any hub (what exactly is a ‘sensitive domain name’?) that sends out spam before, during or after registration or login.

It certainly doesn’t happen beforehand; it’s hardly possible whilst you’re doing it, unless you count the registration dialogues as spam… and afterwards, it’s up to each individual to decide whether spam ends up in their inbox. Hubzilla gives you all the tools you need for this, but you have to use them yourself.

Both Hubs updated…

You must enable SSE in the admin interface (Site ➔ Advanced ➔ Enable SSE Notifications) AND enable the SSE Notifications add-on as an admin.

citc schrieb:

How does someone install the 'solidified' theme please?

As a user, you can simply select it in the design settings. However, this is only possible if the Hub’s admin has installed it on the Hub using a simple shell command and has also enabled it with a single click in the admin interface.

👍

That’s quite provocative, @Jupiter Rowland  … 😉😄

But that’s the only way to get things moving.

Your demands are certainly justified, but they come up against reality.

The fact is: Redbasic will probably always remain the only theme included in Hubzilla’s core. Other themes are apparently not intended for the basic installation. And that makes it the only theme that is guaranteed to be available on absolutely every hub.

It follows that: Redbasic would need to be adapted to be screen-reader-compatible.

Problem: WHO is supposed to do that?

Solution (warning, I’m going to be a bit ‘provocative’ here): YOU! Get stuck in! Get to grips with the technical requirements, mechanisms and options for making pages screen-reader-compatible. Familiarise yourself with Hubzilla’s theme system and theme creation (no, there’s no suitable documentation… You’ll have to take a look at Redbasic and try to understand how it all works and what needs to be implemented… including the template engine, schemas, Bootstrap 5, etc.). Then rebuild Redbasic so that it works with screen readers whilst still fully supporting Hubzilla’s features. After that, try to convince the lead developers to incorporate the theme into the core.

I don’t know whether Solidified can be built to be screen-reader-compatible. However, Saiwal still has his hands full just getting the theme properly finished. His other themes should be easy to adapt accordingly if you come up with a solution for Redbasic.

There’s one thing I absolutely must set straight here, though!

…because they were written entirely by AI…

NO! His classic themes are themes adapted for Hubzilla – for example, one derived from https://adminlte.io/ – and are not AI-assisted, let alone created entirely by AI. Nor is Solidified created entirely by AI. AI is used in parts (which I understand, as the frameworks used require a lot of formalism and routine tasks).

So “written entirely by AI” is incorrect and casts the themes (especially the “classic” Utsukta themes) in a bad light.

@Harald Eilertsen @Lotfi

Could there be a problem with the hub (hub.volse.no)?

No, there are no problems on either hub (11.4.1 – 1265 with Redbasic). The File menu opens for both files and directories.

Take these:

remove_theme_repository
remove_theme

https://code.pepecyb.net/pepecyb/pepes-hubzilla-snippets

👍

1. Deactivate the theme in the admin interface
2. Delete the symbolic link to the theme directory in view/theme
3. Delete the theme directory in extend/theme

It would be interesting to know how the translation process works. Does the add-on have its own translation engine and carry out the translations on the Hub, or does it use a translation service? If so, which one? What data is transmitted?

Thanks for helping me unearth some forgotten memories.

Of course feeds work as a channel source… you just need to have added them as a channel beforehand. I’d completely forgotten that. I’ll add it to my KnowledgeDB straight away!

In order to add a feed as a contact, this option must have been enabled on the Hub by the admin. Otherwise, the option to connect to feeds will not be available.
As far as I am aware, it is unfortunately not possible to use feeds for channel sources.

Why should it be replaced?

Good idea to enable slow log for another series of tests. I’ll do that.

Performance differences when accessing new vs old files does not make much sense to me though

That’s exactly why I’m confused. The only thought I had was whether it might somehow be down to the number of entries in the directory. However, the two directories do differ in the number of entries. What they have in common is the rather large total size (MB). I’ve no idea at the moment.

Several tests (in which the hubs consistently froze) showed no significant differences in the number of times images were accessed.

Nor did the method of referencing in the source code (i.e. <HUB>/photos/<HASH_FILENAME> or <HUB>/cloud/<CHANNEL_NAME>/<REAL_FILENAME>) make any difference. New images from the two problematic subdirectories caused the system to freeze, whilst images from other directories did not. I’ve now simply stopped using those two directories for new uploads… but that's obviously just treating the symptoms.

In view of the points outlined here, Hubzilla has a huge advantage: it is modular.


Even though the use of AI-generated code in the core is not permitted, Hubzilla offers the option of creating appropriate accessibility aids using AI. Special themes and/or (in combination with) relevant add-ons would be suitable for this purpose, and their installation would then be the responsibility of the Hub administrator. Hubzilla makes this possible.

I’m going to give that a proper go today to see if I can spot any differences.
I’ll get back to you as soon as I have the results.

That also seems rather unlikely, although the thought had crossed my mind too.

Example:

I upload the image A.png (a completely new image) to the “Artikelbilder” folder and embed it in a post: after a short while, the hub freezes and displays the error message in the log.

After rebooting, I delete the post and the image.

Then I upload the image A.png again to a different directory and use it in a post: no error occurs.

I upload a completely new image, B.png, to a different directory and use it in a post: no error occurs.

I upload the image B.png to “Artikelbilder” and use it in a post: after a short while, the hub freezes and displays the error message in the log.

Reboot, delete…

I move the image B.png from the other directory to “Artikelbilder” and use it for a post: after a short while, the hub freezes and displays the error message in the log.

The only thing that might explain this is that the issue does not occur with older images already present in the critical directories.

That’s what I’d suspected at first, too. But what sort of ‘configuration error’ could be responsible for files from certain directories suddenly timing out when referenced? I pushed my hub even further tonight (until it crashed with the error message). And it’s reproducible: files newly added to certain directories cause the timeout error. Older files already present in precisely these directories do not cause the error, even when reused in a post. The files that caused the problem do not trigger the error if I upload them to new directories (including sub-, sub-sub-… directories) or to other sub-directories that have existed for a long time, and then use them in posts.

If this error were to occur generally, that assumption would make sense, but as it only happens in a few specific directories – and only with newly added files (which, by contrast, cause no problems in other directories) – I no longer necessarily assume it is down to a misconfiguration. I have currently identified the problem in two directories…

Pepes pic (41.6 MiB, 208 files, 1 subfolder)
Artikelbilder (39.0 MiB, 120 files, 10 subfolders)

The channel’s entire cloud: 233.1 MiB, 1,118 files, 92 subfolders.

It’s unlikely that the theme is to blame. Hubzilla stored the files correctly in `store/pepecyb/` – both the original and the resized versions, with the hash value as the filename – and their paths are correctly referenced in the database within the ‘attach’ table. I’d checked this before deleting them. And it doesn’t matter whether I upload the file via WebDAV or from the web interface. Certain directories cause the error. BTW: These are directories, some of which contain over 200 files… which is why I became suspicious.

I’ve also tried this with Solidified, Redbasic and Adminlte. And whenever I’ve uploaded to one of the rather ‘full’ directories, the file was visible in WebDAV and on the web interface and could also be displayed, but when embedded in a post, the Hub freezes with the error mentioned.

HestiaCP?