Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
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
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
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
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
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
Re: Theme asset size limit increase in Textpattern 4.9
As giz says, any time there’s duplication or repetition, that’s my trigger to use a form or a shortcode.
Like Jools, I used to have fairly big Pages, with Forms used just for items in lists. Nowadays, I’ve slimmed my Page templates down, and most are used merely as HTML scaffolding, with common blocks in ‘Section’ Forms:
head(for everything in the<head></head>)navigationpage_headpage_footaside
The remainder of the page will be made up of article lists/individual article tags and stuff to handle landing pages.
Most sites I do nowadays have two Page templates:
frontpagea.k.adefault– because it usually handles a lot of different elements that aren’t the same as every other page. Search results. Category/Author lists, hero/smd_featured articles, etc.regular– for all remaining list/individual article pages.
Performance hasn’t been an issue, so I’ve kind of settled on this approach. Also, thanks to a trick someone in here mentioned recently, I don’t even need to faff with canonical tags or special handling for sections that contain only a single article, like /about-us and /contact. For those sections, I set the permlink mode to just /title so it sidesteps all the tomfoolery. Result!
Other Forms come and go as needed. Shortcodes for repeated things like email and phone and address, which render relevant anchors with optional <txp:yield /> goodness. I create other Forms in dedicated groups for ?f= processing or special pages like uploads/importing or interfaces for spitting out query results.
The downside to these Forms is that I’ve been burned at least twice by accidentally checking the ‘remove unused pages/forms’ when exporting a theme. Then all my beautiful hand-crafted ?f= forms etc instantly go bye-bye. Luckily to date, I’ve had database backups or I’ve developed them on disk in a separate folder/repo and been able to restore them, but it’s damned annoying, because they are “in use”; they’re just not referenced directly so Txp thinks they’re outdated and zaps them.
As for CSS, I’ve yet to adopt BEM. It just hasn’t ‘clicked’ for me yet and I don’t use SASS/SCSS because it generates code that I can’t debug six months later. I tend to hack CSS inline in the web inspector and then just paste the changes directly into the CSS editor on the Txp back-end, as that’s the fastest workflow for luddite me. And I still keep my CSS file in media query blocks because that’s how my brain understands and logically parses it:
Here’s the baseline rules for reset/mobile devices…
now if they rotate their device we change things a bit…
and if they have a bigger device, this moves here, that moves there…
and if they’re on a desktop, they get stuff side-by-side…
and if they’re on a multi-screen mega rig, everything’s clamped to a max width to avoid spillage.
I find that makes isolating bugs at and around breakpoints/device min-widths easier to deal with, as I immediately know which area of the CSS to target.
This has probably wandered way off-topic so I’ll shut up now.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline