[plugin] [ORPHAN] cnk_versioning

jstubbs · 2011-06-13 15:23:18

Giving the plugin a whirl and having a few issues. The $CNK_VER_OUTPUT_PATH at first I got wrong but now that is ok, the /versions/ folder and their sub-folders (pages/forms/css) is within the /textpattern/ folder and all permissions set to 777.

I get a success message (Forms were successfully written to the “/forms/” directory. etc) when running Write to Files but upon inspection there is nothing in /forms, /pages or /css and I see an Unknown section error on the front page of the site (running in Testing mode).

Wondering what I missed??!

maniqui · 2011-06-13 15:34:26

Jonathan: it doesn’t seem to me that you missed anything, but it may have been one of those times when this awesome plugin goes awry. It always needs one or two tries until it gets properly configured.

First, I hope you have a backup. Your forms & pages & css may have just got vanished :o
Remember: one this plugin is set, it will update/add any new file as a form/page/css, and also will delete any form/page/css not present anymore.

So, it seems that the plugin never wrote the files (forms, pages and css) to the filesystem (that’s incorrect behavior), but then, when it went to read the files, it didn’t find anything on those folders, and so, acting accordingly, it deleted every form/page/css from the database. That is correct behavior of the plugin.

That’s what you got the Unknown section message. You have some page template assigned to some section, but TXP can’t find the page template anymore, so, it prints that error message (it should be more lie Missing like page template, than Unknown section).

Bottom line: I’m not sure why it said it wrote the files sucessfully but then, there were no files in the folder. I’d suggest re-installing/re-configuring the plugin.

hotwebmatter · 2011-06-18 05:14:27

I’m excited to try out this plugin, but first …

Can someone verify that cnk_versioning 0.1.6 (near as I can tell, the current version on textpattern.org) will be compatible with Textpattern 4.4.0? Much obliged!

maniqui · 2011-06-18 05:32:17

Check the OP: there is version cnk_versioning 0.1.7.

And it think it works OK with 4.4.0 (I’ve yet to test, but it worked ok with 4.3.0).

hotwebmatter · 2011-06-18 08:36:40

Oops, better make that Textpattern version: 4.4.1 (r3575) (as of five minutes ago!) And I guess the answer to my question is “Nope, nobody has tested it with that version yet, but you may as well be the first.”

=^D

I’ll let you know how it goes. I’m pretty sure I won’t get around to it tonight, though …

Even though I have a db backup, I wanted to clarify one last thing: the full path to the directories I’m supposed to create.

In the OP the plugin author says “Before installation, you have to create a php-writable “forms”, “pages” and a “css” directory in the textpattern root directory.” I’m not sure whether that means:

the DocumentRoot of my Apache VirtualHost, i.e.:
- ~/public_html/forms
- ~/public_html/pages
- ~/public_html/css
the /textpattern/ directory inside the DocumentRoot, i.e.:
- ~/public_html/textpattern/forms
- ~/public_html/textpattern/pages
- ~/public_html/textpattern/css
or some other variant … for example, jstubbs mentioned that he used folders like this:
- ~/public_html/textpattern/versions/forms
- ~/public_html/textpattern/versions/pages
- ~/public_html/textpattern/versions/css

… but then again, he also had trouble with the plugin.

Or is it really that I can set the $CNK_VER_OUTPUT_PATH to any directory I want? I could just blunder through with it, but it would be nice if it were clearer in the documentation, so I’m asking for the benefit of future forum readers as much as for myself.

Last edited by hotwebmatter (2011-06-18 09:07:22)

Gocom · 2011-06-18 08:49:08

maniqui wrote:

And it think it works OK with 4.4.0 (I’ve yet to test, but it worked ok with 4.3.0).

Yes, it works just fine. Relevant callbacks and database structure hasn’t changed in “awhile”.

hotwebmatter wrote:

“Nope, nobody has tested it with that version yet, but you may as well be the first.”

Don’t worry, you won’t be the first to use cnk_versioning ;) Pretty much every serious team of developers uses it or some similar tool. Makes using versioning systems — um — easier.

Last edited by Gocom (2011-06-18 08:55:48)

hotwebmatter · 2011-06-18 22:28:09

Well, I did it, and it works — almost.

At first I had the same Unknown column 'file_mod_time' in 'field list' warnings as algaris but I fixed this by running “install” from admin-side -> presentation -> versioning.

Now it works flawlessly for Pages and Forms, but the CSS is getting corrupted. If I disable the plugin and view presentation -> style, it looks like all the punctuation is stripped from the markup:

bodymargin0pxpadding0pxcolor6c6969fontfamilyTahomaGenevasansseriffontsize12pxlineheight15embackgroundcolor252423backgroundimageurlimages/templatemobodyjpgbackgroundrepeatrepeatxbackgroundpositiontopaalinkavisitedcolor990000ahovercolorAAAA00textdecorationnoneamoredisplayblockwidth137pxheight35px

… etc., etc.

Any idea why that might be happening?

Here’s what I’m running:

TXP version: Textpattern 4.1.1 (just released last night)
Server version: Apache/2.2.14 (Ubuntu)
PHP 5.3.2-1ubuntu4.9 with Suhosin-Patch

Last edited by hotwebmatter (2011-06-19 05:17:11)

Gocom · 2011-06-19 01:57:19

hotwebmatter wrote:

At first I had the same Unknown column 'file_mod_time' in 'field list' warnings as algaris but I fixed this by running “install” from admin-side -> presentation -> versioning.

That will show up to everyone until the plugin is installed by manually running the installer

Now it works flawlessly for Pages and Forms, but the CSS is getting corrupted. If I disable the plugin and view presentation -> style, it looks like all the punctuation is stripped from the markup:

Are you sure it’s stripped from punctuation and that it’s it not actually base64 encoded string? If it is base64 encoded string (which would mean you are using the 0.1.7 Julián linked – etc), you will need to remove base64_encode / base64_decode instances from the plugin source. Back in the day CSS used to be stored as base64 encoded string, but it was later on dropped.

So, go to your plugins pane and click cnk_versioning’s edit link. From the source find line:

$css = doSlash(base64_encode(file_get_contents($filename)));

And change it to:

$css = doSlash(file_get_contents($filename));

And then line:

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

And change it to:

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

…or just simply search for base64_ and remove the function.

Last edited by Gocom (2011-06-19 02:09:42)

hotwebmatter · 2011-06-19 05:16:33

Thanks, Gocom!

I found the base64 functions and removed them from both lines as you instructed. Now I’m getting a new error and some odd behavior. Whenever I load a page on my site from either the front-end or admin-side interfaces, I see:

Parse error: syntax error, unexpected '[' in /home/userid/hotwebmatter.com/textpattern/lib/txplib_misc.php(653) : eval()'d code on line 410 The above errors were caused by the plugin:cnk_versioning

Also, it seems odd that although the cnk_versioning plugin is enabled and Production Status is set to “Testing” in Admin Preferences, I can now edit the pages, forms and css styles in the admin-side interface. (I thought this functionality was supposed to be disabled if the plugin were correctly installed.)

If needed, I can paste the cnk_ver_update_css() and cnk_ver_pull_css functions in their entirety for context, just to verify that I haven’t fat-fingered something. Let me know if that would be helpful.

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.

Textpattern CMS

Textpattern CMS support forum

#97 2011-06-13 15:23:18

Re: [plugin] [ORPHAN] cnk_versioning

#98 2011-06-13 15:34:26

Re: [plugin] [ORPHAN] cnk_versioning

#99 2011-06-18 05:14:27

Re: [plugin] [ORPHAN] cnk_versioning

#100 2011-06-18 05:32:17

Re: [plugin] [ORPHAN] cnk_versioning

#101 2011-06-18 08:36:40

Re: [plugin] [ORPHAN] cnk_versioning

#102 2011-06-18 08:49:08

Re: [plugin] [ORPHAN] cnk_versioning

#103 2011-06-18 22:28:09

Re: [plugin] [ORPHAN] cnk_versioning

#104 2011-06-19 01:57:19

Re: [plugin] [ORPHAN] cnk_versioning

#105 2011-06-19 05:16:33

Re: [plugin] [ORPHAN] cnk_versioning

#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

Board footer