netcarver

@Nikola, thank you for putting this up on Github. @all, I've updated the futura-delta repository on Github (download as zip) to include many of the features that Nikola has worked into his lovely theme. The main difference between the two is that futura-delta has a much lighter approach to styling the search box.

Hi diogo, I tend not to use the default theme -- but I do think this is a good idea for those that use the same theme everywhere.

Hi Nikola, Thank you for this update. Could you be tempted to setup a github account and host your code there?

@evan: Thanks for posting the solution to your problem.

Ryan, I've not tested this, but I am impressed with the speed with which you handle reported bugs.

Textile v2.4 is now out. Check the change-log for anything new.

Ryan, you are definitely invited, as is anyone else from the wider community who happens to be in the UK whenever we decide to meet

Wondering if anyone here has tried Asana? Just stumbled on it as a potential collaboration tool and it looks very good.

Let's see who else we can get to join us. I wonder if Pete might be able to come over from Chester too.

Great to hear DaveP. I travel up to the Warrington area from the Southwest every month or so. Would you be able to travel down to Warrington/Manchester for a meetup?

Would anyone be interested in a ProcessWire-themed meetup/social gathering in the UK?

Yes, using JSON would make transfer very easy. However, I was thinking that, just as with articles in textpattern that are written in textile and converted to HTML on save, the conversion from a YAML/NEON def only has to happen once, just when the structure is saved just after an edit. There is no need to trade verbosity for speed. If you stick with using the PHP-array to form conversion, then people can provide whatever front-ends for that they wanted, graphical (form building UI), compiled (from YAML/NEON), JSON or a straight PHP array.

This looks great Ryan. If you take this a step further with the input formatting done in YAML or Neon then you'll have a super-terse way of defining your form structure.

Hello all, I've just pushed textile 2.4 up to github should anyone wish to try out some of the new features. If you do try it out, please keep me informed of your successes or failures with it. Download instructions are at the end of this post. What's New? Quite a lot... Support for HTML comments. Support for extended characters in URLs. Support for Redcloth-style definition lists. More robust handling of notelists and note definitions. Support for linebreaks in table cells. Support for apostrophes following abbr/acronyms. Support for ordered list continuation/start control. More robust detection of lists so that even those which are not separated from the previous text are found. Customisable format for footnote refs and marks and for notelist refs. And here are some examples of the above to help you get started 1: Support for HTML comments. Previously having HTML comments embedded in your textile source code could lead to broken output. You should now be able to get well formatted output even if you feed it things such as... Here is some text with a <!-- Commented out[1] --> block. <!-- Here is a single <span>line</span> comment block --> <!-- Here is a whole multiline <span>HTML</span> Comment --> bc. <!-- Here is a comment block in a code block. --> 2: Support for extended characters in URLs. You can now do this... "Übermensch":https://de.wikipedia.org/wiki/Übermensch "äöüÄÖÜßçéáóúèàòùÉÁÓÚÈÀÒÙêÊôÔâÂûÛåÅœŒæÆøØëËïÏ with trailing slash":https://en.wikipedia.com/ä/öüÄÖÜßç/éáóúè/àòùÉÁÓÚ/ÈÀÒÙêÊôÔâÂû/ÛåÅœŒæÆøØëËïÏ/ ...and get correctly formatted links. However, if your link has non-word characters at the end then you have to use textile's link alias feature to get them correctly recognised and encoded. So for things like... http://msdn.microsoft.net/en-us/library/cby9kycs(v=vs.80).aspx (brackets + multiple periods) http://ja.wikipedia.org/wiki/福島駅_(大阪府)/ (brackets) ...you would need to do this... Contact "Microsoft":myalias1 or check out "福島駅":myalias2. [myalias1]http://msdn.microsoft.net/en-us/library/cby9kycs(v=vs.80).aspx [myalias2]http://ja.wikipedia.org/wiki/福島駅_(大阪府)/ 3: Support for Redcloth-style definition lists. Although PHP-textile has supported definition lists for a while, this version adds support for the redcloth definition list syntax. So you can now define lists so... - coffee := Hot _and_ black - tea := Also hot, but a little less black - milk := Nourishing beverage for baby cows. Cold drink that goes great with cookies. =: 4: More robust handling of notelists and note definitions. Textile is pretty picky about its notedef and notelist syntax. Prevoiusly both had to be terminated with a period. As users seem to miss these out fairly regularly I've relaxed this and now your notedefs and notelists don't need to end with a . 5: Support for linebreaks in table cells. You should now have newlines converted into <br /> properly in tables now. 6: Support for apostrophes following abbr/acronyms. Previously apostrophes following abbr/acronyms were not being encoded correctly, showing up as an open-single-quote mark. These should now work just fine... NATO(North Atlantic Treaty Organisation)'s pretty big. The NHS(National Health Service)' charter states... 7: Support for ordered list continuation/start control. When starting an ordered list you can now specify the start attribute to be applied like so... #8 Item 8 # Item 9 And if you want to continue a list's numbering from where you previous ordered list finished you can let textile know using the continuation character... #_ Item 10 # Item 11 8: More robust detection of lists so that even those which are not separated from the previous text are found. I've relaxed the constraint that lists have to be separated from what comes before them by two newlines. So the following example will still correctly generate a list... A list of colours. * Red * Green * Blue 9: Customisable format for footnote refs and marks and for notelist refs. Some languages need a slightly different way of showing footnote references in the main text (or indeed, marking them in the foot itself) so you can now define your own format before you include classTextile.php in your project. Please look at the commit messages here and here for more details. Getting the file... If you do want to try it out and have an existing installation of PW or Textpattern which use textile then you can follow these steps to get the release candidate installed... Backup your existing classTextile.php file. Click here to access the new, raw, classTextile.php Save this over your existing file.

yellowled, I've updated the gist to show how to put the form into a contact.php template file. If you need to make the recipient email settable via PW, just add an email field to your contact template and use the PW api to put that into the recipient email address in contact.php.

yellowled, If you want to try it out, here is a simple contact form that you might be able to use in your site. If you do want to try it you will also need to follow this tutorial to get Flourish working with ProcessWire. Should be pretty easy for you to extend.

Hello yellowled, Have a read of this topic for a discussion of this. Are you just wanting to have the content of the form(s) submitted to you via email or do you need to do something more?

Yes, that seems to work. Would be nice if we could specify the year range to appear in that picker (as sometimes year +/- 10 is too big a range, and sometimes too small) -- but perhaps I'm just being picky. Also having issues with the unix timestamp, but I may be using this wrong. For this, I've set my timezone to Europe/London and we are on daylight saving time here. If I manually set the field to 0 and save, it gets adjusted to -3600 on save, even though I wanted it to be zero -- presumably an adjustment for DST. Anyway, I know there is an adjustment of -3600 being made on this field when saved directly. Ok so far. If I now open the picker and take the year back to 1970, the month back to Jan and the day back to 2, I'd expect to see a timestamp of (24*3600) - 3600 or 82,800 when I close the picker. Instead, I get 82,800,000 on close -- so it looks like the timestamp coming from the picker is at millisecond resolution. Finally, when I then save the page with 82800000 it converts to -3600 on reload. Ah, sounds like a great day! And this is a really minor suggestion anyway so please treat it as such. However, I do think that just having the day > 12 will still allow folks to see leading vs non-leading zeroes in the formats as the use of April as your month will give you either 4 or 04 so you can still see it. Only problem would arise if you can separately set the leading zeroes on both the day and month field -- but that doesn't seem to be the case from the formats in the list. Thanks Ryan.

This will be a fantastic feature to have.

Hi Teppo, I've some code in a private git repo that some folks here have access to (Antti is using it at present). It's a very young bit of code, based on an idea I had for a DSL for building webforms. Currently it is not tied into ProcessWire but does have a dependency on Will Bond's flourish library. To get a brief overview of what the DSL looks like please check out this gist. There are also a few (early) snapshots of it in action on flickr. I'm at the limit of invitations to that repository but if there is general interest I could be persuaded to move it onto github once I've got a couple of important items crossed off its to-do list. Whilst I'd love to see a graphical form builder based on this, it's a long way off yet. What you can easily do with it right now, is specify forms with it within your templates.

Hi Ryan, I'm trying this out now and it looks nice -- thank you! I've created a date of birth field using this field-type and added it to a template, setting it up to show on button press. However, I've hit a few issues with it so far... The year shown in the picker seems to be limited to this year +/- 10 years -- which is way too limited for a d.o.b field. I can't see any way to change that range, nor can I change it from the pop-up picker. I can change it by editing the date manually but that kind of negates the use of the picker. Attempting to save dates on, or prior to, the Unix epoch (01/01/70) fail silently when using the 04/08/12 input format and lead to a blank value in the field. As this doesn't happen in some of the other formats it doesn't seem to be a limit of the storage. If this is a consequence of a limit on the two-digit year input then this probably needs to raise a warning in the UI. The list of choices for the input and output date format currently use April 8th (in whatever format.) I'd suggest using an example date with a day number > 12 so that it is immediately obvious in the list which part of the date is the day. Using April 8th (04/08) is still ambiguous in some of those formats. Using something like April 24th would remove the ambiguity (04/24 or 24/04). More to come as I find it. Once again, thank you for working on this. Edited to add: Just a thought, but having this as a dev/experimental/nv branch would actually be useful (for me, at least, and maybe for other git users here too.)

<off-topic> I passed through Zagreb in 1999 & in 2000 on my way to the Vukovar & Orahovica areas of Croatia. I did some relief work out there. Despite the look in the photos, I really enjoyed my time there and met a lot of nice people. </off-topic>

Looking forward to the update Nikola. PS. How is it in Zagreb? It's been a while since I visited.

Alan, thank you. For the record, this is (99%+) Nikola's theme.

Thanks to Adamkiss, futura-delta now has a few more tweaks.