Blog Profile

[ryan]

I've been working on a blog profile that we can have as an installation option for ProcessWire. The goal is to have a profile that someone could download and setup a pretty nice website/blog without having to touch any code (i.e. it's ready-to-run and populate).

I'm hoping that this is something that may help us to grow our audience beyond the web development community. The requirement is that it must be as easy (or easier) than WordPress, both to install and use.

This profile is also for web developers, as it's a blog profile ready to be styled and enhanced -- a good starting point.

It uses the Zurb Foundation CSS framework, so it is fully responsive and mobile-ready.

It's not much to look at now, but should be fully functional. I'm making progress and wanted to post a preview. The content you see here is from one of my client's blogs and the content is just here to test things out.

http://processwire.com/blogtest/

I'm hoping to get this up on GitHub next week. I've never really done much blogging, so am seeking feedback on what others would suggest to make the blog profile as good, powerful and simple as it can be. Right now it's pretty much a generic Zurb Foundation "look and feel", so it probably needs at least some color tweaks and integration of some masthead photo(s) or something.

[Soma]

Great work Ryan, already looking very good!

What do you plan for supporting themes?

[diogo]

Looks good! Would be nice to give it a PW look and feel.

I'm curious to see the inside

[renobird]

Awesome! Just plain awesome.

[apeisa]

This looks great! I need to start thinking about building a tiny shop profile.

One note though: while browsing with android phone, the site feels little slow. I would guess it is the use of those CSS gradients on big post elements.

[teppo]

Awesome! Seems like you've got all the important stuff implemented already, but just a quick question: are you planning to add trackback support / is it already supported?

Also, there's something strange going on with comments; if you leave a comment which contains errors (might consider explaining what exactly went wrong, by the way - "there were errors" isn't very informative, especially since required fields are not clearly pointed out) it seems to break the browsers back button. This happens at least with Chrome. Not a big problem, but a bit annoying still.

[Marty Walker]

Really looking forward to picking through this.

[ryan]

Thanks for the feedback everyone.

@Soma: I'd like to support themes, but not really sure how since /site/templates/ pretty much is the theme. I may end up moving some of it to a module so that the theme aspects can be better isolated, but not sure it's the best way to go. I've taken a different approach with the development of this to maximize markup reusability. I'll be curious to have some more eyes on this and see what you guys think is the best way to maximize the flexibility too.

@Apeisa: I didn't observe this issue in iOS, but unfortunately I didn't have any other mobile devices to test with. I'm trying to get the profile to be as good of a starting point as possible, so am removing most Foundation-specific classes that are stylistic in any way, so those gradients will be gone in the next version you see.

@Teppo: Trackback support isn't there now, but sounds like a good idea for the future. I don't know how to implement it at present (and have never used them), so will do more research. The blockage of the back button is intentional to prevent double posts and allow for potential single-use validation keys. However, the form should have everything they entered in it without them having to click back. Though if they enter an invalid email address, it'll remove it. Error messages have never been comprehensive here, but will be improved as upgrades are made to the Comments field, separate from the blog profile.

Thanks,

Ryan

[DaveP]

Just to add that this is really good - I love the plain look of Foundation.

I'd like to support themes, but not really sure how since /site/templates/ pretty much is the theme.

Totally agree. Maybe anyone out there with a bit of time on their hands should have a go at creating a new /site/templates/ for this blog profile, which would effectively be a new theme.

Oh, and http://phptrackback.sourceforge.net/ may help with trackback support. B)

[Soma]

Maybe a well build html structure that suites well for theming only through CSS. Like zen garden.

[ryan]

Here's the first version of the blog site profile. I was wondering if anyone could help me test? To install, download a brand-new copy of ProcessWire (it must be the latest commit). Then remove the 'site-default' directory that it comes with, and replace it with the one in the attached zip file. Then load in your browser to begin installation as normal.

Edit: see this message for the latest version.

Thanks,

Ryan

[teppo]

Downloading now, will comment after testing

[apeisa]

Very nice job Ryan! I like it a lot!

Few notices:

• Maybe add real sidemenu for normal pages (I love the categories main page!)? Currently subpages available only through drop down, which will cause some accessibility challenges.
  
• Edit this page -link on sidemenu doesn't work
  
• Error Call to a member function findPosts() on a non-object (line 13 of /srv/www/pw/pwblog/site/templates/widget-recent-posts.php) when I try to view widget directly.
  
• public function headline($text) {
  return "<h1>$text</h2>";
  }
  

Few ideas:

• I don't like the way image gallery is embedded. a) It's in english B) it is easy to make mistakes. Maybe use checkbox instead? Of course we lose some flexibility that way.. but this is more of an issue how deeply integrate tinymce or to build something better to replace it...
  
• It would be great to have comments editable directly on post view!
  

About the intended audience:

There are quite a lot of markupClasses and stuff like that, which look like interesting and will definitely help maintaining the code. But for beginner they might look & feel a little bit scary and definitely makes this harder to grasp than demo profile. I think part of the "easiness" of Wordpress and the like is their "messiness" and how straightforward they are. Currently if you just open the "post.php" file you cannot directly there say how to edit the post view (say to change <h2> to <h1> from post title). You need to open /blog/init.php next. There you definitely cannot say where the code comes. Next you might open the BlogOutput.php.. no luck. Then maybe BlogMarkup.php.. this might be it, but you don't find any easy big bunch of html from there either...

I am not totally sure if I understand the intended audience right though: if this is example how flexible PW is as a framework and how to build a blog-software using it (and of course at the same time provide a great blog software using it) then this is brilliant way to go and I would keep pushing it in current direction. But if this is intended as a starting point for any web developer to install and build upon.. then I think some approach between this blog and current default site might be best way to go.

I don't want to sound nagging, but wanted to share my honest feedback. And after playing with this a little more I probably have totally different opinions

This is very polished and great work Ryan! Eager to see much more pw-powered blogs out there!

[SiNNuT]

Haven't got a lot of time atm but i did install it and had a look at the look, feel and functionality on the front-end and a (very) quick browse on the admin side and the codebase. I LIKE IT!

Being pretty (uhm very) limited coding-wise, i was able to build sites learning from the default site profile, the forum, PW api and learning some PHP along the way.

From the quick look i had i do feel that i can learn a lot of new stuff from the blog-profile. I think that this applies to a lot of PW users, who know the basics but struggle to take the next step.

Looking forward to diving in and testing when time allows.

[ryan]

Thanks for testing Apeisa and Sinnut. Right now the intended audience is us, as you might guess from the included blog entries. But once everything is worked out with it, the intended audience is folks that want to write blog entries and don't know how to do any development. That's the audience that we have no connection with at all right now, but is WordPress's biggest audience. I'm not too worried about this audience understanding the PHP side of it, because I want to make it technically unnecessary for them to have to do anything at that level. But in order to best support that audience, I also think there needs to be some abstraction on the code side.

I did start out with a structure a lot more like the basic profile. But after working with it a bit, decided to build this in the best and most efficient way I knew how. We're already covering the basics in the default site profile, but don't have anything out there that shows how to build something for larger scale. While this isn't particularly large scale, I decided to approach the profile from a development perspective in the same way I'd approach a site I'm building for a client. Though I'll usually bundle some of this stuff into modules, distancing it from the site templates. I may still do that, but still debating the merits of it in this case.

Another factor here is that I wanted to support really easy theme-ability, where you'd never have to make the same change in more than one place. If you want to make this thing run on Twitter Bootstrap rather than Zurb Foundation, all you need to do is replace a few classnames at the top of the file (in the constructor). If you want to make all images follow HTML(5) rather than XHTML syntax, then you only need to change it in one place, and so on for any tag. I didn't want to commit 100% to one CSS framework over another, so trying to keep some things abstracted here so I could swap in another framework without having to change the code.

For the sidebar widgets, I'm thinking about taking a module approach for those rather than a template one. That way people could install a new widget (as a module) in one shot rather than having to add a template, add fields to it, and create a page for it.

[diogo]

I tested it and I like it so far! I wouldn't consider it a finished product, but I don't think that's intended by Ryan at this point.

Some first thoughts (there will be more for sure later):

• Would be nice to have a "write" page on the navigation. This could be simply a link to a new blog post.
  
• A settings page. A place where people can change the color of the titles and links from blue to whatever they want, and also the typeface maybe. I would keep the customization to a minimum, though. This would imply having some dynamic style, and could make it more difficult for a "zen garden" kind of thing, of course.
  
• Changing the "edit" link on the corner by something like " new post | manage "
  
• For the intended audience, I would avoid having words like "responsive" on the blog descripton
  

Hm, I think that's it for now.

[ryan]

Would be nice to have a "write" page on the navigation. This could be simply a link to a new blog post.

That's a good idea! And it's already there. But you have to be logged in to see it. See the sidebar, it says "create new blog post".

There are quite a lot of markupClasses and stuff like that, which look like interesting and will definitely help maintaining the code. But for beginner they might look & feel a little bit scary and definitely makes this harder to grasp than demo profile. I think part of the "easiness" of Wordpress and the like is their "messiness" and how straightforward they ar

You always have great suggestions, but sometimes it takes me awhile to get it. After sleeping on it and thinking more on the intended audience here and want it to be as broad as possible. So while I want this to be something that people don't have to touch any code, I also don't want to introduce any unnecessary barriers for people that do. Given what you've suggested, I'm thinking I will tear into it and make it less nice on the code side, but simpler for someone to figure out without having to invest much time in it. Here's the strategy:

$markup, $output and $blog will get moved into 1 API variable just called $blog. That API variable will be moved to a module and won't be something that people ever have to look at the code for. The functions in it are:

findPosts($selector)
getPost($selector)
findComments($selector)
findRecentComments($limit)

setOutput('content|sidebar|whatever', $value)

renderPosts($posts)
renderComments($comments)
renderCategories($categories)
renderSubnav($items)
renderArchives($year)
renderAuthor($author)
renderWidgets($widgets)
render() // main

Rather than having the Markup class, all those render functions map to PHP "views":

renderPosts() uses view file: /site/templates/blog/posts.php

renderComments() uses view file: /site/templates/blog/comments.php

...and so on:

subnav.php

archives.php

author.php

widgets.php

main.php

Those view files are basically like WordPress templates. Though with no classes, functions or logic. Just markup, loops and variables. The render functions figure out the logic and then just hand the views data that's ready to be output. Not quite as flexible as before (though still flexible), but there's nothing to figure out, so I like that.

The template files in /site/templates/ will remain largely the same, other than that they'll be calling on $blog rather than $markup and $output like they are now.

What I think this leaves us with is a minor compromise, though one that has a much lower development barrier to entry. People can get in there and adjust the markup output without having to know anything about the system. So I think it's a good compromise. Structurally I think it may be better too because it's much easier to see the scope of a theme: the entire /templates/ dir (and other dirs in it) is it.

This setup is kind of similar to the approach some of us use in having common render functions as modules. Like having a PageArray::renderVillas() that is used by multiple template files. The main difference here is that the render() functions are taking care of any needed logic and then letting really simple "view" files handle generating the actual output. So now the "theme" has good separation and hopefully encourages people to create new themes. It's not an approach I'd use on one of my projects, but it should be a perfect approach for this blog and encouraging people to customize it.

[AnotherAndrew]

Diogo beat me to it. But I will reiterate one of his comments

A settings page. A place where people can change the color of the titles and links from blue to whatever they want, and also the typeface maybe. I would keep the customization to a minimum, though. This would imply having some dynamic style, and could make it more difficult for a "zen garden" kind of thing, of course.

I think this is what make wordpress so attractive for many people who can't code. They can download a wordpress theme and if it supports customization then they can easily change out header images, fonts, text color.

[apeisa]

Ryan: I like your plan, sounds much easier approach to start learning and build upon.

[SiNNuT]

Ryan: I also like your plan. I had some time to take a look at the code of your first version. Although it is very nice to see how you approach and build this stuff it also pretty hard to figure out what's going on with the output and markup classes. But i will definitely keep the zip for further study.

Looking forward to the next version.

[ryan]

I have the next version ready. I just need to export the profile and double check it all works. I hope to be able to post it later today after getting through some client work.

[ryan]

Here's the next version of the Blog Profile. This one incorporates the simpler structure I mentioned earlier, exactly as outlined. Please let me know how it works for you.

To install, download a fresh copy of ProcessWire and replace the /site-default/ directory it comes with, with the one in the attached zip: blog-site2.zip

Thanks,

Ryan

[JeffS]

@ryan - Thanks for this. I was just cruising the code and noticed you used foundation css and was just in the process of coding the menu for a new site (migration from MODx Evo) using foundation. I now owe you a

$drink = "Payment for ./blog/topnav.php";

.

We will give your PW Blog profile a spin over here. Looks nice.

Quick question? How would you approach adding a blog section to en existing PW install using this?

[ryan]

This is intended as an installation profile, so not something that is ready to plug into an existing installation. Though you could certainly copy the templates, install the BlogAPI module, and re-create the fields and pages it uses in an existing install. Though I do plan to make the BlogAPI module installable, so that it can install everything needed by the profile into an existing site. But going to wait till the profile is pretty well nailed down before doing that-- it shouldn't be far off.

Also an update about the profile: the next version is going to be running on the Skeleton responsive framework instead. I'm just finding that framework to be a little better for the blog profile. However, I'll still include the Foundation template and CSS file as optional, so that you can still use the Foundation version if you prefer it.

[porl]

This is looking really interesting, thanks!

As others have mentioned, I think there are many of us that could learn from the way you would approach making a site for your clients. Is there any chance of another profile down the track that uses more of your 'tried and true' methodologies? Obviously I don't expect you to drop everything and start churning out code right away but I am sure I am not the only one that would love to see how 'The Creator' uses his own tools