[wp-hackers] GSoC - easier integration of websites as themes

[Your neighborhood Dukebag]

Hey there,

 

If I understand what you've said correctly, you're referring to the numerous
loop-related theme files (e.g. category.php, tag.php, single.php).

 

Default generation is definitely an involved question, i.e. when the user
uses no-code to generate a theme without specifying anything.  The answer is
mostly speculative at this point.  With specific regard to your question,
users could be forced to at least provide enough information to accommodate
the basic loop pages, as shown here:
http://codex.wordpress.org/images/1/18/Template_Hierarchy.png.  From the
design perspective, this would mean designing 3 alternate views, though it
sounds possible to default to only need index.php (1 static page, no posts).
Below is some further material from the doc I drafted.

 

Determining a best-case default
Some features/controls are more esoteric than article titles.  How does a
user denote a page as a page?  How does a user control conditional features?
Should no-code require certain information/fields to be populated in order
to generate a theme?  If so, what is the bare minimum?  Does it make most
sense to provide no-code users with a "model page" which they emulate or
allow any format? 

Users may benefit from lists of what WordPress functionality is available to
them.  Additionally, WordPress functionality can be categorized and
associated with what the user is currently doing.  For instance, if the user
has text-level elements highlighted, no-code can offer article-related
functions.  If the user selects an element as the sidebar and then
highlights child elements of the sidebar, no-code can offer sidebar-related
functions.

 

HTML/CSS selection
HTML/CSS are tricky beasts, so even if the user's mouse is highlighted over
what they believe is an h2 element, the bounding box may be elsewhere on the
page (or even way off the page).  In cases such as these and other, equally
unforeseeable cases, supporting feedback can be given to the user: e.g. "You
have selected div#page".  Identifiable information can be appended the
element.  Alternatively, the selected element can be highlighted (who likes
reading, anyhow).  Dragonfly and Firebug are excellent models to work with
in this regard.

What if the user gets stuck in a situation where they continually want to
highlight what will be their comments HTML/CSS, whereby some obnoxious
z-indexing makes them have to click in an awkward manner?  Perhaps some
controls could be offered such as "lock to this element and all child
elements".

 

Latching JavaScript onto arbitrary HTML/designs
This could get complicated.  no-code already intends to make Theme
Development readily accessible, though it may be a non-goal to accommodate
non-savvy developers.  For instance, PHP could load the web design via
include, latching on JavaScript in the process.  This would be handled by a
separate user-upload and the user directing WordPress to a same-domain URL.
Alternatively, and slightly trickier, WordPress could automate this by
accepting a file upload.  This may be another matter of scalability, at
which no-code still performs the basic benefits while planning to extend its
usability over time.

 

What if the user changes their mind?
In the middle of naming the block of text "Next Post" the link that points
to the next post, what if the user decides they want it to read "Next Post
>>"?  The goal of no-code is to minimize the amount of extra steps between
designing a web page and integrating with WordPress, so no-code should aim
to do more than reverse that process.