I want to transfer shimmie from a Rasperry Pi to a new server. I am running Apache on both servers and I can install a new instance. How can I copy everything onto my new server?

I have multiple CSS files on my theme and I wanted them to be part of the cache system :) Is this good enough?

Found a bug here. I'll work on it tomorrow. It's pretty harmless tho, creates an empty table row when formatting a full width label.

This is the only thing that's not working with the SetupBlock changes. How should I access SetupTheme? Maybe UserConfigTheme should extend SetupTheme now? I feel like it should.

It seems flexible right until you don't want to use tables :smile: Also, I'm noticing extensions create their tables in very different ways, which explains why I had so much trouble getting everything to look consistent on my theme. There's even setupblocks that don't use tables at all and just populate the items in the div.

I know it's going to look a lot less flexible when I commit this. But giving extensions that much flexibility leads to inconsistencies... I'm also trying to send everything through this format_option function, which I now renamed to format_item and takes care of labels and text as well, and I created other functions in theme.php to wrap them in the table elements (the ones one would override to get rid of tables entirely)

We can discard it if you think it's too much anyway. I'm adapting all extensions to the revised format now, I'll probably commit after that.

This does look good :)

To deal with the formatting test:

./vendor/bin/php-cs-fixer fix

Thanks. I'll fix everything when I feel like it's ready for full review and merging.

oh, don't worry. I'll implement it accordingly. This PR is not meant to be merged yet as it is a bit less polished, because I'm working on multiple things at the same time. I wanted to make sure I wasn't making a big mistake and have to discard too much work. I'm working on setup's layout at the moment, which was a big pain when I tried to theme it.

That is nice. Will add this to my TODO list :)

main.php still uses a lot of small non-overridable functions to generate tables (I think we should avoid that) but at least this one can be overridden now.

Decided to go for a different branch for this, so we can easily discard it or merge onto the other one, since I'm still trying to find the workflow we should go for with this rework.

If we want to let themes completely replace layouts, like replacing this table with a flexbox or grid, we should externalize the TR, TH, TD wrappers found in extensions. This is just one example of them.

I decided to go for a custom class for parts of this ImageInfo block but this is not the only place where an object with header, body and order is needed, so I can see Parts becoming its own thing like Blocks but with just the bare minimum information. They would be useful for events that build blocks like this one. Maybe we end up using an array and not a dedicated class for this, idk.

The part building process is not definitive, it's just a quick prototype.

I wanted to use MicroHTML on ext/view/theme.php's build_info but the contents of the table still needed to allow for HTML to be injected. This may be improved as well.

There's a few TODOs here, mainly notes for myself. Also, sorry @shish, I know this is a lot of work and a lot to think about and review. I'm trying to maximize my contributions since this is my last free week before starting uni.

Same proof of concept from #827 but without my custom wrapper. build_selector has been moved to basethemelet.php. I didn't even think of it before. Putting this function here means that in addition to overriding on the entire site, themes can override them on a per-extension basis, giving even more control to the designer. Let's just hope we don't override the new functions on extensions themselves or we will end up in the same road :smile:

• The doc-string might be a bit too much, I just wanted to make it clear for this PR.
• There's an unrelated change that makes pools sort posts by ID when order is the same. It was a personal uncommitted change and it slipped on this one.

If this looks good, I will implement build_selector on more extensions.

FWIW I am happy to help and advise, both on shimmie and programming in general, and I am honoured that you would spend your time here :) Also for the record my day job varies between "overwhelming" and "nothing to do", hence my activity here being variable too ^^;;

Thanks! I felt very welcome here ever since I started studying the code and posted my first PR n.n Hopefully I can look back someday and see many more contributions because this project fascinates me.

Also to expand on the html-generation-library thing - I've started creating some wrappers in core/util.php to make sure that common concepts like "a submit button" are done the same way every time

That's a good one too. I wonder which elements should be done in that way and what's best to keep simple. In my experience, any helper function that returns HTML tags that are not closed is problematic. Example:

https://github.com/shish/shimmie2/blob/c4ae68fb471382db6350b82236cf0cc52a2cdf81/core/util.php#L703

This one generates a <form>, which is useful, but never closes it. Having such helpers for very specific things is ok but I can imagine too many of those "partial" HTML helpers would be confusing to work with.

I wonder if these functions should actually live in the base theme, so that custom themes can override them 🤔

I think so. Being able to override simple functions without having to rewrite a lot of code is always better for me, mainly because it makes themes more resistant to changes in the base code. But also because it makes creating themes faster in general. I found myself spending too much time adapting things that I wouldn't have touched otherwise rather than spend it designing my layout. (I guess I'm still doing that with this lol)

I do have a question, though: Would that approach (with the small helpers) replace the one I posted here? That is, would we still have a function that combines said helpers to create entire blocks in basepage.php or basethemelet.php like the build_selector example, or would extensions directly use helpers on their theme.php functions?

If we kept both, themes could use a mix of 3 options according to how specific the layout change needs to be:

1. Override the new generalized layout functions that affect all extensions.
2. Override those helpers to change specific HTML tags across all the site.
3. Override an extension's specific layout, like until now.

I like this approach more than having just the new functions or just the helpers.

Correct - only stuff in theme.php can be customised (ideally all HTML would be in themes, and main.php would only deal with pure data...

Right, so I will work on moving HTML to theme.php where necessary first, then we can more comfortably apply the new ideas. First offender I found: https://github.com/shish/shimmie2/blob/c4ae68fb471382db6350b82236cf0cc52a2cdf81/ext/setup/main.php#L236-L257

In any new code I write, I'm generally using an html-generation library (microhtml) rather than using raw strings

Yes I noticed those in the ImageInfo table already! IIRC it was another offender in terms of generating its HTML in main.php. Tbh I didn't have the time to get my head around microhtml yet but it would be a good idea to use that when possible then.