yellowled

This system does put a pile of work on module developers (and even more on Ryan), but the result if worked out properly could help the day to day usage of the admin enormously and makes ProcessWire even more accessible to potential clients

Here's what usually happens in my experience: I spend about a (paid) day documenting the specific setup of PW sites for clients, proof-reading and carefully crafting nice PDFs, which I then mail to the client. Clients usually go “Oh, this is great! We have or own manual tailored to our needs which we can reference any time we don't remember what you told us in the CMS training! I'll print out copies for everyone right now!”

Weeks or months later I get a call. “Erm, we kind of forgot how this-and-that works, and we were wondering if you could come in for another CMS training? We haven't used the system in a while and most users forgot what they learned in the training.” – “Well, you always have the documentation I wrote for you …?” – “Yeah, about that … could you send us another copy of the PDF, please?”

The alternative is clients that go “Nah, we don't need documentation, we'll get along with the backend just fine.” And they do, because PW can be pretty self-explanatory.

Bottom line, documentation is important (and PW is documented pretty well already, compared to other CMSs out there). But a lot of end users (again, just in my experience) tend not to read it, because they prefer a human expert to tell them how what they specifically need works. (Which is why questions get asked over and over again in forums, in my opinion.)

I'm not sure a documentation integrated in the backend would really work and thus be worth the effort or overhead. (In fact, I don't even know if it would be an overhead.) Also, there's the risk of inconsistent (some things being documented very well, others not so much) and outdated documentation, which I feel is almost worse than no documentation at all. Oh, and translations, of course.

I deliberately try not to use modules unless I need them. There really is a lot you can do with the core/API alone, so I tend to consider modules as convenient helpers, usually to cover for when my puny PHP skills don't suffice.

That being said, I recommend:

• Markup Simple Navigation – to dynamically generate almost any navigation structure
• Map Marker (Google Maps) – if you ever need users to be able to generate Google Maps, this is a lifesaver
• XML Sitemap – it's one of the basic SEO things, and no one should have to generate an XML sitemap manually
• Language Field Tabs – as if multi-lingual sites weren't awesome enough in PW already, this makes it even better
• Forgot Password (Core) – never, ever forget to install this; if a project has more than one user, someone will forget their password at some point

It's pretty pricey for a small tool, but every once in a while, you can find Better Rename discounted or in a bundle. Doesn't do random strings as far as I know, though.

I've never watched Toy Story, but I was always wondering what Debian will do if they run out of characters to name the release after …

Personally, I don't really care for target audiences or if they'll find code names appealing or off-putting. Code names IMHO are for users and developers, not for suits. I don't think anyone has ever considered not using a Debian server because the OS is called “Wheezy”.

I do, however, think that this should ultimately be Ryan's call.

Already running Yosemite on a 2014 MBA. I was really eager to get my hands on a feature that most people probably find rather whatever, but I loved it from the moment Apple first showed it at the keynote introducing Yosemite – doing iPhone calls on a Mac.   (It does actually work well for me. No more having to pick up the call on the iPhone, plugging in headphone to have my hands free etc. Just accept the call on the Mac and talk.)

Other than that, I'm okay with the new look. No idea why a lot of people are desperately looking for ways to replace the Finder icon, the folder icons in Finder and get Lucida Grande back. Also, I love the new iOS-style notification center. Oh, also, second-best feature in Yosemite: the F11/12 keys for controlling the sound volume now don't make sound any more by default. I'm really not going to miss those sounds at the start of each Skype call when everybody's adjusting their volume …

Since I don't use MAMPP or the local Apache, no issues with that. However, I had to “repair” some Ruby gems that I had installed for whatever reasons. I really only use Sass/Compass and scss-lint, so I have no idea why those gems are even installed.  Other than that, everything seems to work fine, I didn't even notice that the upgrade took longer than expected because of all the Homebrew stuff I have installed.

I already said I liked it on Twitter. 

Teeny-tiny thing about the icons (I'm glad I'm not the last person on earth who uses icon fonts, BTW) – you could make the icon font icons a wee bit nicer for screen readers if you replace i.e.

<i class="icon-search"></i>

with

<span class="icon-search" aria-hidden="true"></span>

The i element is “text in an alternate voice” in HTML5, I'm not sure if screen readers react on that. The aria-hidden makes screen readers not read out the glyph used for the icon. However, if you use aria-hidden, you should also add a fallback text for screen readers to actually read …

<span class="icon-search" aria-hidden="true"></span><span class="screen-reader-text">Search</span>

… and hide that for visual browsers.

While I'm poking at the search, why not use type="search" for the input? Also, the search input is missing a label (again, just for screen readers, and it should probably be hidden for visual browsers as well.)

Interesting...I provided a similar answer to toothpaste in this other post

Yeah, I kind of read that only after posting this here. Oh boy, duplicate content! 

However the links are not sortable.

Oh, that's because I misunderstood. I thought you wanted to filter, i.e. “only show the items that belong to a specific category”. That's because in your mockup, it explicitly says “Filter:”, not “Sort”. Sorry, for sorting you're going to need either completely different JS or what totoff suggested.

PW needs functionalities, otherwise why implement a CMS at all! A CMS brings functionality.

Not necessarily. A CMS can just give you the tools to implement functionality, it doesn't necessarily have to hand you the functionality on a silver platter. See Ryan's excellent statement on the whole “teach you how to fish” thing.

For the record, https://processwire.com/talk/topic/7572-processwire-recipes/ is the discussion about a snippets site for PW.

WoW, this is a bit scary, but like it a lot. I will try to get this to work.

Is it an idea to put all working pieces of code in a forum called 'snippets'?

I remember somebody mentioning an idea to create a wiki or something for code snippets.

Trust me, this will get a lot less scary once you're used it a couple of times, even if only in “practice templates”. That's usually the best recommendation for people who are new to PW anyway – implement a site that you already have build and/or designed with it. Well, first get to know the docs and the API a little, but then just start working with it. It is so much easier than it sounds in theory …

As in most cases with PW, there are multiple ways to accomplish this. That can be scary if you're coming from a module-based system and/or are not a coder, but once you “get” how much freedom it can give you to not have to rely on modules, it's a thing of beauty. Yes, it means you're going to have to write PHP code, but you have the trusty PW API to help you with it. It's really not that big of a deal, trust me. (I'm an idiot in PHP myself.)

Let's assess what you need here and strip it down to very basic concepts. Basic concepts are great, because they are usually generic and thus reusable. As you probably know by now, the most basic concept in PW is a page.  So what you need is a page type to list all the items, a page type for the actual items and a page type for categories. You'll probably want a superordinate page type for categories as well, but since those don't necessarily have to emit frontend markup, they're pretty easy to define. Your page tree for this might look like this:

• Overview
  • Item A
  • Item B
  • Item C
• Categories
  • Category A
  • Category B
  • Category C

Categories as well as its child pages most likely only need a placeholder template since they don't necessarily emit frontend markup. You could have a category.php in your templates folder that looks like this:

<?php
// Placeholder template for categories

Now, in your template for items (let's call it item.php), you would need a field to associate the items with a category, meaning: with a page that is a child page of „Categories“ and/or has the categories template. So you would create a field of the Page fieldtype, call it e.g. “itemcategory” and in its settings limit it to one page (meaning one category), which has to be a child of the page “Categories” and have the categories template. All that is pretty self-explanatory once you see the Page fieldtype in the PW backend. If you add this “Item Category” field to your item template and create a new page with that template in your backend, you can now choose a page representing a category for that item. (Let's skip the actual content of item.php, that's not really relevant for the list here.)

Now, how do we list those items in your format? We need a template for the overview page, let's call it item-list.php. In that template, we can do this:

<?php
// Get all child pages, i.e. items
$items = $page->children;
echo "<ul>";
// For each item in our list
foreach ($items as $item) {
   // Create a list item including a link to the page, the page
   // title and the category title
   echo "<li><a href='{$item->url}'>{$item->title} ({item->itemcategory->title})</a></li>";
}
echo "</ul>";

The filter is a bit more complicated, but mostly because it depends on how you want to implement that. One option would be to just go with a JS-based solution, at least that's what I would do. (I'm a bit more comfortable with JS/jQuery than with PHP, so …)

You would change your item-list.php maybe like this:

<?php
// Get all children of the categories page
$categories = $pages->get('/categories/')->children;

// Create buttons for all categories
<div class="filter">
Filter: 
foreach ($categories as $cat) {
    echo "<button class='show-cat' data-show='" . strtolower($cat->title) . "' type='button'>{$cat->title}</button>";
}
echo "</div>";

// Get all child pages, i.e. items
$items = $page->children;

// List all items
echo "<ul class='items'>";
foreach ($items as $item) {
   echo "<li class='" . strtolower(item->itemcategory->title) . "'><a href='{$item->url}'>{$item->title} ({item->itemcategory->title})</a></li>";
}
echo "</ul>";

So now you have

• a button for each category which stores the lower-case name of said category in the data-show attribute
• list items which have class names which also have the lower-case name of their associated category

which means you can write a little piece of jQuery

$('.show-cat').click(function() {
    var showme = $(this).data('show');
    $('.items > li').hide();
    $('.items > li').hasClass(showme).show();
}

which gets the associated category class of the button and then first hides all the list items and then shows only the ones which have the class associated with the button (i.e. the class matching the selected category). Please note that this JS code a) requires the jQuery library and b) is not perfect for performance, but the easiest way to quickly show you how to do it. It would be better to instead add and remove classes, but for that we would need another code example for the CSS you'd need for those, and I'm already posting a really long example here. 

Also please note that all this is untested and written from scratch off the top of my head on a lazy Sunday evening, so there might be typos. There might even be logical errors in the code. (There probably are. As I said, I'm an idiot in PHP. )

Sorry about that if that's the case, but I hope this example gives you an idea of how simple it can be to write the code for this yourself instead of relying on a module. Yes, other systems might give you a module ready to plug in which gives you about that functionality without having to write a single line of code (well, probably not), but this way you control exactly what code is used. You don't have to have some part of it in one specific way because the module's author decided to do it that way. You can have it your way.

As Philipp already stated, German governments like their taxes a bit complicated sometimes. Most of the desktop software available unfortunately is made by, and by that made for, non-Germans. I have tested quite a few solutions available (for OSX), but most of them either don't work well for Germans or (for my taste) offer too many options and possibilities, and therefore are pretty complicated. Besides, most of the OSX apps available for businesses are quite pricey and don't offer a test version, which in my humble opinion is, well, pretty damn stupid.

I also don't really like web apps for this purpose (can't really explain why, it just feels wrong). If anyone likes web apps for this, Billomat might be worth checking out. I've only heard good things about it, it's just not for me.

So, erm … I do invoices in Pages using a custom template. No, that's not ideal. But it works (for me). OSX Reminders (using the great Fantastical as a frontend) for due dates.

Interesting: something I didn't know is that you can't just update the language files.

Here's what I did: fresh PW 2.5 install. Installed Language support, installed pw-lang-de for 2.4. Saved. Installed pw-lang-de for 2.5, saved. Result: All language files that are in both 2.4 and 2.5 are duplicated (with a “-1” suffix).

Is this intended behaviour?

I tried to upload the zip from Github on the default language page (PW 2.5.1 dev) but got the following error message for a whole bunch of files:

Not sure I understand what you're trying to do there. Did you have a dev version of the language pack installed which you tried to update with a stable version of it? Or did you just drop the stable language pack into PW 2.5.1? Manfred will probably be able to explain better how updating dev versions works, I don't really use dev versions.

I guess you could always delete the uploaded language files and re-upload the version that you want to use, but I have to say I'm not sure how that will work out. I've never done that myself. Sorry.

Thanks to Manfred's relentless efforts (and a little merging by me), the German language pack for the stable version of ProcessWire is now officially updated for 2.5.

I have to admit the merge was a bit of a rocky road, so if anyone notices any issues with this in 2.5 (I have only checked it briefly myself), please report them. The best way to do so is via the language pack's GitHub issues.

Given that 2.5 is just around the corner, I'm looking forward to a pull request for the stable pw-lang-de repository (whenever you think it's ready), Manfred. And thanks again for putting all that work into these language files. 

(If you feel it would make maintaining the language files easier for you, I'd be happy to hand over the stable repository to you. Just let me know.)

Funny thing, I usually associate “Enterprise CMS” with something expensive and closed-source that consists of a weird combination of Java, Perl, XSLT and other outdated technologies which should not be used to build modern web sites or apps any longer. 

As for “Business CMS”, that's a term that I (just my 2 cents) find rather confusing. A lot of us make a living building more or less complex web sites and apps using ProcessWire. Judging from the Showcase forum, a lot of those web sites are for businesses. Besides, what would be a “non-business” CMS? Something for hobbyists? (Did I just hear someone say “Joomla”?  )

In all seriousness, I don't think it's necessary to market PW for Enterprise/Business use. It (currently) is a CMS for developers. Devlopers who make/made an educated, informed decision to use this particular CMS. Developers who will (individually) market this wonderful CMS to their clients.

I really liked the way Marc put it in the original thread – focus on building a smart, yet simple CMS that developers like.

The rest will follow organically. No need to hurry it. 

My 2 cents, and sorry if I'm repeating things that have already been said – didn't have the time to read everything already posted here.

Wordpress has become vastly popular as a blog system. It is being used by a gazillion of people worldwide, most of them not very tech-savvy, which is why there is a huge market for prefabricated themes and plugins. It started out as a small open source project, but is now – at least partially – being developed by a company with about 250 employees plus a very active community of freelance developers. Due to its huge popularity, it has morphed into a system which can also be used as a CMS. This exponential growth into the most popular content publishing system worldwide has taken it's toll. It's bloated, there are unmaintained plugins, it has security issues and if you look closely, the sheer number of themes and plugins does not necessarily say much about their quality. (Did I just hear someone say “Windows”? Nevermind.)

ProcessWire is a content management framework/system which was originally developed by a single developer. The community is picking up lately with more people developing plugins as well as contributing to the core while the system also gains traction with a small, but loyal user community. It's clearly not a system for everyone, mostly based on the design of the system. It might never become a system for end users, but obviously it has become rather popular among developers looking for certain features in a CMF/CMS.

Why anyone would seriously want to compare both systems is beyond me.

that's pretty cool, isn't it?

It's really not so much about “cool”, it's about being able to work the way I think projects should be done. Now, some people might say “Does that really matter, is it really worth it for small clients?” Here's the thing – I don't think “small” clients should be treated any differently. There are some best practices which I think should be applied to any project.

Here's an example: some small hosting plans might not include mod_rewrite or gzip compression. Personally, I think it's ludicrous to implement any web site these days without either one of those.

I know, that 1&1 starter is a very poor package and I advise a customer against this package, but the customer is king.

Ever since my last experience with 1&1, their infamous “support” and their horrible performance in smaller hosting packages, I have explicity banned certain (German) providers. I will decline new clients which insist on staying with those hosters, and I can only advise to adopt that policy. Most clients don't understand the technical limitations that come with bad hosting, and the result will always fall back on you. It's just not worth it.

If you look for CSS “regressions”, my first thing to check out would be if all floats are cleared properly, if there's any “strange” positioning involved. Maybe to test it, temporarily deactivate CSS altogether or very selectively for the pagination using the browser's dev tools. If the pagination links are there and the markups looks the same, it's very likely some CSS issue.

Well, it's kind of hard to tell why it doesn't work without knowing what doesn't work. Does it not create any HTML markup? Can you not click the pagination links (that might be a CSS issue rather than a PHP issue)? Do you have an accessible live example that we could check?

So I have this site to maintain which is a low-budget, kind of non-profit pet project. Basically, it's an online poll for a music festival. It runs once a year (it's actually running now, which is why I even think about it) for a month. As of now, it's implemented with Contao, but I want to move away from that because it drives me insane. PollDaddy is not an option (because of the budget), and apeisa's Fieldtype Poll might be a tad limited for it (not sure about that, though).

Currently, the way it works is:

• People register for an account with a UID/PWD they picked themselves (UID could as well just be email address)
• They get an email with an account confirmation link which leads them to the login
• It's usually about 10-12 polls per year; people can vote in all of them, but they don't have to
• Requirements for the polls are very simple – 5 or 10 possibilities, 1 selection per poll (so basically radio buttons)
• The results are not made public or even open to registered users, but of course I need some way to get the results.

I'm gonna need some maintenance tasks in the backend like “delete all users which have a specific role (meaning delete all users which voted this year because we don't want to keep around the data forever)”, but all that should be pretty straightforward in PW. The part which I haven't quite figured out yet is the actual poll itself. As I said, third-party services like PollDaddy are not an option, and I'm not sure  Fieldtype Poll would meets all the requirements I have. (Just one vote per user, no multiple votes from the same browser, don't show the results to users etc.)

So my idea was this: a poll like this is basically just a form like any old contact form, isn't it? Submitted forms in PW can be saved as pages in the system. So I could build a system which saves every user's poll results to a hidden page under, say, a page called “Results 2014”, and I could probably write some PHP logic to gather the current year's results from those pages, right? Every poll would be a group of radio buttons which would have a value (or not, if the user chose to not vote in that poll), this value would be saved in a field in that user's results page, so iterating over all child pages of “Results 2014” and counting the values would give me pretty much what I need, wouldn't it? There wouldn't have to be some kind of fancy diagram or anything, just a list of values will do.

I don't need code examples here just now, I have about a year to implement this before the next poll takes place. What I'm not sure about this is:

• if this is actally doable in a sensible manner the way I imagine it
• performance issues due to the number of users (I don't have last year's numbers any more; this year, we're up to 980 users after the first week, but it usually slows down after that)
• security; it's rather important to the operators of the site that every user can only vote once per poll (although they are aware that there are ways for users to create multiple accounts)

So, any thoughts on this? Does it sound like a bad idea?

Oh, this is going to come in very, very handy one day. Awesome.