UI needs rework badly

maratnugmanov · 2013-02-25 14:32:59

WordPress has another tradeoffs, but those tradeoffs are textpattern’s strong side – but that doesn’t mean that txp shouldn’t be more user-friendly, isn’t it? It doesn’t ought to, but it can be, if it will want (not sure about my strange language constructions here).
And the admin panel can be superb and still be simple.
And what about quotes? Where should I inject it? I’ve searched through classTextile.php – no thoughts.

GugUser · 2013-02-25 14:38:45

Recently I watched a movie in which the protagonist said (translated): “We imagine that happiness always is located where we not are.”

I think no CMS is complete. Which is a disadvantage to the one user, for the other can be an advantage. I like Textile and I don’t need any Wysiwyg editor. The results of Wysiwyg editors scare me. Textile is very simple to use and the results are clean.

Yes, we can make a long list of what is missing in a CMS. But, as well we can make a long list of the unique features in a CMS. I work with Textpattern, because it offers features that I can’t find in an other CMS. For a beginner, the special features of a CMS should be the reason to begin to work with a specific CMS.

Sometimes I miss in Textpattern other things than you, sub sections, for example. But, all in all Textpattern is a great tool for me and the developers are doing a great job. And there are so many great plugins! Take time to learn about all this.

It isn’t necessary that Textpattern will be the same as an other xy CMS. If you need the xy CMS, then you can work now with the xy CMS.

Bloke · 2013-02-25 14:46:08

Gocom wrote:

You wouldn’t be able access Textile’s internal methods from a callback.

I meant that we might introduce an (initially empty) class array of $symbols in our Textpattern_Textile_Parser implementation, which could expose that array to a regular callback_ref. After any plugins have meddled with the table, the method could continue, iterate over the table and call $this->setSymbol() for each one it finds.

If such a method was called in the constructor too, wouldn’t the symbols be “set” at instantiation time whenever the core needed to employ Textile? Maybe it’s not possible. I do need to clean my glasses / brain today so I probably missed something obvious — like some gaping logic chasm.

Whether we’d even want to consider doing something like this is something I’ve not thought through… we probably don’t want plugins to interfere with the core’s glyphs as it might cause untold catastrophes elsewhere!

maratnugmanov wrote:

And what about quotes? Where should I inject it?

In Textile 2.4.x you need to edit the define block around line 336ish in the code to set the txt_* entries to your liking. In 2.5+ you need to call setSymbol() exactly like Gocom’s code above.

Last edited by Bloke (2013-02-25 14:56:18)

maratnugmanov · 2013-02-25 14:57:43

I repeat – I don’t need WYSIWYG, I just need a fast and simple image insertion in the posts. Hope 4.6.x branch will introduce a slightly easier solution (even multiple files upload will do – i know – there’s a plugin for it for now, and i’ve installed it).

Bloke, I still won’t get it, my php knowledge edge is “open .php, search for some function, paste setSymbol() right next to it, save file, hope it will work”.
I’m running a local copy of txp 4.5.4 for testing purposes. Main site transfer will follow after I get used to textpattern environment. Help please? I will appreciate any help.

Last edited by maratnugmanov (2013-02-25 15:10:17)

Gocom · 2013-02-25 15:10:52

Bloke wrote:

I meant that we might introduce an (initially empty) class array of $symbols in our Textpattern_Textile_Parser implementation, which could expose that array to a regular callback_ref. After any plugins have meddled with the table, the method could continue, iterate over the table and call $this->setSymbol() for each one it finds.

If such a method was called in the constructor too, wouldn’t the symbols be “set” at instantiation time whenever the core needed to employ Textile? Maybe it’s not possible. I do need to clean my glasses / brain today so I probably missed something obvious — like some gaping logic chasm.

Those values would be set if there was a such callback explicitly reserved for that purpose. But it being a global overload, it would also mean the values are always set, even when you extend the class — unless you totally overwrite the constructor.

Bloke · 2013-02-25 15:12:18

maratnugmanov wrote:

“open .php, search for some function, paste setSymbol() right next to it, save file, hope it will work”.

! :-)

If you’re running 4.5.4 then you’ll have v2.4.1 of Textile. In that case, the hacky (not recommended any more) way is:

open classTextile.php
Find line 339+340
Replace them with:

@define('txt_quote_double_open',  '&#187');
@define('txt_quote_double_close', '&#171');

The less hacky (and preferred) way might be to do this in your config.php file — add the above two lines at the end of config.php and save it, then see what happens. In theory Textile will pick those up and use them instead of its own. This won’t work in Textile 2.5+ so it’s only an interim measure.

I don’t know which single quotes you use, but the procedure is similar; just replace or override txt_quote_single_open and txt_quote_single_close.

EDIT: I’ve had to remove the semicolons from the &#187 and &#171 above because the forum converted them into glyphs, grrrrrrr. You’ll need to remember to add a trailing semicolon to each one, immediately after the number itself.

Last edited by Bloke (2013-02-25 15:25:08)

Bloke · 2013-02-25 15:16:44

Gocom wrote:

it would also mean the values are always set, even when you extend the class — unless you totally overwrite the constructor.

Ah yeah. Damn you inheritence! :-p

Had my future-MLP-direction hat on and was wondering about a way to configure the plugin such that each language would have its content rendered in its own quote syntax.

I figured after I posted that extending the constructor is the better approach anyway as it allows me to fire up a different instance depending on admin-side language or currently-edited-article-language, and configure it accordingly. Ignore me.

Last edited by Bloke (2013-02-25 15:18:57)

Gocom · 2013-02-25 15:25:30

Bloke wrote:

The untested, but less hacky way might be to do this in your config.php file — add those two lines at the end of config.php and save it, then see what happens. In theory Textile will pick those up and use them instead of its own.

This. Place the lines Stef mentioned to your config file instead of editing classTextile.php. Always try to avoid modifying source files. Textpattern isn’t one of those systems where its acceptable practice, it’s more of so frowned upon. Using plugins and configuration options over mods is advised, because it keeps updating simple and so on.

Just keep in mind that those options are for Textile and not of Textpattern. The next version of Textile is revamped (modernized) and will no longer have those constants. The unsupported configuration overwrites you have in your config will stop working and will need different implementation.

maratnugmanov · 2013-02-25 15:28:05

Straight from my modified textile:

Russian quotes defined in «config.php»
Not without side effects though, for example: my monitor is 15» :D – I can live with it.

Last edited by maratnugmanov (2013-02-25 15:29:31)

Bloke · 2013-02-25 15:34:40

maratnugmanov wrote:

Not without side effects though, for example: my monitor is 15» :D

lol, not sure if there’s a neat way round that apart from encoding such entities directly in the article itself to use the regular quotes. *sigh*

maratnugmanov · 2013-02-25 15:46:25

In russian such constructions « » » (for ex. he said «Nickname» is a non-formal name») are allowable, so It will take a while for me to get things right %)

els · 2013-02-25 18:48:46

maratnugmanov wrote:

I just need a fast and simple image insertion in the posts.

Forget your wariness regarding plugins and have a look at smd_macro. I’ve used it a lot to simplify a variety of actions for clients.

Textpattern CMS

Textpattern CMS support forum

#13 2013-02-25 14:32:59

Re: UI needs rework badly

#14 2013-02-25 14:38:45

Re: UI needs rework badly

#15 2013-02-25 14:46:08

Re: UI needs rework badly

#16 2013-02-25 14:57:43

Re: UI needs rework badly

#17 2013-02-25 15:10:52

Re: UI needs rework badly

#18 2013-02-25 15:12:18

Re: UI needs rework badly

#19 2013-02-25 15:16:44

Re: UI needs rework badly

#20 2013-02-25 15:25:30

Re: UI needs rework badly

#21 2013-02-25 15:28:05

Re: UI needs rework badly

#22 2013-02-25 15:34:40

Re: UI needs rework badly

#23 2013-02-25 15:46:25

Re: UI needs rework badly

#24 2013-02-25 18:48:46

Re: UI needs rework badly

Board footer