Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

maratnugmanov
Member
From: Russia / Kazakhstan
Registered: 2013-02-24
Posts: 54
Website

Re: UI needs rework badly

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)

Offline

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

Gocom
Developer Emeritus
From: Helsinki, Finland
Registered: 2006-07-14
Posts: 4,533
Website

Re: UI needs rework badly

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.

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 12,463
Website GitHub

Re: UI needs rework badly

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:

  1. open classTextile.php
  2. Find line 339+340
  3. 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)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Hire Txp Builders – finely-crafted code, design and Txp

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 12,463
Website GitHub

Re: UI needs rework badly

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)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Hire Txp Builders – finely-crafted code, design and Txp

Offline

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

Gocom
Developer Emeritus
From: Helsinki, Finland
Registered: 2006-07-14
Posts: 4,533
Website

Re: UI needs rework badly

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.

Offline

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

maratnugmanov
Member
From: Russia / Kazakhstan
Registered: 2013-02-24
Posts: 54
Website

Re: UI needs rework badly

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)

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 12,463
Website GitHub

Re: UI needs rework badly

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*


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Hire Txp Builders – finely-crafted code, design and Txp

Offline

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

maratnugmanov
Member
From: Russia / Kazakhstan
Registered: 2013-02-24
Posts: 54
Website

Re: UI needs rework badly

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 %)

Offline

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

els
Moderator
From: The Netherlands
Registered: 2004-06-06
Posts: 7,458

Re: UI needs rework badly

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.

Offline

#25 2013-02-25 19:24:59

maratnugmanov
Member
From: Russia / Kazakhstan
Registered: 2013-02-24
Posts: 54
Website

Re: UI needs rework badly

Els wrote:

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.

Wow, cool one. Can embed responsive youtube videos with only a _9wad9awe_-like key :)

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

Offline

#26 2013-02-25 19:53:11

bici
Member
From: vancouver
Registered: 2004-02-24
Posts: 2,259
Website Mastodon

Re: UI needs rework badly

Bloke wrote:


  1. Textpattern.org is an utter mess. I started work some years ago on fixing it with a new site and a new vision. Project just stalled for many reasons and it seems like I’m constantly apologising for its horribleness. I keep getting dragged in too many different directions to focus on it.

The plugins directory is a real mess for sure. When i first started using TxP i would try to find useful plugins therein but more often than not left without finding what i needed. I don’t know enough about them to know which to designate to the trash heap. but it does need major culling.

A related issue is that so many plugins are now being served from the the developers personal websites. This makes it very difficult to find what re avery useful plugins. There may be plenty of valid reasons for this decentralization of plugins, but it would be nice if there was a central registry of plugins.


…. texted postive

Offline

#27 2013-02-26 13:28:23

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,565
Website GitHub Mastodon

Re: UI needs rework badly

Bloke wrote:

Brilliant, thanks. Take a look at Phil’s site for the latest design patterns we’re using in 4.6.0 (he can supply you the best URL to use, I can’t keep up with the amount of work he’s doing!) and if you want to have a sneak peek at what’s going on for 4.6.0, grab a nightly.

The (in-progress) 4.6 design patterns can be found here

I can say that I won’t be in favour of a major UI redesign – we are taking iterative steps to improve the current UI gradually and as far as I’m concerned that’s the way it’s going to continue. There are flaws in the current workflow which we are well aware of but we have good ideas of how these can be fixed without drastically rebuilding the UI again.

That being said, feel free to suggest (and demonstrate) improvements where you see fit.

Offline

#28 2013-02-26 15:49:58

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,912
Website

Re: UI needs rework badly

philwareham wrote:

I can say that I won’t be in favour of a major UI redesign – we are taking iterative steps to improve the current UI gradually and as far as I’m concerned that’s the way it’s going to continue. There are flaws in the current workflow which we are well aware of but we have good ideas of how these can be fixed without drastically rebuilding the UI again.

Good. Major redesigns basically require a fork if you don’t want to piss or lose a lot of people. And if that were the case, you’d just want to reopen Xpattern. But count me in the crowd who does think some gradual changes need made, beginning with the workflow issues most understood already; including unlimited, modifiable custom fields (and the UI considerations around that). I’m really, really looking forward to those, and can imagine how powerful they will be with structuring content inside of body fields with smd_macros. :)

Offline

#29 2013-02-26 16:50:57

maratnugmanov
Member
From: Russia / Kazakhstan
Registered: 2013-02-24
Posts: 54
Website

Re: UI needs rework badly

I proposed tabs inside admin tab instead of rolling out lists – that’s no way can be called a major redesign.

Offline

#30 2013-02-26 17:50:47

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,565
Website GitHub Mastodon

Re: UI needs rework badly

Not going to happen, sorry. Tabs are a UX regression for a number of reasons:

  1. Tabs don’t work as a concept on small screen devices, especially since we can never guarantee of how many regions will be on the page anyway (plugins can add their own regions to the write screen, for example).
  2. By moving to a different tab, you are hiding a lot of UI away needlessly. By using slide out regions you keep all the UI in one place. I have a 24” monitor for example so why would I then want to hide huge regions of it inside another tab?
  3. Tabs are an accessibility nightmare for those with assistive technologies – you would have to use WAI-ARIA extensively on a screen reader to try and let those users what region they currently have active, and how they navigate back to another tab region. Here’s what you’d need to do to try to make tabs accessible

Offline

Board footer

Powered by FluxBB