SiNNuT

Again, thx for your always clear and thorough answers. Maybe it can get a little annoying people asking stuff that's obvious to you but if i encounter something that i don't understand most of the time i ask to make sure i'm not missing anything and/or doing something wrong.

Go to site, config.php around line 90, set to true: /** * debug: debug mode causes additional info to appear for use during dev and debugging * * Under no circumstance should you leave this ON with a live site. * */ $config->debug = false;

Thx Ryan, makes perfect sense.

I just started using the repeater module from a fresh github install from today. When creating repeaters the repeaterMaxItems seems gone from the UI. I can't seem to set it anywhere. Judging from the video there should be a setting for this? Glancing over the module code there seems to be some stuff related to repeaterMaxItems that is commented out? Can someone using repeaters can confirm this? Also a screenshot from adding repeater items. This seems kind of off, with adding _repeater[id] behind the fieldname - edit - This seems to be the case if a field attached to the repeater hasn't got a label value set. I will report this on Github.

Great stuff on the auto-complete field. So useful for many things!

hmm, this is also the case for pages that do have a file based template, with only the title field. So this brings me back to my OP question.

I am indeed working with a file-less template. This makes sense cause it actually gives this info on the template edit page: "Pages using this template are not viewable because the template file (tt.php) does not exist [no-file]." So i guess publish/un-publish haas no relevance for file-less template pages.

When you create a new page, and then save, with let's say the basic-page template the page has the status unpublished. When i create a new page, and then save, with a template that only has the title field the page goes straight to published status. Is this by design? If so i'm curious about the reasoning behind this.

I don't think this is a bad choice, if you want to open external links in a new tab (or window, depending on what the user's browser and settings). In html5 the "target="_blank" isn't deprecated.

You are referring to the Import Pages From CSV module? Check out this screenshot , "what to do with duplicate page names" I haven't used this option myself but i guess if you check the 'modify existing page' it will update the field body.

Looking good! One thing i noticed: In the mobile view the main nav and categories nav are turned into dropdown lists which is nice; the only thing that could be slightly confusing is that the main nav dropdown doesn't have a heading to give a clue to what that dropdown exactly is, whereas the categories dropdown below has.

Nice Neil, i will follow your work with interest.

Hahaha, that video is great!

I can't really comment on (the effectiveness of) akismet since i've rarely used it. But i'm curious about what spam prevention techniques you use on you're comment form? I've had good results with a combination of the honeypot method and timestamping the form to check if the form was submitted within a definable number of seconds. If that isn't working you could consider adding some logical questions (textCAPTCHA). Make your own or use a service like this one: http://textcaptcha.com/why

I've used and still use MODx Evolution(v1) and Revolution(v2). I still run a production site on Evolution. This is nothing fancy and i've tried migrating it to MODx Revolution. This was a painful experience. I totally agree with yellowled, Revolution is powerful and feature-rich. It has some nice add-ons, an underlying framework and orm-like system, xPDO, for making your own modules. But imo things are very complicated and clunky. The back-end is pretty slow (heavy ext.js) and confusing. Clients don't tend to like it. Snippets, chunks, template variables. To understand user management, ACL's and stuff like resource groups you have to be a rocket scientist. I wouldn't waste time on MODx right now because they kind of acknowledge their mistakes with the announcement of MODx 3.0 for 2013.

Hmm, not the most descriptive topic title i've ever seen I would probably start from top to bottom, from the calibration certificate to test chart: lifting gear, and carefully write down all the fields needed. From having a quick look there are a lot of fields that are basically the same but only differ in the label. Try to minimize (DRY) the number of fields and make things as reusable as possible. For this the 'field template context' feature can be quite nice (http://processwire.c...mplate-context/). Also, be sure to make good use of the page fieldtype, to make things maintainable and consistent as possible. Look at your data-structure from a relational (orm) pov, of course keeping in mind the PW style of doing things in this regard. Once you've got all your fields in the system i would basically create a template for every element you got in the dropdown on your example page. Add the fields to the templates the order and way you like and start to test things. I also see fields like 'customer' and 'calibration performed by'. Will all this data be available in PW or do have to interact with other systems, like a crm or stuff like that? Also, will the people who perform tests login to PW to add pages? Or do you plan to build some sort of front-end for them to do their stuff?

I can't look it up in the PW code right now but assuming $a->sort is the default php sort it's not a bug. PHP sort function is case sensitive and goes A-Z first and then a-z. Look at http://php.net/manua...nction.sort.php for more details. - edit - https://github.com/r.../Array.php#L657 So ksort and krsort (for reverse) Maybe it is possible to add options for case-insensitive and natural in the core, something like: uksort($sortable, "strcasecmp"); // case-insensitive uksort($sortable, "strnatcasecmp"); // case-insensitive, natural order algorithm Not sure if Ryan finds it desirable, maybe there are some pitfalls to consider.

Thx for the heads up on this.

The parent doesn't need the field. Your date field needs to be set to 'Autojoin' for it to be available as 'sort by' option in the parent page. You can find this when you edit the field, under 'advanced'. Your original questions i'm not sure. I think this would require some hacking.

Hi Soma, maybe i'm overlooking something but $page->sort seems to be missing from the cheatsheet. This one maps to the integer sort value present in the pages table. Sometimes it can be useful.

That should work but you really don't give a lot to go on here. Have you you checked that you're pub_date field actually contains values? If you can't figure it out yourself you should provide more info, possibly a relevant code sample.

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.

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.

ah yeah, that 3 letter word check is a nuisance tbh

Nice site. Maybe you could store the visitors language preference in a cookie? Upon revisiting the site it still gives the choice a language page. Maybe a default lang and if and when a visitor choices otherwise store it for next visits.