Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: ied_plugin_composer - new plugins never came that easy
nice addition! i am completely lazy with version numbers and that’ll definitely get me into better plugin-writing shape. wonderous!
Offline
#62 2008-01-12 13:33:46
- net-carver
- Archived Plugin Author
- Registered: 2006-03-08
- Posts: 1,648
Re: ied_plugin_composer - new plugins never came that easy
All
there’s not much point using my revision mods if you don’t use svn. It’s far easier to simply extend the version string with whatever .digits you want.
However, if you are running svn — highly recommended by the way — then it might be of use to you if you have the LastChangedRevision property setup on your files.
— Steve
Offline
Re: ied_plugin_composer - new plugins never came that easy
When I’m trying to edit plugin with cyrillic characters i get this:
The same bug appears in help box:
But if I export pluging code “as is” (without base64 encoding) everything is good – al characters are displayed right.
Providing help in hacking ATM! Come to courses and don’t forget to bring us notebook and hammer! What for notebook? What a kind of hacker you are without notebok?
Offline
Re: ied_plugin_composer - new plugins never came that easy
I noticed a tiny bug with line endings when exporting to a php file. My code blocks are coming back with /r/n line endings which is a pain in emacs as I have to clean out the ^M ‘s every time.
I was perplexing because it was only happening in the code blocks, the Help and Style blocks were fine. After some poking around I think I found the reason for the discrepancy. The Style and Help blocks get run through ied_plugin_extract_hunk which explodes and trims the lines in ied_plugin_make_array and joins them back together with \n as the glue. This seems to remove the errant /r.
The Code block however does not get run through the split join fun and so it maintains the /r/n line endings.
Doing a simple str_replace("\r\n","\n",$code) in ied_plugin_save_as_php_file seems to do the trick for me and I get consistent line endings throughout the file.
Can anyone think of any reason we shouldn’t do that? Does it cause issues in Windows?
Shoving is the answer – pusher robot
Offline
Re: ied_plugin_composer - new plugins never came that easy
the_ghost
Thanks for highlighting this problem. I have a couple of wild theories:
- I believe (someone correct me if I’m wrong) that most Latin/Greek/Cyrillic/Hebrew characters need two bytes per character to display properly. Since base64 was an ASCII represenatation of ASCII text for MIME purposes, I wonder if it’s choking on the 2-byte characters. I would guess the encoding side would handle arbitrary byte sequences, without regard to character set or encoding, but perhaps when it decodes the sequence it’s treating each “character” (read: byte) as a separate entity and becoming confused. I may be way off track here. Please, if anyone knows better, let me know.
- I have incorrectly used PHP’s base64() on raw characters and should perform some intermediate step in order to ensure the safe transit of Unicode characters in Textpattern. Perhaps I should run the plugin blocks through utf8_encode() first to convert them? However, I have no idea what that will do “the other end” when the plugin is installed by end users. Again, if someone (ruud? wet?) who understands the intricacies of character encodings far better than me can offer suggestions here I’d be most grateful.
The short answer is, a) yes it appears to be a problem and b) I don’t have much idea how to solve it just yet. Being English and using “ordinary” character sets myself doesn’t help matters. Perhaps if you would be so kind to e-mail me some code containing cyrillic characters (will ‘save as php’ work from the plugin composer?) I can use it as a test example and try various settings in the code to fix it. I have no idea if it’ll work, since my browser probably won’t display cyrillic characters anyway :-( Perhaps there’s a Firefox language pack I can install…
hakjoon
I noticed a tiny bug with line endings when exporting to a php file…Doing a simple
str_replace("\r\n","\n",$code)in ied_plugin_save_as_php_file seems to do the trick
Well spotted, sir, and thanks for the diagnosis; I’d never have noticed that. It certainly makes sense to my untrained eye and I can’t see any downside to this (I’m running Windoze and it works for the help and style blocks so it should work for the code as well). Perhaps I should run $code through ied_plugin_extract_hunk as well?
BTW, I still don’t know if uploading PHP files works on non-windows systems, or on hosts with various magic_quotes setups. It works for me now, but when I took over the plugin I switched the logic because it didn’t work on my hoster. My host is, however, somewhat of an anomaly insofar as they still have register_globals on (erm…) and a few other foibles so I’d be interested to hear comments from others on this.
I have an unreleased minor bug fix version waiting in the wings. I’ll update it to modify the line endings in the code block and see how it goes, and try to find a solution for Victor as well. Thanks guys.
Last edited by Bloke (2008-03-28 18:16:27)
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
Re: ied_plugin_composer - new plugins never came that easy
TXP uses UTF8 everywhere, so unless you’re sending email and need latin1, never use utf8_decode, because that converts it to latin1, which is wrong for 2 reasons:
- not all utf8 characters can be translated to latin1, resulting in question marks.
- you should not use latin1 on a page that has a utf8 charset. While utf8 is always valid latin1 (even if not readable), latin1 is not always valid utf8, especially if you characters with the high-bit set. Only the lower 7-bits of latin1 and utf8 are equal.
When I at the plugin code, I see:
$code = '<textarea name="code" id="plugin_editor" rows="30" cols="90" class="codepress php">'.htmlentities(utf8_decode($code)).'</textarea>';
$help = '<textarea name="help" rows="30" cols="90" class="mceEditor">'.htmlentities(utf8_decode($help)).'</textarea>';
$css = '<textarea name="css" rows="15" cols="90">'.utf8_decode($css).'</textarea>';That should be:
$code = '<textarea name="code" id="plugin_editor" rows="30" cols="90" class="codepress php">'.htmlspecialchars($code).'</textarea>';
$help = '<textarea name="help" rows="30" cols="90" class="mceEditor">'.htmlspecialchars($help).'</textarea>';
$css = '<textarea name="css" rows="15" cols="90">'.htmlspecialchars($css).'</textarea>';htmlspecialchars is enough for escaping a string in HTML. Other entities only need escaping in charsets that don’t support those entities natively.
Base64 encoding doesn’t care what it encodes. It treats everything as a bunch of bytes and encodes them. Basically, all it does is convert 8-bit bytes (whatever they are used for, be it us-ascii, binary or multibyte chars) into a 6-bit representation that contains only readable characters which can safely be transported through media (like SMTP) that are not (or were not) 8-bit safe.
Since the Base64 decoding does the exact opposite of encoding, what comes out after decoding is exactly the same as the original before encoding.
I also noticed this:
if (MAGIC_QUOTES_GPC) {
foreach ($plugin as $item => $value) {
$plugin[$item] = addslashes($value);
}
}Which, I think, should be (because that’s how TXP does it for GET/POST variables as well):
if (MAGIC_QUOTES_GPC) $plugin = doStrip($plugin);Combined with adding doSlash (which uses the proper escaping for MySQL) when ever using the $plugin variables in an SQL query. There are several places where doSlash seems to be missing in SQL queries.
As for line endings: I suspect most modern text-editors automatically detect line endings correctly, as long as they’re used consistently throughout the file. Personally, I prefer \n line endings above \r\n, because PHP, Apache and MySQL are originally Unix applications and because it saves a byte and is therefore more environmentally friendly ;)
Last edited by ruud (2008-03-28 19:06:41)
Offline
Re: ied_plugin_composer - new plugins never came that easy
ruud wrote:
never use utf8_decode, because that converts it to latin1
Ahaaa. Right you are. The plugin did that when I took it over so, in my character set naivety, I just left it alone.
Many thanks for the clarification, I shall fix the code as you suggest.
EDIT:
if (MAGIC_QUOTES_GPC) $plugin = doStrip($plugin);There are several places where doSlash seems to be missing in SQL queries.
Again, thanks for the pointer. I shall visit the places that don’t strip/slash the input and correct them. That’s probably the missing piece of the puzzle when the plugin came to me and why it worked for Yura but not me. I could never fathom why addslashes() was there. doSlash() makes more sense and is, in fact, what net-carver suggested to me ages ago and I forgot about. D’oh.
Last edited by Bloke (2008-03-28 19:06:26)
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
Re: ied_plugin_composer - new plugins never came that easy
ruud wrote:
As for line endings: I suspect most modern text-editors automatically detect line endings correctly, as long as they’re used consistently throughout the file.
I was seeing this in emacs which is not really what one would call modern :) I think the main issue was the two different sets of line endings which I know can cause issues with subversion and probably elsewhere.
Plus getting rid of the ^M every time I edited a file wasn’t the most fun.
@Bloke: I don’t know if extract_hunk is necessary. It does a lot of extra processing which if all we want to do get normalize the line endings str_replace() seems to do the job without splitting all the lines into arrays and re-joining them.
Last edited by hakjoon (2008-03-29 04:27:39)
Shoving is the answer – pusher robot
Offline
Re: ied_plugin_composer - new plugins never came that easy
v0.74 [ compressed ] fixes a small problem that sometimes caused the plugin code to disappear if the style block was left empty. Also hopefully addressed the_ghost’s cyrillic character problems thanks to ruud’s suggestion (Victor: please test it and let me know) and addressed the other things ruud mentioned, as well as removing the crlf from the code as per hakjoon’s suggestion.
Hopefully I’ve covered them all. If you spot anything I’ve missed or it falls apart, just holler.
P.S. Would someone be able to update the textpattern.org entry with the latest info please? If you think it’s appropriate you can assign me as editor of that article so I don’t have to bother anyone in future.
Last edited by Bloke (2008-04-01 16:34:00)
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
Re: ied_plugin_composer - new plugins never came that easy
Stef! It’a amazing, thanks! Cyrillic works perfect!
went to find more bugs…
Providing help in hacking ATM! Come to courses and don’t forget to bring us notebook and hammer! What for notebook? What a kind of hacker you are without notebok?
Offline
Re: ied_plugin_composer - new plugins never came that easy
Another minor update to v0.75 | compressed
Changes:
- adds a (Yes) to the version column of any plugins that are ‘modified’ (thanks for the code uli)
- adds a checkbox when editing from the plugin cache directory that allows you to automatically update the file name to match the current version. Useful if you can’t be bothered to fire up your FTP client to rename it manually (though it’s probably a good idea to make a backup first anyway in case you need to roll back for some reason!)
- fixed a couple more gTxt() edits and a tiny bit of housekeeping here and there
The next pencilled version, 0.8 that uses the latest plugin template and allows you to set a ‘recommended’ plugin load order if you wish, is written and pending a few minor details. Like, umm, help! It currently relies on an SVN copy of TXP so is probably not of much use yet anyway and is suffering feature creep so it might not be officially out for a while. If anyone wants a copy to mess around with and is running a recent SVN (r2871 or later – new template available in r2878) just let me know.
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
Offline