yellowled

Granted, there's a lot of truth in that statement. However, there is another perspective that small businesses can value in a CMS – the way it can make maintaining their web site easier, saving them time, effort and, well, nerves. Everyone who has worked with PW will agree that it makes it very easy to customize the backend to a specific user's needs and ability. Now, that is something most people understand very well since they have usually at some point in the past tried to build and maintain the web site themselves using, let's say, not-so-great tools like your typical “1-click web site construction kit” provided by their (cheap) web hoster. Those clients usually can be pretty impressed by how a customized backend can be way less frustrating for them and help them actally fulfill their day-to-day tasks (let's face it, for most small business clients it's more like month-to-month tasks). I have never considered myself to be an artist or something, in fact I even have my difficulties with “designer” (especially since I don't have a formal education, much less a degree in that field). I consider myself to be a craftsman. However, with small business client's, I often find that it's necessary to also act as a consultant or even advisor. As you stated, most of these clients don't know much about our craft or the tools we use – moreover, a lot of them don't even know much about the internet and marketing in it. If they do, their knowledge is outdated. I guess what I'm trying to say is what can also help is to communicate to small business clients is that what you (in addition to your craft) provide is help. (In fact, one of my clients literally refers to me as his “web site helper”.) They won't get much help and advice from any cheap chop shop selling them a generic rip-off design, and it's something some of them might be able to relate to.

+ Home ++ News & Events +++ Company News ++++ Company News post 1 ++++ Company News post 2 ++++ … +++ Product News ++++ Product News post 1 ++++ … +++ Events ++++ Event 1 ++++ Event 2 ++++ … All of these would be pages in a PW environment, but they'd use different templates to distinguish between e.g. overview pages and single news post view. You can use the excellent MarkupSimpleNavigation module to create your navigation or handcode it. I'm not sure what should keep you from doing this in PW. Maybe it's the term “categories”, which is a terminology PW doesn't use. That's because in PW everything is a page, at least technically (but of course you can have a page template called “category”).

It really depends on the site concept. Using pages for these subsections might offer more flexibility, repeaters might be simpler for editors. (I'm not opposed to using repeaters that way, I just haven't used them that way myself – yet.) I know the whole “there's more than one way to do what you want to do” approach in PW can be confusing when you first get started. Then again, it does offer a great flexibility to react to individual site concepts and user needs. There almost always is more than one way, just pick the one that you feel works best in any given scenario.

I have never used images in repeaters that way, but I would assume that in this case, image fields are associated with a repeater panel just as they are usually associated with a page in PW. That means if you delete the repeater panel, you also delete the image along with it. If I understand your scenario correctly, that would mean that the editor would want to switch the associated image for the exisiting section, meaning he'd have to upload it again as the new image for the existing section. That is unless your image field allows uploading multiple images (which is a setting for image fields).

Another option would be to add the various sidebars as (hidden, grouped under a hidden page) pages * Sidebars (hidden) * Sidebar A (hidden) * Sidebar B (hidden) * ... and include them in your templates using a Page field, e.g. called sidebar. Then something like echo $page->sidebar->body; should get you the selected page's body field etc. You could even have this be a Page field which allows to select multiple pages – that way, all pages below Sidebars could be sidebar widgets, and you could add multiple ones to one page. It really depends on what you need and what works best for you (which is usually the case with PW).

Well, that's what you're telling size() to do – “return a thumbnail of $img which is 200px wide, 100px high, has a quality of 50 (which, by the way, is really bad), is not upscaled and is center-cropped”. I'm not entirely sure what you want to do there, but I guess you want to treat landscape and portrait images differently? I'm not entirely sure that's a good idea in terms of performance, but I guess you could get the image's dimensions first and switch between two size() calls (with different options even) depending on the aspect ratio.

There also the Email Obfuscator module which needs JS to decode the obfuscated addresses (might or might not be con for you).

Ryan, the example page for the module throws a 404. (Forgot to publish?)

For the record, that issue is out now – Screenguide No. 22. Should be available at larger news stands (usually not in small towns, though), especially those at larger trains stations.

There's no good way to do that in CSS in a responsive context. Well, technically there's text-overflow, but that also cuts off information in this case.

We already do that for the stable versions (using git tags), see Releases. I think most users would assume that a lang pack always matches the latest stable release of PW. So if you download a lang pack from the modules directory, it should match the current stable version of PW. The link in the modules directory also points to the latest master zip of the lang pack, so the master branch should be “in sync” with the stable releases of PW. Also, in my experience, users downloading from GitHub manually usually just grab the lastest master zip. We should also consider that there's now a module to install languages from the backend. I haven't tested it myself yet, but I assume that always fetches the latest master zip as well, right?

There's no need to rename, git can handle that (as Marc suggested). git offers a feature called branches. It basically means two copies of the same files in one repository. We would use the master branch for the stable versions and have a dev branch for the current development state. Once a new stable PW is available, we just merge the dev branch into master (that's a simple command in git – if nothing goes wrong, and if so, git offers tools to resolve the conflicts), tag the new version and are done with it. The problem with this is that it demands a bit of discipline and makes it a bit more complicated to contribute because contributors have to be able to use branches in git. That's actually not that complicated, but there's a chance to get confused while switching between branches.

Judging from this experience, if you have to enter and emit this massive amount of data for the various types of real-estate objects (the client wanted to here, it might or might not be necessary), you'll probably want to use the new ProFields: Table module. I don't use it here, and it's been a pain in the butt to create fields and code the templates for that. Another option would be to implement the details for any given object simply as a textarea, but since this client is not very experienced in editing content, it did not seem like a viable option. As for moving the heading below the image, I think that while it may technically be possible, it doesn't make much sense. It's probably not really a stable solution, either – the headings could still have a different number of lines below the image, which would ruin the layout as well. Yes, the form is a simple PHP form. See https://processwire.com/talk/topic/6516-%E2%80%9Cpre-set%E2%80%9D-a-form-field-using-session/ for the implementation of “pre-setting” the form field.

I think that's pointless here. On most pages, you'll get that from the pages main heading. As for the current page link, there's mixed opinions on that. (Some users are actually irritated if the current page is not a link.)

Fine by me, but this will make it harder to maintain the repository. I'm not sure if all contributors (most of the commits by now come in via pull-requests) will be able to work with different branches. (Yes, that is not a good reason not to do it, I'm merely pointing out that it's more prone to error than the current setup.)

Two new small sites, both powered by PW 2.4. Both of them in German only (sorry, people who can't read German), HTML5 and responsive. Both kind of simple in design (per request). http://www.eutin-immobilien.de is a site for a local real-estate agent (in a very small town). Content's become a bit weird since the client started to manage it himself because he used the wrong image formats here and there and also decided to skip my advice to keep the headlines short. Nothing much I can do about that; at some point, you just got to let it go. (I'm not a huge fan of limiting the number of characters there.) http://clic-deutschland.de is for a small, but expanding association which … well, I guess it's best described as a network of support groups for addiction. Kind of like AA, but with a different approach. Especially challenging since they have extremely weird needs in terms of the date formats for their events. Excellent example of how to use the GoogleMap marker module with a jQuery plugin to make it really easy for editors to add individual maps for directions. (The latter was originally requested as a Wordpress site. I suggested PW instead, and the main editor is so impressed by PW that she's considering it for the next relaunch of her own web site.)

It's kind of unclear how to handle this for the GitHub repo. So far, we have only included versions matching the stable releases of PW there, meaning it has tags for 2.3 and 2.4. I'm not sure if it would be a good idea to continously upgrade it with 2.4.x versions. Then again, I don't really see side effects here, at least not at the moment. I would like for these to be consistent, though – i.e. not skipping versions. Not sure if it's feasible to have seperate versions of the lang pack for any patch version. That being said, I'm happy to do it the way you guys want to as long as there are no technical concerns (which I don't see as of now; might happen if lang packs become installable from the backend like modules one of these days).

It's now switched to one PHP version (5.3.19) for both domains and seems to work just fine now. The weird thing is actually that it did seem to wok okay on 5.2.x, but then again, I haven't really worked with it while that was active. Thanks for clearing that up.

I got a Skype message from Marc suggesting I check it out. We had been exchanging our evaluations of various CMS back then (this was when PW 2.1 was current, I think), so he knew what I – we both, actually – was looking for in a CMS.

That was actually valid, so I just switched both domains back to 5.3.19 and logged into the backend to make sure that it still works. After logging in, the backend gives me a message saying (paraphrasing here since the backend is in German) that the password system has been updated and advising me to change the password to update my account …?

I have done nothing with /site/config.php in this particular installation but edit $config->httpHosts over FTP using a text editor. That doesn't seem as if it would change the userAuthSalt (although it's of course always possible that some weird copy & paste foo happened there). It's kind of hard to diagnose since this is a project which has run on the temporary domain for quite some time, and unfortunately, there's no version control here, so I can't easily check for changes in that file. I do, however, recall switching the PHP version after the installation (I think from 5.2.4 to 5.3.x or 5.4.x), and here's the thing – for the new domains, the PHP version has been switched back to 5.2.x according to the web hoster's admin interface. I am, however, going to have to consult their support to see if these actually are valid here (the admin interface is kind of confusing).

I should maybe add that this is a site where I had to use $config->sessionFingerprint = false; in /site/config.php to avoid being logged out of the backend all the time.

I developed a client's site using a temporary domain. Over the weekend, the “real” domain(s) were added to the webspace, so I added them to $config->httpHosts in /site/config.php and removed the temporary domain there. As a result, all backend logins “forgot” their passwords. That's not a biggie in this case since I have the “Forgot password” module installed, but it's still something that alerted me since I don't see the connection there. I suppose it might even be a bug? (Using 2.4 here.) Anybody have an idea if there actually is a connection here (sessions? cookies?) between httpHosts and passwords?

Well, one problem would obviously be that you'd have (at some point) translations for all languages in the module's repository. I think PW is currently being translated into 18 languages; it's likely to get more over time. For most sites, even multi-lingual sites, that would give you 10-15 or more unneccessary translations in the module's repository. I think it would be way better to bundles translations with the modules they belong to, so your idea is basically a good one. However, I still think it needs some kind of system to detect which languages should actually be installed in any given PW installation.

Oh, also something to think about – I don't know how you guys handle this, and it obviously depends very much on the project and the modules used. I think translations are (mostly) for users, e.g. editors. Admins should be able to handle a PW backend in English, although I wouldn't call it a requirement. However, I wouldn't know how someone who doesn't read English would even be able to understand PW enough to administrate a PW installation. Most of the documentation is in English only. So in most of my projects, clients have a “backup” admin account, but use PW as editors, which means they don't get to see much more than the page tree, which is a core feature. What I'm trying to say is maybe we're overthinking modules translations quite a bit here. Yes, they would be nice to have, yes, it would be nice to have a way to easily install them. But if someone definitely wants a module's backend section translated, a bit of work to install the translation should be fine.