You are not logged in.
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?
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)
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:
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.
TXP Builders – finely-crafted code, design and txp
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:
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)
a) rvm_css (for static serving of stylesheets)
b) smd_where_used (to help me locate stuff I’m bound to lose later)
c) rvm_maintenance (for sticking up a nice “under construction” message)
#2 Ditch the default page template and replace with a layout like this:
<txp:output_form form="dtd" />
<txp:hide> Contains a series of sub-forms for meta, page title, css, scripts, etc </txp:hide> <txp:output_form form="head" />
<body id="<txp:if_section name="">front<txp:else /><txp:section /></txp:if_section>"> <div id="container">
<txp:hide> Banner stuff </txp:hide> <txp:output_form form="pagehead" />
<txp:hide> Category / Section / Search landing page and/or individual <txp:article> tags </txp:hide>
</div><!-- end content --> <txp:output_form form="pagefoot" />
</div><!-- end container --> <txp:output_form form="piwik" /> </body> </html>
#3 Delete the crappy forms that are of no interest / use and write the relevant form content to suit the above template
#4 install other plugins to help with the site in hand — this depends on the type of site but will often include:
a) adi_gps (for capturing URL variables easily)
b) smd_if (for extreme branching capabilities)
c) smd_thumbnail (if I need more than one size of thumbnail or a gallery) — and smd_gallery occasionally, although after Txp 4.3.0 this plugin’s usefuless has diminished a lot, yay!
d) yab_shop for e-commerce (with smd_ipn if the client wants business logic updated on successful PayPal payment)
#5 Coming up with inventive ways to link articles, images and files that the client can understand given their experience with CMSs, publishing workflow, or computers in general. This may involve some cunning use of plugins, or custom code to write a suitable dashboard (smd_tabber) and/or macros (smd_macro)
#6 Theme the admin side to taste — thank heavens for textgarden.org, the community for writing them, and smd_admin_themes to put them in action!
#7 Customisation of the admin-side to turn off as much irrelevant clutter as possible — these days using a combination of smd_user_manager (for priv/role management) bot_wtc (for reconfiguring the Write tab) or some custom code if necessary
#8 Set up visitor tracking: I now tend to use (an often centralised installation of) piwik because its upgrade script rocks and it’s often quicker to hop to a local server than wait for an http connection to Google Analytics
#9 Add zem_contact_reborn if a client wants a contact form and integrate it with any other data capture they may require (an smd_bio/mem_form combo for example)
#10 If I’m feeling lazy or hate the cpanel implementation I will often install rss_admin_db_manager so I can keep tabs on the database and make backups
Last edited by Bloke (2011-07-24 19:38:17)
One question pops into mind regarding some of the responses so far: How much will some of these things be moot points in future versions of Txp? For example, we know people don’t like/use the “lofi” form, and we know Phil Wareham is working on a new default template, etc. Thus we can assume that there will be changes in the not distant future. Right?
I’m just wondering if there should be a time dimension on this 10 things selection too…ruling out what eventually won’t be a problem anyway.
After thinking on design (on paper sketchs), opening my favourite editor (coda where I can use my custom clips), my method is very similar to Stef one: same forms, same king of page, same plugins :)
Speaking of the new template… I have an idea for another series of docs (something new to the wiki) that will help people build and integrate custom themes, which will be written with respect to Phil’s new template, related plugins…whatever and as much of the best practice advice we can give.
I also see this being a good place to introduce docs that cover advanced designer workflows, like what Julian was getting at, and maybe things like rvm_css, etc tie-into this too.
So, you see, it’s not cut and dried with just 10 tutorials. Documentation is contextual in many directions and we can use that in a variety of ways/places.
Last edited by Destry (2011-07-24 20:12:36)
From Rick Silletti via Facebook…
Though I am currently not working on anything, what seems always to come to the forefront with most projects is smd_calendar and all that it does.
<txp:output_form form="header" />
<div id="primary"> <div id="content" role="main">
<txp:variable name="task" value="frontpage" />
<txp:variable name="task" value="category" />
<txp:variable name="task" value="search" />
<txp:variable name="task" value="author" />
<txp:output_form form='task-<txp:variable name="task" />' />
</div><!-- #content --> </div><!-- #primary -->
<txp:output_form form="sidebar" />
<txp:output_form form="footer" />