Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Dev news
michaelkpate wrote #319975:
I have 4.8.0-dev installed on CMS Styles
[…]
Am I missing something obvious?
That is the same error as I had “in this post above”. See Oleg’s answer in a subsequent post (with a workaround/ solution further down).
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Dev news
phiw13 wrote #319976:
That is the same error as I had “in this post above”. See Oleg’s answer in a subsequent post (with a workaround/ solution further down).
It fixed me for me as well. I read your post the other day but forgot about it tonight.
Thanks.
Offline
Re: Dev news
Some good news for plugins: you don’t have to look for a compressed version any-more to install a plugin. Just upload a abc_plugin.php file and it’s done! Moreover, multi-component plugins can be distributed and uploaded as zip archives now.
Offline
Re: Dev news
etc wrote #319995:
Moreover, multi-component plugins can be distributed and uploaded as zip archives now.
Oleg, first of all – amazing news, thank you! Secondly, does this affect the system requirements? Presumably this needs PHP to have zip enabled…
Offline
Offline
Re: Dev news
I’ve tweaked the system requirements doc.
Offline
Re: Dev news
etc wrote #319995:
Some good news for plugins: you don’t have to look for a compressed version any-more to install a plugin. […]
That is great news and will simplify updating plugins! You may want to mention in the documentation (and upgrade notes, probably) that the textpattern/plugins folder needs read/write access otherwise bad things will happen (including your favourite sports team loosing the local village championship)
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Dev news
phiw13 wrote #320012:
You may want to mention in the documentation (and upgrade notes, probably) that the
textpattern/pluginsfolder needs read/write access otherwise bad things will happen[.]
Perhaps a write access test in the Diagnostics -> Pre-flight Check would also be prudent.
Offline
Re: Dev news
gaekwad wrote #320014:
Perhaps a write access test in the Diagnostics -> Pre-flight Check would also be prudent.
Yes. The dust is still settling on this feature and, as it stands right now, presents possible problems to those using multi-site installations. Think what would happen if all sites shared a single Txp installation and you upgrade or delete a plugin on Site A… it gets updated/removed in the central repo and Site B is affected.
Yes, if you upgrade Txp, all sites are affected anyway and you may not want that, which is why I know people who run multiple Txp versions and symlink clients to the latest version on a case-by-case basis once they’ve paid the upgrade fee and/or it’s been tested on their site. This setup still reaps multi-site benefits, but within a more controlled environment.
Plugins though, I don’t know. Having an individual plugin repo for each site is fine but if you do want to upgrade across the board, it’s a pain to visit them all and update them one by one. But updating a single plugin that is arguably “local” to a site – even though it’s stored in a globally accessible location to all sites – might have detrimental effects to the other sites.
Still mulling this over and wondering if multi-sites should have their own plugin stores. In which case, we should merge the plugin_cache_dir functionality now so there’s a pref to the “Plugin directory” instead of hard-coding it like we do now. That permits site admins to choose whether plugins share a repo or whether to break out some sites to use their own plugin stores.
At that point, yes, we should add a check to Diagnostics to verify that the directory is write accessible. Any thoughts on this plugin feature and how we should handle things with regards upgrading plugins and the ramifications of how it affects other sites, btw, please share them.
Last edited by Bloke (2019-11-12 10:19:53)
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
Re: Dev news
The situation can be complicated even in single-site setups. Recall that we have themes that can be used simultaneously (one per section). Themes contain tags. Tags can be these of core, but also plugins ones.
Suppose now that Theme A requires a plugin version incompatible with this of Theme B. How do we manage it?
Offline
Re: Dev news
Bloke wrote #320016:
Think what would happen if all sites shared a single Txp installation and you upgrade or delete a plugin on Site A… it gets updated/removed in the central repo and Site B is affected.
I would hope (perhaps I’m being optimistic) that someone with enough scope to figure out multi-site has the smarts and visibility to factor that stuff in. I toyed with multi-site a while ago, couldn’t get it to work and I’ve never properly embraced it…I’m probably less likely to now, especially with the ease that a new Textpattern can be spun up and themed.
I know people who run multiple Txp versions and symlink clients to the latest version on a case-by-case basis once they’ve paid the upgrade fee and/or it’s been tested on their site.
That’s genius. Never would’ve thought of that, how clever!
Offline
Re: Dev news
Have I mentioned we have a global evaluate attribute in 4.8? It’s more than just a shortcut for <txp:evaluate /> tag. Consider the following block, outputting a category list with articles count:
<txp:category_list children="1" wraptag="ul" break="li">
<txp:evaluate test="article_custom">
<txp:category title link /> (<txp:article_custom category pgonly pageby="1" escape="trim, integer" />)
</txp:evaluate>
</txp:category_list>Categories that have no articles will not be output (escape="trim, integer" makes 0 values fail the test). But break="li" will still apply, even to empty blocks, so we might get something like
<ul>
<li>Animals (5)</li>
<li></li>
...
</ul>With evaluate attribute the problem is solved:
<txp:category_list children="1" evaluate="article_custom" wraptag="ul" break="li">
<txp:category title link /> (<txp:article_custom category pgonly pageby="1" escape="trim, integer" />)
</txp:category_list>will remove empty blocks from the output.
Should we make global trim attribute act this way too? Currently it trims list items, but does not remove the empty ones.
Offline