Leaderboard

I like all the ideas. A own custom german build of PW would be great. Luis and me chatted about our idea. And we took also WordPress as an example. But our example is more wpde.org So some benefits of PW,blog (maybe with some tips and tricks), FAQ and something like Director-ee build in. We want to introduce freelancers and agencies who are using PW and want to tell WHY they are using it. So we will interview those who will be listed in this director-ee/network-section.

I think Joss is accountable roughly for half of that?…

The dumbed down 'dirty' approach is pretty much all I do! Seriously, it serves as a good point and one that most designers with low to moderate development capabilities (I'm firmly in that bracket) wil be comfortable with. In fact if you look at most of the code samples in WordPress theming and tutorials, inline coding is pretty much the accepted standard. This bracket of people must represent a large section of those looking to use a CMS. The fact that ProcessWire allows for this kind of approach and doesn't discriminate against it is a strong selling point in my view. I'm currently putting a profile together for a website that I might 'generalise' and share - full with inline code.

Thanks for the information Pete, good to know. I am guessing those assumptions are spot on.

half i wouldn't say, but if you count words instead of posts...

I thought it might be fun if everything translates into "WillyC speak" though?

See the htaccess file, there is a mention about ~ char.

There are two issues with the normal bootstrap menu: 1. It doesn't hover 2. The "parent" is not linkable (it is too busy doing the dropdown) So, here is the solution: http://cameronspear.com/blog/twitter-bootstrap-dropdown-on-hover-plugin/ Basically, this script replaces the data-toggle with data-hover Without the data-toggle, the parent becomes clickable and with the data-hover it now drops down on hover!! Magic!

Depends. Here's an example: I'm involved in the development of the Serendipity blog engine. While it's not technically a German project at all, our lead developer (“our Ryan”) is German, as are most of the contributing devs. Since Serendipity also has a lot of German users, it seemed reasonable to set up a German-only subforum on the user forum for those of them who are not confident in their English skills. So now we have quite a few German-only forum threads which “hide” valuable info from people who don't read German, although we usually encourage anyone to use the English subforums if at all possible. So while I think that a certain amount of local activity can be a good thing - basic localized information/documentation, a list of local users/developers etc. -, too much local activity can also lead to a fragmentation of the community. I would, e.g. not necessarily consider a “German PW forum” a good idea. Also, localized documentation is kind of cutting it both ways - while it's a good thing for people who don't read English properly, it is very hard to keep localized docs up to date. Just my 2 cents, though.

*whistle whistle whistle.....*

Love that idea The more local activity there is the better I think. And let's not forget that all of this will end up in search engines driving yet more relevant traffic our way.

Someone added 5,000 more posts in 2 months since WillyC posted this So... if traffic just stays the same we're looking at 30,000 posts a year? That's neat, but I think by the end of 2013 we might be a lot closer to the 100,000 mark than the 50,000 mark.

I hadn't noticed that - in case others missed it, you can read about it here: http://processwire.com/talk/topic/2491-skyscrapers-profile/ I quite like the idea as you can really keep things tidy this way.

Yes - I'm pretty sure one or two of the rendering options allow for that Ray. Certainly the iframe way (which looks nice and not at all like an iframe ) will and I'm pretty sure the roll-your-own-HTML way of doing it will work too. As an example, there are hidden fields at the end of the forms like this: 1:contact-us:125e5bf0ddbe17eb22d269da97b0188f So it knows the form ID and name from that which I assume is so that you can use the same field names across different forms. For the best experience though, I think you need the latest Dev branch (2.3) of ProcessWire to make use of the latest version of FormBuilder. Sorry, lots of "pretty sure's" and assumptions in there now I read it back

if($page->title == 'customPageName') echo 'your js/CSS link';

Reading your comments, Pete, this article comes to mind.

The community issue is separate I think. I am a great believer that, once a community gets big enough so that it is not like a cosy family any more, it should be very separate from the main, promotional site. That means that it might have a common logo and possibly corporate colours, but other than that, its design is aimed at community. In the case of national websites, they would, by definition, be promotional sites (plus direct translated documentation) - they can have their own unique identity, but must follow some basic rules and be approved centrally (as any company with multi offices does). The community site, however, should be one central resource, albeit with language sections. That way, those that are multi lingual would be able to talk on native language forums and others that they can understand all in one place. Or use auto translators to understand posts if needed. But they remain part of the entire community rather than being off in another place entirely. (Note: it is vital, in these sorts of forum, that moderators duplicate important announcement posts across all languages. Time and time again I see this not done, which leaves one community feeling like they are also-rans. Multi lingual communities can work very well, but they need lots of management).

The problem with my idea of a "simpler" blog profile is that if I build it it's going to feel a bit wrong as it will throw some best practices out of the window to essentially "dumb it down", so if I were to attempt that then I might feel a littly dirty by the end of the process

Very interesting points here, Pete. I think the short tutorials on slightly more technical bits that you propose will not only help end-users but also less experienced designers/developers that want to start using the system but really don't know how. I think this would be less intimidating to them than, say, going to the API documentation and start getting ideas from there. This leads us to your next point, the idea of developing a more beginner friendly blog profile. I think the current blog profile is fantastic, and I've personally learned a ton of stuff from it, like how to neatly use functions to organise your code and make it more easily maintainable, best practices, etc. Having said that, I think it's far too intimidating for beginners, so having an easier alternative sounds like an excellent idea. I personally have some theories on this, but I'm gonna keep them to myself for the time being!

@ray - I was thinking that it would start with a "this is how you post in ProcessWire" so that you're showing the end-user how to enter content in ProcessWire as opposed to WordPress. At the basic end, this shows them that it's really simple and nothing to be afraid of. Then a simple 30 second bit at the end that adds a field to a template (shorten the sequence maybe) and show them how easy it is to do that for the slightly more adventurous Wordpress user. I think we just need a direct comparison as a starting point - this is how you create a "post", upload images and insert them into the "post". Then if we skip the bit where we setup categories and show them how easy that is we've pretty much covered a lot of it. Someone has already developed a tag field too but I can't seem to locate it in the Modules directory. @Joss - I agree. Ryan's profile is excellent out of the box already but - no offense ryan, and I think I've said this before - I wouldn't mind seeing a version that is even simpler code-wise. I know functions are the sensible way to go, but a version with more of the PHP code inline done neatly would probably appeal more to beginners and those WordPress users that are happy enough to dabble in WordPress' template code but not comfortable with functions etc. Something else to go on the list I think are a few alternative themes out of the box, but I think we've talked about that before. It's not really something you need to think about with ProcessWire as you can do what you like template-wise, but I think a few choices of killer designs would certainly entice people in who don't have the skills to begin integrating their own templates, but that would certainly like to learn over time.

See the user comments section on the strftime reference at php.net. There appear to be lots of feedback and means of working around this issue with strftime.

I think we should do it the WordPress way (sorry for mention the w-name). We don't need processwire.de - we just could use http://de.processwire.org/ (or .com) as a beginning (like: http://de.wordpress.org/). This page doesn't have to include all of the pages processwire.com does. It just would be a "hello german user. Yes, ProcessWire has a german admin interface. You can downlad the bundle here." And if you download processwire on this site it may should contain a german profile already...

It worked! I uploaded a new processwire, finished the installation and changed it to my old database in the config.php Just had to reset all users password for some reason. Thing worked on first refresh, amazing. I only lost a couple of images which were uploaded content, but it's recoverable. Thanks again!

Thanks for sharing your experience. I stopped working on WordPress sites some time ago, but I offered to help a friend with his WordPress site recently and was surprised by how little had changed. That's rarely the case, but I did have a big client request WordPress once. They were very amenable to other suggestions though, as the work got rolling. Pretty soon the WordPress site was a thing of the past, and the character of the work changed toward a more flexible, powerful collection of tools and resources. Earlier this year I sat in a meeting with a client, across the table from a social media consultant who looked at me and said at one point, "we are using WordPress for this site, correct?" I was sort of shocked, but she didn't really know of any other software, and was used to using WP for everything. She is a bit frustrated that she has to re-train just to use a client's site, but what can I say...it's not like learning new stuff is some rare thing in our industry. This client would have been lost with WordPress. I'm even frustrated by MODx these days, so I must be turning into a real CMS snob. Just got a client's OK to move a large, fairly prominent MODx site to ProcessWire after I built a newer, smaller site in PW for them. So looking at my work, it'd almost seem that "the right tool" is always ProcessWire. But I think it's mostly that ProcessWire is a flexible tool that is well designed to solve common problems.

Here is the first release version of the Blog Profile! http://modules.proce...s/blog-profile/ It is now up on GitHub as well: https://github.com/r...ign/BlogProfile Below is a lot more talk about this blog profile and how it works, but if you just want to install the profile and test it, it's not necessary to read anything further unless you want to. I've simplified this a lot from where it's been. It does all the same stuff on the front-end, but the code behind the site is no longer a huge departure from the basic profile. I've rebuilt this profile 3 times trying to find the right balance between making it as flexible as possible and making it as easy to understand as possible. I think it's got a better balance now than before. It's now at a point where it does everything it always has, but the template code behind it should be a lot more accessible and easy to understand. There is no longer a separate module or API variable. Everything here just happens in /site/templates/ files. Consistent with making it simpler, I've also removed the drag-n-drop theme support. While it was cool to have, it always felt a little dirty introducing some kind of proprietary theme support that was so different from the way I'd build any other site. This thing is pretty darn simple to theme as it is (just edit a CSS file). Maybe we'll take it further in the future, but we don't have many PW site profiles out there right now (1 or 2?) and so I decided this profile needed to stay more accessible on the back-end. How the template files work In ProcessWire there are any number of ways you can use your template files. In this case, we are using our template files (in /site/templates/) to populate 3 variables ($content, $headline and $subnav) and then including an HTML file (main.inc) to output them in the right places. The $content variable represents the center (body) column, the $headline variable represents the text headline of the page, and the $subnav variable represents the navigation that appears in the left sidebar. Once one or more of these variables is populated, the template file includes the /site/templates/main.inc file. That main.inc file is just a big HTML file that outputs the $content, $headline and $subnav variables in the right places. We've made an attempt here to separate most of the logic used in the template files from the output. Most of the markup is generated from files in /site/templates/markup/. These files are included from the template files to output specific things like a blog post, comment, etc. Because a lot of output needs are similar among the various template files, we've created a file called /site/templates/blog.inc that has a few shared functions in it. If you look in any of the template files, you'll see that most of them include blog.inc as the first thing. This blog.inc file also initializes our $content, $headline and $subnav variables, mentioned earlier. Outline of /site/templates/ with this profile /site/templates/blog.inc Shared blog-specific functions included by most site templates. /site/templates/main.inc The main HTML markup file through which everything is output. /site/templates/markup/ Contains PHP files that generate markup for specific things like posts, comments, etc. This is separated from the site templates to make it simpler for you to modify the markup if you want to. This is primarily used by the blog.inc functions, but also included by a couple templates as well. /site/templates/skeleton/ This is the Skeleton CSS framework. It is identical to the one they distribute except we added a wider viewport to it. You probably wouldn't have much need to edit anything in here. /site/templates/styles/ Stylesheets used by the blog profile. The most useful one in here would probably be theme.css, which contains all the color definitions for the profile. /site/templates/scripts/ Javascript files used by the blog profile. Not much is happening in here at present.

Thanks Pete, good to know about the difference there. That definitely explains why Cufon goes soft on the retina screen (iPhone at least). I will make a point to avoid Cufon.