[plugin] [ORPHAN] cnk_versioning

hotwebmatter · 2011-06-19 05:58:51

The error message refers to line 653 of /textpattern/lib/txplib_misc.php, which is the following line in the middle of the load_plugins() function:

$eval_ok = eval($a['code']);

Apparently, this is barfing on the cnk_versioning plugin — specifically on the eval()'d code on line 410. Sure enough, line 410 is the line that I just pulled the base64_decode() function out of:

if (@file_put_contents('../'.$CNK_VER_OUTPUT_PATH.'css/'.$r['name'].'.'.$CNK_VER_EXT_CSS, r['css']) === false) return false;

I think this makes sense — because the css files are still base64-encoded, textpattern fails to read them into the database. My hunch is that I either need to put the base64_decode() function back into the cnk_ver_pull_css() function, or use another expedient method to de-base64 the css source files.

I expect I’ll have this sorted in a few more minutes, but I’ll keep you posted!

Gocom · 2011-06-19 06:48:21

hotwebmatter wrote:

just to verify that I haven’t fat-fingered something

If that what you have quoted is from your code, yes there you have your cause. You have changed a variable to a constant by removing a dollar sign. r['css'] should be $r['css'].

because the css files are still base64-encoded, textpattern fails to read them into the database

Not the reason to the error. The contents of the file wouldn’t effect anything at all error-wise, just what gets to the database.

The error message refers to line 653 of /textpattern/lib/txplib_misc.php, which is the following line in the middle of the load_plugins() function:

Every error caused by a plugin will point to that specific line that evaluates the plugin code. Not directly related to anything.

My hunch is that I either need to put the base64_decode() function back into the cnk_ver_pull_css() function, or use another expedient method to de-base64 the css source files.

Just put the real, original styles you had to the css file and that’s it. If you don’t have the original styles stored anywhere, you can try to encode the base64 string using some online tool.

Last edited by Gocom (2011-06-19 06:54:56)

hotwebmatter · 2011-06-19 07:25:49

Well, it’s working, I think.

It did eat all the CSS styles I already had stored in the database, though. Rather, it chewed them up and spit them out, but not in a useful format. (Luckily, I believe they can be restored from backup.) My advice to users considering this plugin would be to install it right away when initiating a new TXP site, rather than after doing a bunch of work on a site. As I said above, Pages and Forms dumped flawlessly from the database to the versioning directory, but Styles were problematic.

Gocom : Are you sure that Textpattern no longer stores CSS as base64-encoded in the database? Because I did remove those functions from the plugin, and something is still scrambling my CSS, but only as viewed through the txp admin-side webpage.

Here’s the behavior I observed:

I put the base64_decode function back temporarily and hit the “Write pages & forms to files” link, which returned “There was an error while processing” messages for Pages and Forms, but announced success with the CSS.

CSS styles that were already in the TXP database were exported to the $CNK_VER_OUTPUT_PATH/css/ directory in some weird format I couldn’t edit with vim. Maybe I should have tried to use a binary/octal/hex editor, but I opted instead to delete them all for a fresh start.

The one Style which exported correctly was the one I had added to the database by copying it into the versioning directory — that one restored as vim-editable ASCII.

To illustrate, this is a the output of the file command in the /versions/css/ directory:

userid@hostname:css$ file *
archive.css: data
default.css: ASCII C program text, with very long lines

When I add CSS styles to the $CNK_VER_OUTPUT_PATH/css/ directory, they get picked up by cnk_versioning appropriately and stored in the database; however, if I then disable the plugin and view the Styles using Textpattern, they show up as base64_encoded strings. I verified this by cutting from the Textpattern admin-side Presentation -> Style page and pasting into a file called default-css.b64, then using a tiny Perl utility to decode the base63 to ASCII.

debase64.pl:

#!/usr/bin/perl -w
use MIME::Base64;
open( DATA, $ARGV[0] ) or die "ERROR opening file!";
while ( <DATA> ) {
	$decoded = decode_base64( $_ );
	print $decoded;
}
close DATA;

Running this against the base64-encoded file decoded it correctly, while running it against the data file displayed a bunch of jibba-jabba:

userid@hostname:cnk_versioning$ debase64.pl default-css.b64 > default-css.css
userid@hostname:cnk_versioning:cnk_versioning$ file *
archive-css.data:        data
default-css.b64:         ASCII text, with very long lines
default-css.css:         ASCII C program text, with very long lines

Even though file says that default-css.b64 is “ASCII text” it is plainly base64-encoded. Here are the first few dozen characters:

LwoJb3ZlcmZsb3c6dmlzaWJsZTsgLyogaWU3IHBhZGRpbmcgYnVnIGhhY2sgKi8KICAgIGNvbG9yOiMzMzM7CiAgICB0ZXh0LXNoYWRvdzoxcHggMXB4ICNmYmQ5Nzg7CiAgICBkaXNwbGF5Omlub

Anyway, to sum up, it’s been an adventure getting this installed, but it appears to be working as advertised, so I think I’ll use it for a while. The entire DocumentRoot of my TXP instance is already in a git repository, so I will be git committing my edits to the files under the versioning directory. Fun!

I’ll try not to worry that when I disable the plugin, the files may not be editable directly in Textpattern. If I want to edit things that way again, I can just back up the versioning directory, disable the plugin, and then cut and paste the human-readable files over the base64-encoded glop in the Textpattern window.

Actually, first I should restore the base64 functions to the cnk_versioning plugin and see whether everything works correctly. I have a hunch that restoring those functions may address my concern about later editing Styles within Textpattern.

Finally, my problem with corrupted CSS styles may not be the fault of this plugin. For example, it may have occurred last night when I upgraded Textpattern from 4.4.0 to 4.4.1, or it may be due to something else entirely. I guess the lesson is not to make too many changes all at once.

hotwebmatter · 2011-06-19 07:29:08

@Gocom:

You have changed a variable to a constant by removing a dollar sign. r[‘css’] should be $r[‘css’].

Good eye, sir! I had already fixed it myself by the time I read this, but thank you nonetheless!

Gocom · 2011-06-19 07:33:15

You make everything so unnecessarily complicated.

hotwebmatter wrote:

Are you sure that Textpattern no longer stores CSS as base64-encoded in the database?

Yes, I’m sure. Otherwise I wouldn’t have said so. More specifically see r3300.

Actually, first I should restore the base64 functions to the cnk_versioning plugin and see whether everything works correctly.

No it won’t as Textpattern doesn’t use base64 encoding, and won’t decode the base64 encoded strings. You are just going to f’up the styles.

it may have occurred last night when I upgraded Textpattern from 4.4.0 to 4.4.1

4.4.1 upgrade won’t touch styles stored in the database, and it’s unlikely that would be the cause. It’s more likely caused by the plugin.

Last edited by Gocom (2011-06-19 07:37:40)

hotwebmatter · 2011-06-20 00:29:34

@Gocom:

You make everything so unnecessarily complicated.

Guilty as charged. I’ll try to cut down on long incoherent posts like the one I made last night. (Better yet, I’ll try to stop staying up so late at night that I get verbose and incoherent!)

I did restore from the last mysqldump, which I made after upgrading to 4.4.1 but before installing cnk_versioning. I got all my old styles back, but I also lost cnk_versioning for the moment. I think everything will go much more smoothly when I re-install the plugin. I’ve manually created files in the versions directory from the two active stylesheets in the database, and I’m going to make sure that I back up that folder elsewhere, so that I can restore it if those files get clobbered. Also, I’ll make certain this time that I remove the base64 functions from cnk_versioning 0.1.7 before I enable it.

By the way, sorry for posting so many irrelevant red herrings — I think the base64-encoding was probably caused by the mem_templates plugin, which I had initially used to install the theme. At any rate, its import($dir) function contains these lines:

if ($type == 'css') {
    $data = base64_encode(implode('', $data));
}

Does that look like it is related?

AdamK · 2011-06-20 10:45:26

Hello

I have a strange problem: I’ve created all the three folders, I’ve given 777 to them (linux host) and still I get

Folder "/forms/" is not writable.
Folder "/pages/" is not writable.
Folder "/css/" is not writable.

I use multisite installation, TXP 4.4.1

$CNK_VER_OUTPUT_PATH = ‘_templates/versioning/’;

which, as I suppose, should be read as

~/public_html/textpattern/sites/sitename.pl/public/_templates/versioning

versioning folder is 777 as well

I have no clue…

Adam

Last edited by AdamK (2011-06-20 10:45:54)

maniqui · 2011-06-20 16:57:13

Hi Adam.
Try:

$CNK_VER_OUTPUT_PATH = ‘public/_templates/versioning/’;

jstubbs · 2011-06-21 01:15:38

$CNK_VER_OUTPUT_PATH = ‘public/_templates/versioning/’;

It didn’t work for me until I used a folder inside the main Textpattern folder. That’s what the instructions appear to require – as I read them anyway. By the time I figured it out all the forms/pages/css were deleted from the site I was working on but nothing had been replaced by cnk_versioning.

artagesw · 2011-06-21 01:29:14

I’m interested in hearing use cases for cnk_versioning. Are you using it so that you can easily version your code in an external version control system (subversion, git, mercurial, etc.)? Or are you using it simply as a way to avoid building your site’s code within the Textpattern admin interface (i.e. you simply want to use an external text editor or IDE)? Or both? Or some other reason(s)?

johnstephens · 2011-06-21 02:00:15

jstubbs wrote:

It didn’t work for me until I used a folder inside the main Textpattern folder. That’s what the instructions appear to require – as I read them anyway. By the time I figured it out all the forms/pages/css were deleted from the site I was working on but nothing had been replaced by cnk_versioning.

It’s not required— I always keep my templates in a directory nested within the DocumentRoot outside the textpattern directory.

artagesw wrote:

I’m interested in hearing use cases for cnk_versioning. Are you using it so that you can easily version your code in an external version control system (subversion, git, mercurial, etc.)? Or are you using it simply as a way to avoid building your site’s code within the Textpattern admin interface (i.e. you simply want to use an external text editor or IDE)? Or both? Or some other reason(s)?

Those are the two main reasons I use cnk_versioning. Building a site entirely using Textmate + the TXP Bundle (or sometimes Espresso), and being able to refresh my browser to see the changes, is especially useful to me.

maniqui · 2011-06-21 02:10:11

jstubbs wrote:

$CNK_VER_OUTPUT_PATH = ‘public/_templates/versioning/’;

It didn’t work for me until I used a folder inside the main Textpattern folder.

Maybe.
I currently have configured it to use a folder inside /admin (on a multi-site install), and I can confirm that it doesn’t work in any location, afaicr. In any case, I’m currently using an slightly modded version.

artagesw wrote:

I’m interested in hearing use cases for cnk_versioning. Are you using it so that you can easily version your code in an external version control system (subversion, git, mercurial, etc.)? Or are you using it simply as a way to avoid building your site’s code within the Textpattern admin interface (i.e. you simply want to use an external text editor or IDE)? Or both? Or some other reason(s)?

Both main reasons, and on top of them, for making teamwork and deployment easier.

artagesw · 2011-06-21 04:25:11

maniqui wrote:

…and on top of them, for making teamwork and deployment easier.

and how does it help with this, exactly?

Gocom · 2011-06-21 04:57:10

maniqui wrote:

Both main reasons, and on top of them, for making teamwork and deployment easier.

Same.

Even when auto-deployments (from the repo directly) and version control system isn’t required, the editor doesn’t support multiple active authors and doesn’t prevent overwrites. But even it did… it wouldn’t change what I personally use. I do use the admin-side editor when working alone (storing the actual end-results in svn/git), but most of the time not when working with others. Using version control system is must and cnk_versioning (and similar tools) are the easiest way of doing it.

artagesw · 2011-06-21 05:23:47

I have never tried the plugin, so I may be missing something. But how does it prevent overwrites or conflicts between multiple authors? It seems that the plugin simply reads/writes a shared file system on the server instead of the database. How do you provide multiple authors with access to this shared space without conflicts?

Textpattern CMS

Textpattern CMS support forum

#106 2011-06-19 05:58:51

Re: [plugin] [ORPHAN] cnk_versioning

#107 2011-06-19 06:48:21

Re: [plugin] [ORPHAN] cnk_versioning

#108 2011-06-19 07:25:49

Re: [plugin] [ORPHAN] cnk_versioning

#109 2011-06-19 07:29:08

Re: [plugin] [ORPHAN] cnk_versioning

#110 2011-06-19 07:33:15

Re: [plugin] [ORPHAN] cnk_versioning

#111 2011-06-20 00:29:34

Re: [plugin] [ORPHAN] cnk_versioning

#112 2011-06-20 10:45:26

Re: [plugin] [ORPHAN] cnk_versioning

#113 2011-06-20 16:57:13

Re: [plugin] [ORPHAN] cnk_versioning

#114 2011-06-21 01:15:38

Re: [plugin] [ORPHAN] cnk_versioning

#115 2011-06-21 01:29:14

Re: [plugin] [ORPHAN] cnk_versioning

#116 2011-06-21 02:00:15

Re: [plugin] [ORPHAN] cnk_versioning

#117 2011-06-21 02:10:11

Re: [plugin] [ORPHAN] cnk_versioning

#118 2011-06-21 04:25:11

Re: [plugin] [ORPHAN] cnk_versioning

#119 2011-06-21 04:57:10

Re: [plugin] [ORPHAN] cnk_versioning

#120 2011-06-21 05:23:47

Re: [plugin] [ORPHAN] cnk_versioning

Board footer