[wiki] What are the 10 most frequently needed developments in a Txp site?

maniqui · 2011-07-23 16:14:08

I once loved the “everything is saved in the DB so it makes it easy to migrate/upgrade” philosophy/feature.
But now, I find that I couldn’t work without cnk_versioning. It creates files for every form, page and CSS (although I don’t use anymore any of the built-in CSS functionalities), enabling developers to use a code editor.
Also related, I don’t install plugins on the DB (well, only if it’s a new plugin that I’ve yet to export as a .php file, using ied_plugin_composer), but run them from the plugin cache dir.

This two changes in the way I use TXP enables easier teamworking, as it also enables you to work with a SCM like SVN, Hg or Git.

On top of this, I don’t use anymore the “single install” method for a TXP website. I’ve bended/hacked a little the multi-site install process, to “detach” a Textpattern-powered website from the /textpattern-x.y.z/sites/ folder, and “attach” it again via a symlink. I do the same for the plugin cache dir. I’ve a huge collection of plugins, all stored on the same folder, and “attach” it to a Textpattern install via a some symlink daisychaining.
This enables to have different repositories for: Textpattern, the plugins (where different versions of the same plugin coexists), and the websites, and “tie” them all via just a few symlinks.
This way, upgrading Textpattern or upgrading a plugin is just a matter of changing a symlink.

This kind of setup really pays off on a development environment (where you need to setup a few TXP websites) or when you host multiple TXP website on the same server (ie. if you provide hosting to your clients), or when you have to setup a production and stage/dev environment next to the other.
And if you use git new-workdir, the sky is the limit: you can have coexisting working directories (i.e. different tags/branches checked out at the same time), checked out from the same repository, without needing to re-clone/copy the repo. In other words, you can have all TXP versions sitting each next to the other, and all tied to the same repository.

I know all this sounds a bit complex, but it’s not, really. There are a few more details here, but I should have write this down properly… someday.
Well, to be sincere, I think I should first ask to pieman, Gocom, Bloke and jakob, who may have “suffered” working with this kind of setup. :)
Hope this isn’t too off-topic. Is it, Destry?.

jakob · 2011-07-23 16:18:41

The other main reason for using a contact form over an email address is to collect certain – or structured – information that may be needed to deal with an enquiry.

Gocom · 2011-07-23 16:49:36

Contact form also adds layer of security as it doesn’t reveal the email address to everyone. Usually you will want to keep your email addresses the same, intact for several years (or at least so that it redirects to correct location to not cause any confusion to your contacts), and revealing it would make it easy spam magnet.

Contact form also easily allows saving the sent messages to somewhere else. For example if you have a contact form with a subject option Bug report or Security, the sent message can be saved to bug tracker or staff’s high priority to-do list.

Destry · 2011-07-23 17:33:44

Pete, Jakob, Gocom,

I agree with the “structured” idea of collecting data, or redirecting certain inquiries to a particular locations/person (though this works just as well, and is not a form). But aside from that, there’s a lot of usability and accessibility argument in favor of not having a form. I certainly wouldn’t say having a form is an improvement to UX (no offense, Pete). Also, forms can be a problem with security as much as they try and fix it.

An enkoded email address can not be scraped by bots (like a raw email address can), and I doubt spammers are manually taking note of enkoded addresses that show up in the browser’s “destination” hover when an email link is hovered on (which they would even have to write down by hand to record it).

Using a plugin for a contant form is a lot of setup/overhead to maintain where it’s often not needed. If a project needs it to structure input, that’s one thing, but to use it as a substitue for general contact…maybe that’s unnecessary code to worry about?

I’m not arguing the validity of contact forms, per se, I’m just exploring the notion that having a top ten tutorial on it might perpetuate over-reliance on having one when not always needed?

(Personally, I rank contact forms in there with blog comments…they are not a must-have feature. But, don’t worry, I’m not letting that get in the way here.)

Last edited by Destry (2011-07-23 17:39:35)

Gocom · 2011-07-23 17:38:26

Destry wrote:

An enkoded email address can not be scraped by bots (like a raw email address can), and I doubt spammers are manually taking note of enkoded addresses that show up in the browser’s “destination” hover when an email link is hovered on (which they would even have to write down by hand to record it).

What your browser can encode, anyone else can encode. Encoding isn’t one way and doesn’t protect it from spam bots other than some. It’s only measurement to reduce spam, not to protect the address.

Last edited by Gocom (2011-07-23 17:41:04)

Destry · 2011-07-23 17:43:34

Gocom – I’m talking about Enkoder as an encoding method. Is that different from browser encoding?

gaekwad · 2011-07-23 17:47:56

Destry wrote:

(no offense, Pete)

Too late. I am offended. I’ll be in my trailer :)

Is it ultimately down to personal choice? I think it is. There are compelling arguments for having a feedback/comment form, and there are compelling arguments for having an obfuscated/obscured email link. Some people like forms, some like email. I would go so far as to say that if a Textpattern instance was running a blog-style section, and had comments enabled (and they were being used), then a feedback form would be preferred to an email address. That said, there are folks who have a contact page with their email address stashed somewhere inside it. The idea behind a website which invites comment is to make those avenues available to promote engagement with the user – the feedback or comment being the conversion in this case, and anything that prevents them doing it, no matter how small, may send visitors away.

In my former life I used to work for Sophos and have a better-than-average knowledge of email harvesting. Spammers are generally either ruthless or lazy, in my experience – where there’s a will, there’s a way.

PS: I wasn’t really offended. Honestly.

Last edited by gaekwad (2011-07-23 18:01:54)

Gocom · 2011-07-23 17:49:33

Destry wrote:

Gocom – I’m talking about Enkoder as an encoding method. Is that different from browser encoding?

What your browser can decode, anyone can decode and encode. Encoding and decoding are two way. Everyone sees your email address, it isn’t protected. It’s encoded to reduce spam, not to make your email invisible.

For example, in case Enkoder, your email address will be stored publicly visible in JavaScript code. Anyone that runs the JavaScript code or reverses the obfuscated code, including bots that have JavaScript capability, will see the address as it’s only encoded.

Encoding works, but it’s not a security feature to keep the address private as a contact form is. It’s way to reduce spam.

Destry · 2011-07-23 18:04:52

Okay. Cool. Useful conversation, guys. Thanks.

Everyone else…back to the task at hand. What are you’re top developments when building websites with Txp?

Dragondz · 2011-07-24 08:41:09

Hi

In my workflow i code template and CSS by hand then put it into Textpattern and make changes into it.

A reset button of the install (erase dummy information: comments, articles, category, …) can save me 10mn in each install

i usually use a sql dump to put about 10 plugins in each install then enable what i need (allways use: zem_contact_reborn, upm_insert_tab, rss_admin_db_manager, adi_gps)

Cheers

jakob · 2011-07-24 14:20:03

Something that’s coming out of all the above is that the typical next steps very much depend on the kind of site you are making, and perhaps also whether it’s for one’s own use (or own management) or is to be used by others. The current standard template is a self-publishing oriented blog-type template, so most people who are building a different kind of site, particularly those with good txp experience, will scrub (parts of) their installation and start over with a new template, whether self-built, a css-reset or a txp-ised html boilerplate.

At txpbuilders we have some basic “framework” templates that don’t purport to be full templates but can serve as a starting point for certain types of sites (e.g. portfolio site, gallery slideshows, tumblelog-style sites…). Jonathan’s (jstubbs) been working them up in his spare time so they may be released at some point.

If you’re looking to create a set of “what now?” springboard articles for typical development tasks, maybe txptips (and some of the more “How do I?” oriented FAQ articles) is a good source for identifying typical topics. It is arguably also a good repository for this kind of knowledge, especially where plugins are concerned as they are not part of the core and are constantly in flux. Txptips shows clearly that many roads lead to Rome and that “how do I do a menu navigation” has at least as many answers as there are different kinds of menus. Maybe it would be an idea to hook up your tutorial idea to some of the categories on txptips.

What is commonly needed on many sites regardless of type is:

menu + page navigation (sometimes with different article sorting schemes)
feedback/contact possibility (whether blog comment form, contact form or email)
search facility (in differing levels of complexity depending on site needs)
article-based or image-based gallery
meta data (rah_meta or custom solution)
stats package integration
google sitemap (rah_sitemap or custom solution)
rss (depending on site needs/site structure, standard or custom solution)

I agree with what Jukka wrote about a “blank canvas” and like maniqui and others I routinely now use cnk_versioning even when not using a versioning system or working with others, which means that I do not use most of the “Presentation” tab anymore. For client sites I definitely use the image, files and links pane. Like everyone else above I simplify the write tab, sometimes radically, and I also provide basic task-oriented instructions as well as redbot’s write tab tooltips.

BTW: the setup maniqui mentioned sounds mind-boggling at first but it really is the bee’s knees when used with versioning and for developers who need a framework from which to develop and host multiple txp sites. It’s not beginners territory, though.

@Pete: I used Coda too for a long while when developing static sites. You might want to investigate Espresso because it gives you very similar text editing and project organisation facilities to Coda and a separate preview pane that can show another page (e.g. your live local site while you work on the template code). In the current v2 beta (still a bit buggy unfortunately), CSSedit has been integrated into the preview pane, changing the address bar into a DOM-walker (pretty much obviating the need for xyle scope). If you use a dedicated css file (or css via versioning) you can live edit the css too. The preview pane is webkit-based so you have access to the webkit web inspector too if you want to track down css overrides or watch how js alters your code or logs to the console. Like Coda you can selectively publish to an online server, so if you use cnk_versioning you can develop on your local server to your heart’s content, then push the template file(s) to the online site and update that accordingly.

Destry · 2011-07-24 19:23:48

Jakob…yep.

I intentionally started this out a bit vague as an exercise to see what feedback people would give (I’m collecting from 3 channels, btw; via Facebook, G+, and and this thread). I anticipated there would be, at least, two kinds of feedback against what I was asking for:

that which was more or less on target (e.g., Zanza and Jakob’s lists), and
that which fell into more advanced territory (e.g., Julian’s feedback).

Thus I expected the potential for breaking things down for ~~designer and client~~ veteran and newbie audiences, but I didn’t want to get overly specific in the beginning.

I also expected people to mention build objectives that required plugins, and that was fine. It’s just not realistic to think anybody is going to build (or have a site built for them) without any plugins at all. For that reason, documentation should not be void of plugin solutions anymore, even if that was the aim of the user docs in 2004. It’s not good user documentation if it’s not bridging the two sides where people inevitably go. This also helps bridge content between .net and .org sites, particularly when .org is redone.

What I didn’t expect were the functional/feature requests (what Txp can’t do with or without plugins), or people just saying what plugins they installed without explaining why. Neither is particularly helpful in this instance. But I take the hit on that because my initial request was pretty vague. So I made a couple of clarifications in the head post, and along the way too.

Most ideas put forth are what I would call advanced. While I can appreciate what a veteran’s personal workflow is for dev or design, that wasn’t really the desired info, but it has been very interesting nonetheless. And that’s the great thing about user research (however informal), you learn some useful things you didn’t expect.

This may not go anywhere, in fact. It’s only an exercise. If I don’t see enough similarity in responses, there won’t be any point trying to make something of it. TXP Tips is a great site, and I did have TXP Tips in mind (just one example); they would be looked at later after having a solid list of 10 things to work with. The list isn’t there yet. Also, sometimes I think tips could be edited better, and if I had a solid 10 things to focus on, that would be the objective: writing 10 modern tutorials based on info that exists and giving credit where due.

So we’ll see. Nobody is losing any skin of their tush by offering their 2 bits. Even if it doesn’t result in anything.

Last edited by Destry (2011-07-24 20:18:36)

Textpattern CMS

Textpattern CMS support forum

#13 2011-07-23 16:14:08

Re: [wiki] What are the 10 most frequently needed developments in a Txp site?

#14 2011-07-23 16:18:41

Re: [wiki] What are the 10 most frequently needed developments in a Txp site?

#15 2011-07-23 16:49:36

Re: [wiki] What are the 10 most frequently needed developments in a Txp site?

#16 2011-07-23 17:33:44

Re: [wiki] What are the 10 most frequently needed developments in a Txp site?

#17 2011-07-23 17:38:26

Re: [wiki] What are the 10 most frequently needed developments in a Txp site?

#18 2011-07-23 17:43:34

Re: [wiki] What are the 10 most frequently needed developments in a Txp site?

#19 2011-07-23 17:47:56

Re: [wiki] What are the 10 most frequently needed developments in a Txp site?

#20 2011-07-23 17:49:33

Re: [wiki] What are the 10 most frequently needed developments in a Txp site?

#21 2011-07-23 18:04:52

Re: [wiki] What are the 10 most frequently needed developments in a Txp site?

#22 2011-07-24 08:41:09

Re: [wiki] What are the 10 most frequently needed developments in a Txp site?

#23 2011-07-24 14:20:03

Re: [wiki] What are the 10 most frequently needed developments in a Txp site?

#24 2011-07-24 19:23:48

Re: [wiki] What are the 10 most frequently needed developments in a Txp site?

Board footer