It would be really useful to be able to specify:

• the form input type for admin-editable prefs
• the Pref label name (instead of rah_flat_variable_custom_pref_name)

e.g. in a prefs.json file.

Work in extending, modularity. E.g.

class Rah_Flat_Pages extends Rah_Flat_Import
{
    public $table = 'txp_page';
    public $directory = 'pages';
}

new Rah_Flat_Pages();

If including /prefs for importing, the rah_flat_variables sub-section of the prefs pane shows but the sections panel is then hidden.

Temporary solution: add an empty getPanelName function

public function getPanelName()
    {

    }

to /Import/Prefs.php. But you probably have a better idea ;-)

This would allow a grater level of organization for forms.

UPDATE 3! OK I get it... you're disabling them on purpose... I'm not as think as you drunk I am.
This is going to save me an assload of time.

I'd like to use this plugin to edit outside of the database/txp admin layer.
Unfortunately the Pages and Forms areas no longer appear in the txp_admin's primary navigation and when I manually attempt to get to ?event=page or ?event=form I get a restricted area...

When I disable rah_flat they resume normal display and I am no longer restricted.

Any ideas?

UPDATE! So I changed the name of the directories in the templates folder to "form" and "page" (based on a post of yours in the forum that refers to nomenclature) and now they display correctly. You might want to update your example templates directory to reflect that.

UPDATE2! I CAN get it to show pages and forms if I rename them to page and form BUT then updates do not work... I mist be doing something wrong.

Hi Jukka,

Just trying this new version and it works wonderfully. But it also cleaned out my adi_variables form though too, and from this follows two questions:

• Is there a way to make rah_flat ignore a form (e.g. adi_variables)? That used to be possible in an earlier version by adding form names to rah_flat.config.xml but the removal method seems to have changed since (If I've understood it correctly, rah_flat now drops the entire table and replaces it with the new items from the flat files?).
• Is there a way to have the adi_variables panel still functional? This was mentioned in Issue 3 with an earlier version of rah_flat. I think adi has since changed his own prefs system for v0.5 of adi_variables.

Thanks for your useful feedback :-) Jools

took me a while to get styles working.
This plugin is literally changing everything about the way I design sites... thanks.

Maybe this is just me? ;-) but I was confused by the difference between prefs and variables. As far as I can tell:

Variables (= hard-coded by developer)

• Non-editable in the txp admin
• Always overwritten by the value in the flat file
• Hence: the value must be specified in the flat file

Prefs (= user-editable for admin users with appropriate privileges)

• Editable via the txp admin area in the Preferences > rah_flat_variables panel
• Only created but not overwritten by the flat file
• Flat file can be blank

Correct?

I would like to run this plugin through plugin composer as a php file as I do with my other plugins. This way I can have sets that span multiple sites. As you know running plugins through the cache folder makes them "always on". I'd like an option in prefs to disable import from files so I don't have to load this plugin for every site.

can haz?

I know this is in development so I'm probably jumping the gun – also not sure if "issues" is the right place to post this but anyway here goes:

How about a "write db rows to files" function similar to cnk_versioning? I can see you have a write to file function in the source but as far as I can tell it's not (yet) referenced anywhere. I realize that if you have your own stripped-down custom txp-setup with only the mandatory forms that this isn't so essential, but sometimes it is useful as an "export" possibility.

On a related note, deleting a file doesn't currently result in the relevant entry in the db-table being deleted. To a certain extent, that's good: it means you can disable the plugin and hand over a correct installation to the client. I guess this would also be dependent on writing all db-rows to files as well or else they'll all be deleted.
On the other hand, there's no way of housekeeping, for example if you decide to rename a form or want to get rid of old cruft, duplicate or alternate forms etc. I guess one needs to disable the plugin, do housekeeping the respective tab, then switch it back on...

Hi all.
In case you have many forms in your existing Textpattern website and you are moving into flat file templates, here is a quick script to export all your forms from your database into flat files. This way, you avoid the "newfile-copy-paste-save-givename" dance :)

I've tested it in Linux. It will probably work on Mac and Windows too.

How to use it?

1. open a command line.
2. create and/or navigate to some empty folder (it could be your templates/forms folder)
3. run the python console (usually, you just have to type python).
4. run the following script.
5. profit!

import MySQLdb

db = MySQLdb.connect(host="", user="", passwd="", db="") # fill in with your database details
cursor = db.cursor()
sql = """SELECT * FROM txp_form"""
cursor.execute(sql)
forms = cursor.fetchall()
for form in forms:
    file = open(form[0]+'.'+form[1]+'.txp', "w")
    print>>file, form[2]
    file.close()
db.close()

The script is easily adaptable to export pages. And probably easy to export styles too. It won't work as is for sections or preferences, as it would require to transform the data into JSON format.

Edit: see below for scripts to export Pages, Styles, and Sections.

Hello,
I installed rah_flat on a local copy of Txp 457, using Mamp. Still I can't see any directory created, I'm using ../templates or ../../src/templates as destination path, and tried also to invoke the process using the secure key, which rendered {success: true}.
Tried also do create the folder myself, to no avail.
Thanks

Using this version of rah_flat I get the following warning on the front-end and admin area for each instance where there are no files in the respective templates subdirectory.

rah_flat -> Warning: Invalid argument supplied for foreach() on line 641

Again, more of an idea than an issue:

Apart from the fact that you've made a very tight and configurable plugin here, what attracted me to it is the potential possibility of managing smd_macro and rah_external_output code as files without using output_form trickery.

To start with I experimented with using rah_flat with smd_macro and have it working up to a point. I used a flat file export with “macro_name" as primary column and “definition" for the export. It works but you still need the interface to set the attributes (I guess xml format might be a better choice of format here) and more importantly to compile the resulting function on "save".

So, thinking aloud, might there be cases where it would be useful to trigger a function when rah_flat updates the database? In the case of smd_macro, it's not sufficient to only update the "definition" column, you also need to trigger the "code" column to be recompiled by smd_macro. Obviously, smd_macro (or the respective plugin) would need a corresponding function or callback that can be triggered.

I can imagine there might be other situations, for example a pretextiled html field (analogue to "body_html", "excerpt_html" etc.) that updates when the base field is updated...

Hi,
When I disable the plugin and navigate to the form tab, here is the error message I can see:

Internal error "Undefined index: files"

and

 Internal error "Undefined index: links"

Should I only use .misc forms?

Instead of truncate, run a delete command. Either before or after importing is done. Either all items, or those that weren't present in the repository.

This resolves importing downtime, and also allows us to lock the tables, reducing odd race condition artifacts. We basically want to lock tables while we are importing, to make sure other sessions wait us to finish.

Am using <disable_event>form</disable_event> in rah_flat.config.xml as per sample template and it works brilliantly. However, with adi_variables I get unexpected behaviour when calling up the "variables" pane.

Suspected reason: adi_variables uses has_privs($adi_variables_admin_privs) where $adi_variables_admin_privs = 'form'; to allow admin users extended editing rights. With rah_flat active the admin view of the variables pane is not visible. It seems that <disable_event>form</disable_event> also removes the privs.

Tested:

• If I remove the line <disable_event>form</disable_event> from rah_flat.config.xml, adi_variable works again but rah_flat no longer prevents access to the "presentation > forms" pane.
• If I change the privs in adi_variables to another privilege name with the same user privs combo e.g. $adi_variables_admin_privs = 'image.edit';, adi_variables works again alongside rah_flat.

The template pattern in FormIterator.php still contains the pattern for the type, thus preventing import of forms in sub-folders when no type is specified:

Removing \.[a-z0-9]{1,28} from the pattern resulting in:

protected $templateNamePattern = '/[a-z][a-z0-9_\-\.]{1,63}\.[a-z0-9]+/i';

makes it work as described in the docs.

I'm unsure of what format and file naming conventions are used for plugins (.json?)

Maybe adding a plugin directory with a dummy plugin would be beneficial here.