Using TXP for managing directory listings

tcgra · 2009-11-04 20:32:56

Hi All,

Brand new TXP user here. I work for a one of the colleges at a large institution and have been tasked with revamping our outdated alumni directory listing. Currently, it uses a perl script to retrieve and display search queries for alumni records. It is truly a pain, as records must be manually added into a .txt file.

The 2 main goals I have in mind are:

1) Implementing TXP into our current site template and allowing users to browse/search the directory
2) Allowing users to submit new alumni entries via a form to TXP that are added upon approval

Could anyone offer any helpful resources to get this rolling?

Gocom · 2009-11-04 21:48:58

Textpattern isn’t exactly a thing that you can call a file browser. Tho, if you have a good reason why you are using TXP with a directory listing, you can of course use a PHP file browser script or write your own little thingy that is a thing that you might call a file browser — blurb.

There ain’t any TXP plugins that I’m aware of that are for that purpose, but building a really simple file browser requires only just around 10 lines of code; fopen, some while loop, and html to link the file.

Some good simple examples in:
PHP.net / Manual / opendir()

whaleen · 2009-11-04 22:00:50

Maybe you can process the txt file into a spreadsheet and then each row (person) into TXP articles in a Textpattern Section called alumni. I personally would attempt to break that file apart into individual things for each person. You’d abandon that old file in the end and have all Alumni stored elsewhere.

You could go further and make each person a user/author whereby other departments could hook into your system to give alumni publishing powers if needed. Look at the user privileges setup TXP provides.

A directory of user/authors in TXP is possible to set-up as a searchable listing as well as is a section full of articles, one per each person.

I expect you’ll get a lot of response on this thread. :) I hope so.

whaleen · 2009-11-04 23:44:50

I expect you’ll get a lot of response on this thread. :) I hope so.

Maybe not. I’d be interested to know what you end up doing.

Bloke · 2009-11-05 00:20:21

fwiw, I’d go with either of whaleen’s solutions. The approach depends on what you want your alumnees(?!) to get out of the system:

if it’s just for some user base to be able to find people’s bio info then saving each person as a TXP article in a dedicated TXP section makes a lot of sense. There’s a brief tutorial on that. TXP’s custom fields can be used to store additional bits of info about each person (e.g. their department, title, contact details, etc)
if you want your alumnees in the long term to be able to log in and post stuff then you’ll need to create them as users in TXP with appropriate rights, as whaleen said. Since the core fields for holding user data are somewhat limited here (pretty much just a name and e-mail address), you can use the smd_bio plugin to extend that and store unlimited additional bits of info about each person

Setting up a directory of people using either method is then just a case of fiddling with the TXP article tags (for option 1) or smd_bio’s flexitag to display various bits of info.

Searching and filtering the lists is also fairly easy (moreso with option 1) though the catch-all smd_query can always leap to the rescue for those hard-to-reach corners of the database.

But before you do all that there’s the arduous task of prepping the data into a format suitable for import. If you go with option 1 and can transform your .txt file into a usable comma-separated format (perhaps via spreadsheet as whaleen said) then the jmd_csv plugin might save you some graft. There’s also the ‘Import’ facility in TXP which, although primarily of use for bringing in articles from other CMSs, might bear fruit if your data format happens to closely resemble something from another CMS.

Batch importing under option 2 will probably require some SQL ninja work I’m afraid.

speeke · 2009-11-07 03:28:09

I’m interested in this thread because I have a site I’m thinking of moving to Textpattern.

Basically it is a product directory. It offers free listings to businesses (after approval), so there needs to be a custom html form set up to allow them to input the required data (text and images). Stef, would smd_query be needed for this (I’ve had a look at Txp’s MySQL database and it appears as though the only (?) table that needs updating is textpattern).

They would need to login to add/modify/delete content (but only their own). I’m guessing the role of Staff Writer (4) (in user permissions) would be ideal ???

The whole site should then be searchable (including glz_custom_fields and smd_bio plugin fields.).

Are there any other considerations/helpful hints experienced Txp users have, in addition to those listed above?

Last edited by speeke (2009-11-07 03:29:14)

jakob · 2009-11-07 07:42:50

Yes, you can, of course, use the standard textpattern articles with a bevy of custom fields to organise the information. smd_bio is really conceived for textpattern authors to write a profile about themselves so textpattern articles would be better for a product directory. If you use textpattern articles you can use the standard txp tags to output information. One way or the other, you’ll want to consider how your directory needs searching early on in the setup and how you’ll realise it as that can be a deal-maker/breaker.

Stef’s suggestion of using jmd_csv is probably the way to go when importing data the first time. For later submissions you have a number of options:

backend editing rights: provide restricted txp backend access (e.g. staff writer) plus instructions. They also see all other entries in your site, though. This is least comfortable for the user but also least work for you.
If you need just submissions and they don’t need to be edited by the submitter at a later date, try mem_moderation and mem_moderation_article, with which you can create a front end form that allows users to submit their data in a structured way and passes it to a moderation queue. The site admin moderates the data before passing it directly to a textpattern article. Thereafter the entry can only be edited by the admin, so later amendments must be provided by mail. This is quite easy to implement but depending on how much you need to edit data later, it may add maintenance work further down the line.
If you need the submitter to be able to update their entry at a later date, you might want to try mem_public_article. You need to build a “client area”-type login mechanism around this with ign_password_protect (and maybe mem_self_register if you want people to be able self-register) so that they can see and edit only their own articles. This is ultimately most comfortable for the user but also most work for you.

speeke · 2009-11-07 10:09:21

jakob wrote:

One way or the other, you’ll want to consider how your directory needs searching early on in the setup and how you’ll realise it as that can be a deal-maker/breaker.

I agree. I have some very specific search criteria I would like to include that will hopefully make the directory easy to use. Are there any plugins you would recommend to help create an advanced search? Or would this be something I would have to hard code using MySQL statements to pull out the relevant information etc?

Thanks for all the other info, Jakob. I wouldn’t have known where to start to find out about these option/plugin combos. Very helpful indeed.

jakob · 2009-11-07 14:58:41

Txp brings a degree of flexibility out of the box but can’t handle a lot of multiple different criteria at once. When I last tried this glz_custom_fields allowed you to chain some different select boxes together for a multiple item query and was the most powerful option available (I’ve not used the most recent version yet so I don’t know if this has since changed). You can often get a workable solution by searching according to section and category and sorting by a third criteria. It’s worth thinking about how the search is likely to be used and whether it really needs to be as complex as one would like to design it – for example, you may find that 90% of the users will only need a few main queries.

Otherwise you may need to develop special mysql queries for some special cases and feed them through smd_query. You can do that by making your own search items in your search form that pass get variables (e.g. mydomain.com/search?section=xyz &filter=special) via the url. On your search results page you then use something like adi_gps or similar to retrieve the get variables. adi_gps is nice because it automatically makes a txp:variable for you and you can then use txp:if_variable to conditionally test for its existence. If you have a lot of criteria to test for and your nesting of txp:if_variable statements starts to get out of hand, there’s also smd_multi_choice for dealing with multiple ifs at once.

One thing you need to definitely watch out for if you build your own sql query-variants is to avoid a get variable going straight into your query or else you open up your database to security violations by people constructing their own queries. smd_query provides some filter mechanisms for filtering types of data (e.g. integer, string, etc.) and search and replacing out invalid stuff (see the plugin help) but ideally, if you know there are only certain allowed responses, you use if_variable to test for the allowed responses only first before building a query with smd_query.

Note that while smd_query is excellent in a tight corner, you lose the ability to use txp’s next/prev paging tools and any plugins that work with txp’s own paging system. If your output happens to be tabular (rows in an HTML table), you can use things like jquery datatables to provide similar functionality, though you always need to output your whole dataset for that. There may be other similar jquery plugins out there that don’t require the information to be in tabular form.

That’s all I can think of for the moment :-)

speeke · 2009-11-07 23:48:50

Once again, many thanks for your detailed reply, Jakob.

Textpattern CMS

Textpattern CMS support forum

#1 2009-11-04 20:32:56

Using TXP for managing directory listings

#2 2009-11-04 21:48:58

Re: Using TXP for managing directory listings

#3 2009-11-04 22:00:50

Re: Using TXP for managing directory listings

#4 2009-11-04 23:44:50

Re: Using TXP for managing directory listings

#5 2009-11-05 00:20:21

Re: Using TXP for managing directory listings

#6 2009-11-07 03:28:09

Re: Using TXP for managing directory listings

#7 2009-11-07 07:42:50

Re: Using TXP for managing directory listings

#8 2009-11-07 10:09:21

Re: Using TXP for managing directory listings

#9 2009-11-07 14:58:41

Re: Using TXP for managing directory listings

#10 2009-11-07 23:48:50

Re: Using TXP for managing directory listings

Board footer