[plugin] [ORPHAN] cnk_versioning

Algaris · 2011-12-12 09:42:11

johnstephens wrote:

@whaleen: I keep my external output snippets as forms in cnk_versioning’s forms/ directory, and include them in rah_external_output’s tab via Textpattern’s output_form tag.

I’m trying to wrap my head around this. What would be the difference between doing this and just using a plain old <txp:output_form form="xx" /> in your code? Won’t the end result be the same either way with the form being pulled from the database?

Last edited by Algaris (2011-12-12 09:42:25)

johnstephens · 2011-12-12 13:50:41

@Algaris: I’m not sure I understand your question. I do use the <txp:output_form form="xx" /> tag in external_output admin interface to grab the appropriate form. If you’re asking why I put the form in cnk_versioning’s forms/ directory, it’s because I want to keep my template code in the file system for all the benefits that offers.

maniqui · 2011-12-12 14:07:03

Hi Algaris,

What would be the difference between doing this and just using a plain old <txp:output_form form=“xx” /> in your code?

I’m not sure if your question is formulated properly or if I didn’t understand it.
In any case, the trick posted by johnstephens is clever & pretty simple: in some rah_external_out entry, you put just a <txp:output_form form="some_form" />, and that’s all you will need to have the code for a rah_external_output located in an editable file (imported back to DB via cnk_versioning).

Won’t the end result be the same either way with the form being pulled from the database?

Even when using cnk_versioning, stuff (forms, pages and, optionally, css) is pulled from DB.
The only “job” done by cnk_versioning is to “suck” forms, pages and css files from the filesystem and dump them into the DB. Then, TXP inner cogs look for those forms, pages and css in the DB, as always.

Algaris · 2011-12-13 08:30:42

Sorry I could have been clearer and worded my question better.

What I was trying to say was what advantage would there be to using rah_external_output and txp:output_form as apposed to just using txp:output_form in a page template?

As far as I can tell both would accomplish the same thing, pulling content from the database

I hope this makes sense. It could be that I’m having a slow week and missing something obvious ;-)

Last edited by Algaris (2011-12-13 11:58:58)

jakob · 2011-12-13 13:19:13

You’re right, you don’t need rah_external_output for normal txp-internal use. You would use it if you want to provide another site with a txp-generated content snippet. I did once have a hybrid case where a flash-based map widget needed you to specify a an xml-url/file to load. rah_external_output can be used for that too.

The problem is you cnk_versioning doesn’t save the rah_external_output templates as files so you can’t edit them in your normal text editor. johnstephen’s trick of just placing <txp:output_form name="my-rah-external-template" /> in the rah_external_output templates gets around that limitation.

johnstephens · 2011-12-13 16:46:07

@Algaris: Jakob’s explanation pretty much covers it, but here’s an example from the wild. I built the site for an academic journal, and one thing they did routinely was publish the article info for each article in text files for scraping by a custom aggregator. I was able to automate this by using rah_external_output to generate the text “file” dynamically using the article information Textpattern already has in its database.

Here’s an article page.

Here’s the article metadata feed.

Using rah_external_output allows me to pull this information out in a format I define without littering my site architecture with unnecessary sections and mucking around with serving certain sections with a different MIME-type.

I hope this makes sense!

sidekarsten · 2012-01-04 23:01:55

Dear maniqui, will have a good look at this versioning plugin, looked at it before but found it very difficult to understand how it works exactly. My sites will be on the same server, even on a subdomain of the main site mainsite.com / relatedsite.mainsite.com

However, at the moment each is running on its own TXP install and Dbase but as I understand it, this should not really matter for the versioning plugin. Thanks for the advice however, I will try to get that working… In anycase, rah_external_output is a very handy plugin, as I was also looking for a way to include content from the related sites in the main sites (as a sort of overview site to show what is going on in the related sites) and this seems perfectly suited for that!

Cheers

maniqui · 2012-01-05 00:01:37

sidekarsten wrote:

Dear maniqui, will have a good look at this versioning plugin, looked at it before but found it very difficult to understand how it works exactly. My sites will be on the same server, even on a subdomain of the main site mainsite.com / relatedsite.mainsite.com

This is exactly the same scenario where I implemented the suggested solution.

After installing (and visiting the corresponding tab & running the process), the cnk_versioning plugin will create one file for each page & form (& css, although I don’t use the feature of serving CSS from TXP database) you have on your database. This process is usually run just once, you don’t need to do it again.
After that, each time you edit any of this files (i.e. you edit a form or a page), cnk_versioning will “suck it” from the filesystem and “dump” it back to the database. One-way only (and, btw, will do it only when the website’s production status is set to “testing” or “debut”, not “live”).

So, some extra notes for you:

first, you will have to decide:
- A) if all websites will share the same set of forms & pages (probably, the ones created in the main website)
- B) or if you will prefer to have each related website with its own set of pages & forms, and also, have some extra pages & forms symlinked from a common “pool” of files (this “pool” of files could be the files corresponding to the main website).

If you go with option A:

you will have to install & configure cnk_versioning on each website ***but***
only run the “create files” process once, in one of them (probably the main site), and then do all the symlink setup

If you go with option B:

you will have to install & configure cnk_versioning on each website ***then***
run the “create files” process once, in each website.
and then “add” the extra pages & forms on each related website by symlinking the corresponding files from the main website’s folder.

There are a few different ways to setup both options A & B, and in fact, I can think of few more options than just A & B. For example, option C (a mix of A & B):

the main website has its own set of files (pages & forms).
then all related websites also have a common set of files (pages & forms). This set of files could, of course, include symlinks to files on main website.

This reduces the need of setting up a folder for pages&forms on each related website.

However, at the moment each is running on its own TXP install and Dbase but as I understand it, this should not really matter for the versioning plugin.

It wouldn’t matter in the sense that all files (pages & forms) will be “sucked back” to each database (i.e. for each website).

In any case, rah_external_output is a very handy plugin, as I was also looking for a way to include content from the related sites in the main sites (as a sort of overview site to show what is going on in the related sites) and this seems perfectly suited for that!

So, I think you will find this trick very useful. It takes advantage of using rah_external_output in tandem with cnk_versioning.

Bottom line: if you setup all this properly (and, really, it isn’t that hard as it may sound), you will totally forget about editing files in a browser’s textarea, and you will greatly reduce the need of doing duplicated edits/tasks across different websites. And you will get some extra gains if you work with VCS (like Git/Mercurial/SVN/etc).

markus_falk · 2012-01-29 17:19:46

too good to be true :)

Warning: Duplicate column name ‘file_mod_time’ ALTER TABLE projectm_txp_form ADD `file_mod_time` DATETIME NULL textpattern/lib/txplib_misc.php(653) : eval()’d code:528 cnk_ver_batch_query() in /Applications/XAMPP/xamppfiles/htdocs/project-m/textpattern/lib/txplib_db.php on line 89

Installation aborted

Last edited by markus_falk (2012-01-29 17:23:06)

maniqui · 2012-01-29 20:00:51

markus_falk, it seems the plugin’s installation process was already run before, could that be?

markus_falk · 2012-01-29 20:36:54

that’s correct. I got a different error that I can’t reproduce right now so that I wanted to reinstall it.

I deleted the plugin from the admin tab. But I also removed all the database fields with that name. still the error occurs.

btw: thanks for your fast reply :)

markus_falk · 2012-01-31 18:59:27

Sorry but I just can’t get it to work … I successfully de- and reinstalled the plugin.

Problem is that it just can’t get it to “write pages and forms to files”. It returns:

Folder “/forms/” is not writable.
Folder “/pages/” is not writable.
Folder “/css/” is not writable.

but I put all 3 folders to drwxrwxrwx. It also tells me that there are files in those folders. These could only be the OSX storage files. but overwriting doesn’t work.

any idea? I just don’t want to give up on this plugin cuz I luv the idea of it :)

Textpattern CMS

Textpattern CMS support forum

#157 2011-12-12 09:42:11

Re: [plugin] [ORPHAN] cnk_versioning

#158 2011-12-12 13:50:41

Re: [plugin] [ORPHAN] cnk_versioning

#159 2011-12-12 14:07:03

Re: [plugin] [ORPHAN] cnk_versioning

#160 2011-12-13 08:30:42

Re: [plugin] [ORPHAN] cnk_versioning

#161 2011-12-13 13:19:13

Re: [plugin] [ORPHAN] cnk_versioning

#162 2011-12-13 16:46:07

Re: [plugin] [ORPHAN] cnk_versioning

#163 2012-01-04 23:01:55

Re: [plugin] [ORPHAN] cnk_versioning

#164 2012-01-05 00:01:37

Re: [plugin] [ORPHAN] cnk_versioning

#165 2012-01-29 17:19:46

Re: [plugin] [ORPHAN] cnk_versioning

#166 2012-01-29 20:00:51

Re: [plugin] [ORPHAN] cnk_versioning

#167 2012-01-29 20:36:54

Re: [plugin] [ORPHAN] cnk_versioning

#168 2012-01-31 18:59:27

Re: [plugin] [ORPHAN] cnk_versioning

Board footer