Leaderboard
Popular Content
Showing content with the highest reputation on 05/02/2012 in all areas
-
You guys got me thinking about this form builder and now I can't get my mind off it. I've taken a look at Netcarver's and Zend's form classes, and both look awesome. I'm particularly impressed by Netcarver's system and hope to be putting it to use sometime soon. Focusing on this a lot the last few days also made me realize that a PW formbuilder and the existing Inputfields have a lot of common ground. Enough so that it probably doesn't make sense for a PW formbuilder to venture outside of that. But it does make sense to upgrade PW's Inputfield system to make it more flexible consistent with the needs of a formbuilder. It's easier to maintain and support if there is one system rather than two. It wouldn't replace a system like Netcarver's or Zend's, but would provide a good middle ground for the less complex form needs. As a first step, I figured I'd see how well Inputfields would adapt for the sort of portability a formbuilder would need. The goal was to be able to take an array or JSON string, and have it render as a form using PW Inputfields, as they are now. This is something I'd not tried before, but the first step we'd need in order to easily store a form schema for a form builder. A small 20-line recursive function takes that array and dynamically creates a form composed entirely of PW Inputfields. All that's left to do is call $form->render(); I built a small test form and had success with it. Yesterday a friend needed help on a larger form, so decided to put the strategy to work there too. Here is the result. Not a pretty form by any stretch, but I was happy with how easily it all went together, and now getting me enthusiastic about going further with full blown form builder. As an example, here's the PHP array schema for my test form: $formArray = array( 'personal_info' => array( 'type' => 'Fieldset', 'label' => 'Personal Information', 'children' => array( 'first_name' => array( 'type' => 'Text', 'label' => "First Name", 'columnWidth' => 50, 'required' => true, ), 'last_name' => array( 'type' => 'Text', 'label' => "Last Name", 'columnWidth' => 50, 'required' => true ), 'email' => array( 'type' => 'Email', 'label' => "Your Email", 'columnWidth' => 50, 'required' => true ), 'phone' => array( 'type' => 'Text', 'label' => "Your Phone", 'columnWidth' => 50, 'required' => true ) ) ), 'customer_feedback' => array( 'type' => 'Fieldset', 'label' => 'Share Your Feedback', 'children' => array( 'store_location' => array( 'type' => 'Select', 'label' => 'What store location did you visit?', 'options' => array( 'ATL' => 'Atlanta, GA', 'CHI' => 'Chicago, IL', 'NYC' => 'New York, NY', 'SFO' => 'San Francisco, CA' ) ), 'would_visit_again' => array( 'type' => 'Radios', 'label' => 'Would you visit that location again?', 'options' => array( 'Y' => 'Yes I would', 'N' => 'No I would not' ) ), 'comments' => array( 'type' => 'Textarea', 'label' => 'Comments or Questions?', 'description' => "We'll respond right away!", 'rows' => 5 ) ) ), 'submit' => array( 'type' => 'Submit', 'value' => 'Submit Your Feedback!' ) ); That schema can be converted to/from JSON just by calling json_encode/json_decode on it, and gives us exactly the portability I'd want out of it. Given that this can be translated to a full form of Inputfields with a tiny function (arrayToForm), I figured that's a great first step towards an interactive formbuilder. Here's what the template code looks like: $form = arrayToForm($formArray); if($form->isSubmitted()) { $body = "<html><body>" . $form->renderValues() . "</body></html>"; $headers = "Content-type: text/html; charset=utf-8\nFrom: " . $form->get('email')->value; mail('me@domain.com', 'Form Submission', $body, $headers); echo "<h2>Thanks, your form was submitted!</h2>"; } else if(count($form->getErrors()) { echo "<h2>Fix the fields in red and try again.</h2>"; echo $form->render(); } else { echo $form->render(); } That's how I'm doing it now, but stuff like the above would obviously be integrated into a FormProcessor class so that you only need to call 1 function to display/process a form, and you could store and browse the results in a DB rather than just emailing it. Inputfields need to be upgraded so that all the structural markup is customizable. I'd probably want the default render output to be structured around fieldsets rather than lists, and be something that one wouldn't necessarily need any prerequisite CSS/JS except for progressive enhancement. Other upgrades would be more validation options for the basic Inputfields. The nice thing is that any upgrades would benefit all of PW, not just the formbuilder. The next test/proof-of-concept will be to make the creation of that $formArray interactive from the admin (with a Process module).6 points
-
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.2 points
-
In case the mistake I just made helps anyone else... I wanted to display a file on a page with a default install of PW. So I added a field of type 'file' and rather unimaginatively called it "Files". Via the admin I then edited a page and added a file and description to a page and added: foreach($page->files as $file) { echo "<p>Test output: {$file->description}</p>"; } to the template. The result was nothing new displayed :/ Confused I tried lots of things, then wondered if by using the name "Files" for my field I had stumbled on a reserved word that didn't work. Of course everyone will have seen my error, the field I added was "Files" and the field I am querying is "files". Lesson well and truly learned (I hope )1 point
-
I'm creating a family history website, and after looking at the software available for the purpose (I'd have to remove a lot of things I don't need), decided to see how ProcessWire might be used for this. I don't really need a formal family tree structure in the back end as long as I can figure out a reasonably good fit for indicating family relations. Right now I have a flat grouping of pages for individuals under a page for each family name. I was thinking I could indicate parents, children and spouses via page fields. Can anybody see obvious flaws in this, or give me an idea of an alternative? I just couldn't think of a way of getting away from using page fields to indicate things like spouses, even if I used the page tree to indicate children. I don't want to get too serious about replicating a genealogy app because I don't need all of the crazy features those have, but I would like to be able to at least display hierarchichal family data on the front end. Thanks for any ideas!1 point
-
Setting PW to advanced mode (which I actually didn't even realize was there!) didn't do it - but importing the fields from the admin template did the trick. Thanks, guys!1 point
-
Another way to do it, just using PHP string functions: $out = "<ul>"; foreach($parents as $parent) { $out .= "<li><a href='{$parent->url}'>{$parent->title}</a></li>!"; } $out = str_replace('</li>!', '></li>', rtrim($out, '!')) . '</ul>';1 point
-
I don't know if you know that variables/namings in php can't contain a dash "-". So also this is true to a field name in PW. So things like: $page->my-repeater-area doesn't work. I'm sure you know it, but typed it wrong in your post.1 point
-
It seems to be missing from Field selection, so you probably need to use API for that (might be available on advanced mode => edit config.php and try then). One way could also be duplicating the admin template, so your new template would have Process field assigned.1 point
-
Welcome to the forum Ben! You have to iterate over the repeater, and output each field: foreach($page->my_repeater-area as $building) { echo "<p>{$building->building_description}</p>"; echo "<img src='{$building->building_image->url}' alt='{$building->building_image->description}' />"; echo "<p>{$building->building_text}</p>"; }1 point
-
Thanks ryan. It was indeed the case that the server wasn't reading the .htaccess file. Told the web host and now it is working again.1 point
-
I'm having the same problem with a new website. I moved PW from my testing server to a subdirectory of the new server because i don't want to replace the old site for now. It shows the homepage, but when I press the links, I get a 404 from the server. I asked the server if mod-rewrite is on, and they told me to add "RewriteEngine On" to my htaccess file... not helpful at all... I added some random characters inside "<IfModule mod_rewrite.c>" on PWs htaccess, and it does throw a 500 error. Another thing I just did: I moved PW files to the root and put the old site files on a folder (thre wasn't any htaccess file on the root). PW shows me the homepage, but when I go to subpages, instead of a 404 I get a 500 (??)... back to the subfolder, I get the 404 again. EDIT: I solved this issue by uncommenting this line on the .htaccess: # RewriteBase / (on the subfolder I added RewriteBase /subfoldername/)1 point
-
This is the method that I use and find it really handy. The main.php file for processwire.com has this at the top: if(strpos($page->body, '<p>https://www.youtube.com') !== false) { $replacement = '<iframe width="640" height="360" src="https://www.youtube.com/embed/$1" frameborder="0" allowfullscreen></iframe>'; $page->body = preg_replace('#<p>\s*https://www.youtube.com/watch\?v=([^\s&<]+).*?</p>#iu', $replacement, $page->body); }1 point
