Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

etc
Developer
Registered: 2010-11-11
Posts: 3,427
Website

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
Admin
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 2,633

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: 1,759
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)

Offline

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

gaekwad
Admin
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 2,633

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: 8,842
Website

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: 3,427
Website

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
Admin
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 2,633

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: 3,427
Website

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

#49 2019-11-18 20:08:40

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,592
Website

Re: Dev news

etc wrote #320105:

Have I mentioned we have a global evaluate attribute in 4.8?

Another excellent addition! And a great use case that will allow @bici to put cbs_category_list to rest (as mentioned here).

Should we make global trim attribute act this way too? Currently it trims list items, but does not remove the empty ones.

I reckon that’s a good idea but admittedly I can’t think of any situations off the top of my head where that might not be a good idea.


TXP Builders – finely-crafted code, design and txp

Offline

#50 2019-11-18 20:17:40

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,592
Website

Re: Dev news

One more thing :-) I come up against where I wonder whether some trick might help is dealing with if_different and the first wrapping item.

Say you have something like:

<txp:if_first_article>
    <header>
        …
    </header>

    <section class="container">
        <div class="month hidden">
</txp:if_variable>
</txp:if_first_article>

<txp:if_different>
        </div>
        <div class="month">
            <txp:posted format="%B" wraptag="h3" class="month-title" />
</txp:if_different>

            <article>
                …
            </article>

<txp:if_last_article>
        </div>
    </section>
</txp:if_last_article>

to group articles into month containers and add the month name as a title.

If you use txp:if_first_article within txp:if_different it shows you the first and the second article as being different. So I often place the first opening div and the last closing div in the if_first/if_last but you end up with an empty div at the top (which I then hide with css). I know I can search and replace it out, but I can’t help thinking there’s a better way to avoid it.

I seem to remember that @els (?) had a complicated solution for this using a comment or variable or something, which I’ve forgotten how to do, but maybe you have something better in your arsenal of new attributes.


TXP Builders – finely-crafted code, design and txp

Offline

Board footer

Powered by FluxBB