netcarver

Sorry, I don't use either Hani, but if you don't get any help here then I've often found IRC channels to be quite a good way of getting help. There are some channels for these topics on irc.freenode.net and #gnupg looks like the best bet judging by the names. You can join the channel via webchat in your browser too. Hope that helps.

Fulltext stopwords might have something to do with it too -- but I've never used fulltext indexes so I'm not very familiar with them at the moment.

Just a quick update. I've now pushed a preview of the changed code to a new 'nr' (next-release) branch. Feel free to post comments, suggestions or questions here or raise issues over on the repo itself. I've actually started documenting the methods too -- something that will be ongoing over the next few point releases.

@Mathew Thank you for the report, I appreciate it! Actually, TextileRestricted() intentionally does not convert these structures to lists. It's restrictive as it's meant to be used for things like public facing inputs like comments which can easily be abused. As you've found out already, you need to use the normal unrestricted textile if you want lists rendered properly. As a slight aside for a moment: You mentioned using... *Publications* * Publication 1 * Publication 2 ...as the input but this version of textile requires a newline between what you are using as a heading and the first item in the list, like this... *Publications* * Publication 1 * Publication 2 Ok, back to the main thrust. If this isn't a public facing application and you need to have users input lists then you could consider switching over to the un-restricted formatter. If you do need restricted mode (untrusted users) plus lists then please raise an issue over on the repo and I'll see what I can do. I'm not particularly happy with this split between functionality between the two textile methods at present although it seems to have done what most people need until now. I have been thinking of adding a more general and flexible parse method to which you can specify exactly what structures should be allowed, but that's just a thought at the moment. Thank you for your interest in textile.

Adam, this looks fantastic!

@soma, I've seen that error once before on a live PW site too.

Ryan, best wishes for a healthy pregnancy and delivery to you & your wife (ok, mainly to her) but congratulations to you both.

Hi Adam, thanks for the feedback. Feel free to open an issue on the netcarver/textile repo for any feature requests or ideas you have. Going beyond v2.5 I'm considering adding a plugin system to textile, called "textplugs", and having a textplug specifically for MD compatibility but I don't want to make MD compatibility part of the textile core.

I'd like to hear Ryan on FLOSS weekly (not a dental product.) That would be some great exposure for PW, especially now it's just won the best free cms award too.

Hello folks, The next release of textile (v2.5) is going to see some major changes to the codebase and a few minor additions to its abilities to handle text. The changes outlined here are not yet committed to the dev branch of netcaver/textile but (Now committed) I want to post about this in advance so any developers here can get a feel for what will be changing and see if it impacts them (to track what is already committed to the dev branch for v2.5 you check the changelog.) As I'll be taking over responsibility for maintaining the textile text formatters with this release, I'll also take care of making sure these code changes don't impact end users of the textile in PW. However: if there any devs reading this who use textile in other work they might be interested in the rest of this. To facilitate textile’s uptake in other projects & to make it plain easier to read, I'm moving the code towards PSR-2 compatibility. Although I don't necessarily agree with everything in the PSR-2 standard, I will be adopting it for textile because... textile has used no coding standard to date and has had many contributors who have all used different styles & consequently the coding style (or lack of it) reflects this and needs some sanity restored to it. It gives people who may contribute to textile a standard to work to. I have been advised that a minimum of PSR-1 compatibility is required for textile's uptake in at least one other CMS. So how might these changes bite your installation? Here's a few ways... First potential problem: Are you overriding textile's defines to customize something? As PSR-1 (needed for PSR-2) doesn't particularly like code declarations & side effects (such as the #defines that pepper textile) in the same file, I need to know what use, if any, folks are making of the existing txt_ defines listed here as they will be going. If you are using them, you will need to start calling a new method setSymbol('name', 'value') prior to calling TextileThis() or TextileRestricted() and drop the defines as textile will no longer be using them at all. NB. the 'name' to pass into setSymbol() is as shown in the link above without the leading 'txt_' which is no longer needed as the names will no longer be in global scope. If you are using textile in exactly its default configuration with respect to defines there is nothing to worry about so far. Next: Using a define called 'hu' to make all relative image paths absolute. This is only likely to impact the use of textile in Textpattern CMS (it's original parent project.) Textpattern CMS uses a define called 'hu' to point to its root path and if textile finds a define called hu it uses that to prefix all root-relative image paths turning them into absolute paths. Now that textile is breaking free from its Textpattern CMS heritage, I think it's time to break this hidden coupling between the two and instead replace it with a generic (and explicit) setRelativeImagePrefix() method, allowing other projects to use relative image path prefixing if they need to without resorting to using the 'hu' define and without the possibility of a name conflict if they already happen to be using a define called 'hu' for something else. If your project doesn't use any define called 'hu' the above won't be a problem for you. Finally: Still using PHP4? I thought not, but I have to cover this anyway. Next up is PSR-2's requirement for explicit visibility on all properties and methods. As textile comes from a PHP4 heritage it has never had these. A quick look at my stats for PHP versions across hosts show that ~79% of hosts run PHP of some kind and that ~76% are PHP5 or better. Needless to say, PHP4 support is going. But even if you are running PHP5+ this change to the textile codebase will bite you if... you are calling any methods other than the constructor method, TextileThis() and TextileRestricted(). you are accessing any of the class properties. These will all become either protected or private and most will have no set or get methods. I figure that for most projects using textile there will be no issues but please let me know if you are going to get bitten by any of the above and if you know of other devs who use textile in their projects, please give them a heads-up.

@yellowled, feel free to open issues for bugs, problems or feature requests over on the textile repo on github.

Thanks guys, I've actually been working a lot on textile recently and want to push some big changes to the code soon. In the meantime Antti, if you do go down the textile route, then you probably want to use the TextileRestricted() method as this is meant to deal with input that's coming from untrusted sources such as public comments. The normal mode in textile supports a far wider range of features.

Fantastic! Thanks for running the awards over at CMSCritic and congratulations to Ryan and the other contributors.

Hi @antknight, great to see a newer face on the forum so firstly: welcome! As with most things PW, the answer is almost certainly "yes" but in this case you'd probably be compromising the permissions on your template & css files in order to do it. I know that some other CMSs do have this kind of feature though (like Textpattern, which I like a lot.) Can I ask what your rationale for the request is? Do you need to develop on a live server or something? It might be that mounting the server partition locally over SSH would be both faster and more secure in such cases.

There's also "possessive quantifiers" and "illogical shift upwards". Oops, scratch the last one, that's a machine code mnemonic a bit like "halt and catch fire".

Hi @Martijn These HTML5 extended attributes should be totally transparent to browsers that don't support them so I don't think there would be any need for PW to have to treat them differently as you'd still have to do server side validation/checking on entered values anyway.

@Matthew, partially on topic: have you had a look at textile for some of its typographic features (see the entities section) like automatic curly-quotes, em-dashes, elipses, dimensions etc? Ryan wrote a textformatter module for it that you can apply to your text fields.

Yep -- just tried it -- even more useful than my snippet above. I'll be adopting this, thanks!

Ryan, IIRC, they are almost so -- but I thought that in HTML5 you needed to omit the delimiters that PCRE expects. I might be wrong (probably so) and I don't have time to dig through the documentation right now.

A few keystrokes if you do it a lot. My main driver is that I like the fluency of it. @Adam Not seen it done like that before. Will try that out too.

Perhaps slightly off-topic (or on-topic but from a programmer's twisted pov.) When dealing with object oriented PHP code, I like to keep things terse and also like to be able to chain things straight from when they are constructed (kind of like the fluent style) -- but PHP doesn't let you do it. So, when I want to to do this in various parts of my code... echo new somethingOrOther()->set('size', 'big')->render(); ...PHP only lets me do this... $thing = new somethingOrOther(); echo $thing->set('size', big')->render(); Yikes! However, if I define a function (once) called newSomethingOrOther() then I can get what I want easily... function newSomethingOrOther() { return new somethingOrOther(); } // The following now works as I want, however many times I need it in my code... echo newSomethingOrOther()->set('size', 'big')->render(); Ok, end of diversion, as you were.

Anyone here installed Piwik 1.9.2 recently? If so, check your installation for a possible backdoor that it may have contained. The download server was compromised and a backdoor injected into the downloadable. Background, including basic cleanup instructions, via the-H (includes links for more info).

Hello USSliberty. Welcome to the PW forums and thank-you for your contribution.

Methinks this... 'url' => "./$event[id]", // event ID is the url segment ); return json_encode($json); // <<<< wrong data? } ...should be this... 'url' => "./$event[id]", // event ID is the url segment ); return json_encode($items); // <<<< right data? }

Hi Harm, try to develop the habit of always putting the constant first in statements like this... if('inactive' == $u->user_status) ... Then if you miss out an '=' sign PHP will shout at you about it.