Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#37 2019-11-07 00:07:31

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 2,395
Website

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 ?

Offline

#38 2019-11-07 01:43:23

michaelkpate
Moderator
From: Avon Park, FL
Registered: 2004-02-24
Posts: 1,367
Website GitHub Mastodon

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

#39 2019-11-10 13:53:37

etc
Developer
Registered: 2010-11-11
Posts: 4,352
Website GitHub

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

#40 2019-11-10 13:57:46

gaekwad
Multi-hyphenate
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 3,559
GitHub

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

#41 2019-11-10 14:11:49

etc
Developer
Registered: 2010-11-11
Posts: 4,352
Website GitHub

Re: Dev news

gaekwad wrote #319996:

Presumably this needs PHP to have zip enabled…

Yes, it does. An alternative way is to ftp the unpacked bundle to plugins/abc_plugin/ directory and install from there.

Offline

#42 2019-11-10 15:16:01

gaekwad
Multi-hyphenate
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 3,559
GitHub

Re: Dev news

I’ve tweaked the system requirements doc.

Offline

#43 2019-11-12 08:51:51

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 2,395
Website

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 ?

Offline

#44 2019-11-12 09:07:12

gaekwad
Multi-hyphenate
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 3,559
GitHub

Re: Dev news

phiw13 wrote #320012:

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[.]

Perhaps a write access test in the Diagnostics -> Pre-flight Check would also be prudent.

Offline

#45 2019-11-12 10:19:21

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 10,396
Website GitHub

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

#46 2019-11-12 11:28:22

etc
Developer
Registered: 2010-11-11
Posts: 4,352
Website GitHub

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

#47 2019-11-12 19:24:44

gaekwad
Multi-hyphenate
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 3,559
GitHub

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

#48 2019-11-17 23:18:32

etc
Developer
Registered: 2010-11-11
Posts: 4,352
Website GitHub

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

Board footer

Powered by FluxBB