Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 Today 09:46:08

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,535
Bitbucket GitHub

Theme asset size limit increase in Textpattern 4.9

Recent changes to the dev branch of Textpattern have increased the size limit of text assets in a front-side theme.

From Textpattern 4.9.0, the size limit for pages, forms and styles is 16MB. In Textpattern 4.8 it’s 64KB, so this represents a significant bump up in permitted size.

On the GitHub issue where it was figured out (see #2021 for background), there was some discussion around whether themes are best suited to being more reliant on pages with less use of forms, or the opposite where the focus is on forms with a very minimal page scaffold.

What do you do? Mostly pages or mostly forms? Is there a balance? Have you changed your approach over your time with Textpattern?

Offline

#2 Today 16:06:34

giz
Plugin Author
From: New Zealand
Registered: 2004-07-26
Posts: 395
Website GitHub Twitter

Re: Theme asset size limit increase in Textpattern 4.9

As soon as I find myself repeating/duplicating code (which happens regularly when using multiple pages), I separate it out into a form.

I find long pages of code difficult to deal with; its simpler to manage multiple tabs…

Offline

#3 Today 16:08:40

Dragondz
Moderator
From: Algérie
Registered: 2005-06-12
Posts: 1,550
Website GitHub Twitter

Re: Theme asset size limit increase in Textpattern 4.9

Hi cool thing

Right now i change the page and form field manually to increase it s size thrue phpmyadmin for every new install because i use mainly page for coding and in some case page/form are huge (2000 lines or more).

Cheers

Offline

#4 Today 19:30:37

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 5,042
Website GitHub

Re: Theme asset size limit increase in Textpattern 4.9

Interesting to hear those contrasting approaches. I think I used to do more in the page template and use forms just for the article, listform and image display parts. Then, when container tags became a thing, I included more in the template and less in forms, especially for small code segments. At that time, I was usually working in the admin panels (with that expand-to-full-window editor plugin), so it was more productive to stay in one window than hop between several different panels.

When I started working from files (mostly after rah_flat came out) and could switch to using a code editor, I initially kept to the same pattern but I never warmed to those ‘fuzzy barcode’ minimap navigators for finding your way through huge files. Then I discovered espresso, which gave/gives you a kind of tree map of your file in the sidebar. If you segmented a huge css file with comment separators, it would show that in the sidebar and collapse that segment, making it easier to jump to the part of the long file you needed, or to the respective media-query, which at that time I also kept in separate blocks.

I think my switch to greater separation into multiple files came a) after seeing how some other people here structured their templates (Phil, Stef, Robert in particular) and finding them more readable than my convoluted templates, b) when I started to learn sass, and c) with the advent of project-wide search in code editors. That made finding things in your code across multiple files much easier. Now, and especially since the advent of shortcodes and breakforms, I structure a project similarly to what Gary describes, but sometimes I do struggle with the amount of open code editor tabs and use the split-screen facility of the code editor to group tabs into those related to css and those to txp. Css/Sass build tools / codekit have also made it possible to use media-queries directly in the selector you need them in, instead of in separate blocks, which also lends itself to breaking things down into files related to purpose. That is, I suppose, also a result of how I write css: if I were to use tailwind, my working method might be different.

It’s similar with the core php files. Initially I found the highly segregated object-oriented classes that gocom introduced really hard to follow: tiny chunks in individual files and in subfolder after subfolder, each referring to each other. I still don’t find it as easy to grasp at a glance, but GitHub’s code navigation tools have made it much easier to see relationships and how functions are used across a project of many files. In the past phpxref was a help but it wasn’t as intuitive. As much as I like the idea of codeberg, I miss that code-navigation functionality there (or maybe I’ve just not found it?), and that’s holding me back from using it.


TXP Builders – finely-crafted code, design and txp

Offline

#5 Today 19:45:15

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 5,042
Website GitHub

Re: Theme asset size limit increase in Textpattern 4.9

An aside: anyone remember asy_wondertag? It came back to me when trying to think what we did before container tags became more widespread.


TXP Builders – finely-crafted code, design and txp

Offline

Board footer

Powered by FluxBB