Leaderboard

Hi everyone, I refused to switch to another CMS for many years. I worked with a Perl based self-made CMS that produced no markup and provided the basic tools to fill templates with life. After being pointed to PW by a friend I finally made the switch since our CMS is dated and needs to much work to keep at a reasonable level (UTF8 support among things). PW is what we wanted our CMS to be! So I just released my first PW project into the wild: http://bmxrider.de I quickly found myself at home in PW since the workflow is just the one I was used to. I could never make myself use webforms to edit templates or even have my stylesheets in a DB. I used an approach similar to Ryan's described here: http://processwire.c...legate-approach , with a little modification to keep the amount of PHP in my templates to a minimum. My "home" template looks like this: <?php include('./tools.inc'); ob_start(); $news = $pages->find("parent=/news/,sort=-created,limit=3"); $videos = $pages->find("parent=/video/,sort=-created,limit=3"); $aktuelles = $pages->find("parent=/news/|/magazine/|/video/|/termine/,id!=$news|$videos,sort=-created,limit=5,"); include('./news.inc'); ?> <div id="content-sidebar"> <div id="content-left"> <?php include('./videos.inc');?> <?php include('./aktuelles.inc'); ?> </div> <?php include('./sidebar.inc');?> </div> <? $page->body = ob_get_clean(); include('./main.php'); ?> I'm already working on the next PW project and hope to switch all of our company's sites better sooner than later. Thanks for a great product and community! thomas Edit: I forgot to mention the PW credit: http://bmxrider.de/impressum/ ... and also forgot to mention that I my only problem with PW is that it's PHP based. Perl is just much more fun! But I guess I'll get over that ...

Well tough Smileys/emoticons are an easy fix - we can manually add conversions so they will work, though it is not standard to have a hyphen in them and I've used a lot of forum software - more standard without. Like I say though this can easily be solved by adding more variations in the admin so that is neither here nor there. Indentation is an annoying bug. It's on their list of things to fix. Seriously though? Neither of these are showstoppers and no software is perfect (apart from PW). Various editor improvements are coming in in v3.4 so I suspect a lot of the little quirks will be fixed then. It's interesting to note that the editor that you guys don't like is ckEditor (I think - might be TinyMCE even) but there are indeed quirks with their custom implementation. Compared to the previous software though I think it's a lot more useful overall. In summary, it would be a huge pain to switch again and the alternatives all have their own issues, bugs and drawbacks so I don't think either issue is enough to even consider it.

THANK YOU to you and Ryan I now have a much better approach to my problem

Hi, Diegonella. Try to use this module. Put it in your site/modules folder. Your fieldtype for transaction number has to be a textarea. After you've installed the module, select InputfieldTextareaLookup for your transaction number fieldtype on it's Input tab. Now your field will display as a paragraph so user won't change it. Please, let me know if it works as I didn't test it. Cheers! InputfieldTextareaLookup.module

Based on what I'm understanding from your last message, I think you should skip keeping the separate table. It just sounds like extra, unnecessary work, unless there's something more to this project that I don't yet understand. Instead, I think you should have your cron job execute a script that bootstraps ProcessWire and takes care of all the adding, updating and deleting of records consistent with the web service you are reading from. This is something that I think ProcessWire is particularly good at, because it's been designed for this from the beginning (it's something I have to do with a lot of my client work). Whether XML or JSON doesn't matter much, as PHP includes the ability to read from either type quite easily. Though like the other guys here, I generally prefer JSON just because it's less verbose and less fuss. If JSON, you'll pull the feed and use PHP's json_decode() to convert it to an array. If XML, you'll use PHP's SimpleXML to convert it to an array. Once you've got the array of raw data, you'll iterate through it and add, update, or delete pages in ProcessWire to make it consistent with the data you are pulling from the web service. Live, working example I think that the best way to demonstrate it is with a live, working example. This one uses the existing modules.processwire.com/export-json/ feed. You might also want to see the feed in human-readable mode to get a better look at the format. Below is a shell script that bootstraps ProcessWire, reads from that feed and maintains a mini "modules directory" site, on your own site. I made this feed so that it can be tested and used on a brand new installation using the basic profile (included with PW). If left how it is, it'll create a mini modules directory site below the '/about/what/' page and use the template 'basic-page' for any pages it adds. But you can run this on any ProcessWire installation by just editing the script and changing the parent from '/about/what/' to something else, and changing the template from 'basic-page' to something else, if necessary. This script assumes that the template used has 3 fields: title, body, and summary. The 'basic-page' template in PW's default profile already has these. If you adapt this for your own use, you'd probably want to change it to use more specific fields consistent with what you need to store on your pages. In this example, I'm just building a 'body' field with some combined data in it, but that's just to minimize the amount of setup necessary for you or others to test this… The purpose is that this is something you can easily run in the default profile without adding any new templates, fields, pages, etc. 1. Paste the following script into the file import-json.php (or download the attachment below). For testing purposes, just put it in the same directory where you have ProcessWire installed. (If you place it elsewhere, update the include("./index.php"); line at the top to load ProcessWire's index.php file). 2. Edit the import-json.php file and update the first line: "#!/usr/bin/php", to point to where you have PHP installed (if not /usr/bin/php). Save. 3. Make the file executable as a shell script: chmod +x ./import-json.php 4. Run the file at the command line by typing "./import-json.php" and hit enter. It should create about 95 or so pages under /about/what/. Take a look at them. Run it again, and you'll find it reports no changes. Try making some changes to the text on 1 or 2 of the pages it added and run it again, it should update them. Try deleting some of it's pages, and it should add them back. Try adding some pages below /about/what/ on your own, run it again, and it should delete them. import-json.php #!/usr/bin/php <?php // replace the path in the shabang line above with the path to your PHP // bootstrap ProcessWire. Update the path in the include if this script is not in the same dir include("./index.php"); // if you want to run this as a PW page/template instead, remove everything above (except the PHP tag) // save our start time, so we can find which pages should be removed $started = time(); // keep track of how many changes we've made so we can report at the end $numChanged = 0; $numAdded = 0; $numTrashed = 0; // URL to our web service data $url = 'http://modules.processwire.com/export-json/?apikey=pw223&limit=100'; // get the data and decode it to an array $data = json_decode(file_get_contents($url), true); // if we couldn't load the data, then abort if(!$data || $data['status'] != 'success') throw new WireException("Can't load data from $url"); // the parent page of our items: /about/what/ is a page from the basic profile // update this to be whatever parent you want it to populate... $parent = wire('pages')->get('/about/what/'); if(!$parent->id) throw new WireException("Parent page does not exist"); // iterate each item in the feed and create or update pages with the data foreach($data['items'] as $item) { // see if we already have this item $page = $parent->child("name=$item[name]"); // if we don't have this item already then create it if(!$page->id) { $page = new Page(); $page->parent = $parent; $page->template = 'basic-page'; // template new pages should use $page->name = $item['name']; echo "\nAdding new page: $item[name]"; $numAdded++; } // now populate our page fields from data in the feed $page->of(false); // ensure output formatting is off $page->title = $item['title']; $page->summary = $item['summary']; // To keep it simple, we'll just populate our $page->body field with some combined // data from the feed. Outside of this example context, you'd probably want to // populate separate fields that you'd created on the page's template. $body = "<h2>$item[summary]</h2>"; $body .= "<p>Version: $item[module_version]</p>"; foreach($item['categories'] as $category) $body .= "<p>Category: $category[title]</p>"; $body .= "<p><a href='$item[download_url]'>Download</a> / <a href='$item[url]'>More Details</a></p>"; $page->body = $body; // print what changed $changes = $page->getChanges(); if(count($changes)) { $numChanged++; foreach($changes as $change) echo "\nUpdated '$change' on page: $page->name"; } // save the page $page->save(); } // now find pages that were not updated above, which indicates they // weren't in the feed and should probably be trashed $expired = $parent->children("modified<$started"); foreach($expired as $page) { echo "\nTrashing expired page: $page->name"; $page->trash(); // move to trash $numTrashed++; } echo "\n\n$numAdded page(s) were added"; echo "\n$numChanged page(s) were changed"; echo "\n$numTrashed page(s) were trashed\n"; import-json.php.txt Running the script as a cron job: You can instruct your cron job to run the script and it should be ready to go. You may want to move it to a non web accessible location for more permanent use. You'll also want to update your bootstrap "include()" line at the top to have the full path to your ProcessWire index.php file, as your cron job probably isn't executing it from the web root dir like you were manually. Running the script as a template file: You can run this script as a template file on a page by removing the include() line and everything above it with this line: <pre><?php Place it in your /site/templates/ directory, add the template from PW admin, and create a page that uses it, then view it.

Modules directory: http://modules.processwire.com/modules/facebook-login/ Github: https://github.com/apeisa/FacebookLogin I didn't have any real reason to build this. I actually started to just browse the documentation of OAuth implementations and discovered that Facebook really does make this easy: http://developers.facebook.com/docs/authentication/server-side/ (header "Example" on bottom of the page) so I decided to implement it. It was also nice way to test the Ryan's method of module that creates page which executes itself (like Ryan's new ServicePages module).

This forum is buggin' the heck out of me... For one, it doesn't translate standard smilies... ;-) etc. ... becomes and ;-) etc. The WYSIWYG editor itself seems really quirky and buggy. Most annoying thing so far, is the tag, which only seems to work properly when inserted by pasting into the dialog box after clicking on the toolbar... If you edit your post (or preview it) afterwards, the indentation in the pasted code is lost, and you have to delete it and click the toolbar button and paste (or type in) the formatted code again.Using Chrome here, by the way. Is anyone else annoyed with this forum software? Doesn't seem very well suited for code anyway...

Soma, I find it too long. What about closestP($sel)? It's like a gangsta rapper's nickname Nobody will guess what it means.

Also you can get a page by its id even when it's unpublished

It will become second nature!

Hidden pages are excluded from all queries that return multiple pages. Things like find(), children() etc.. But since get() returns only single page it is assumed that you really want what you are looking for. So hidden pages are returned in get(), but not in finds (unless you explicitly say include=hidden).

WEll it was when I coudn't help to make page sunpublished already on running site that needed approval before going live. Could have done it differently but I just tried intuitively and it just worked... with a little smile.

Apeisa is right. But if you really can't help it and it is a must you can do this: $pages->get("/path/, include=all");

This could also work $pages->find("parent=/galleries/,categories_selected=$category, private=0"); parent= will look for direct children of /galleries/ only And to make it complete this if searching for nested children $pages->find("has_parent=galleriesID, categories_selected=$category, private=0");

You need to edit the home template, access tab and "activate" the new role for your home template (it will inherit from there to other pages too).

The PW version is always present in the footer. It's by intention there's no such info screen, and will hopefully stay like this. Anyway there's always the possibility to create your own very easily. Also if you like dashboards this might come soon

I wonder if there aren't better ways to check for compatibility and such. For example php version checking in install.php. There are existing functions for that: <?php if (version_compare(PHP_VERSION, '5.2.3', '>=')): ?> <?php echo PHP_VERSION ?> <?php else: ?> PW requires PHP 5.2.3 or newer, this version is <?php echo PHP_VERSION ?> <?php endif ?> <?php !extension_loaded('iconv') ?> <?php !function_exists('ctype_digit') ?> <?php !function_exists('json_decode') ?> etc

I'm not sure about the usefulness of this. I assume that on this kind of software people look for all the information on the website. These starting pages can get pretty annoying for someone that has to make lots of installs

Not yet, but I have strange feeling that we might have one sooner rather than later. Here are the latest news from that front: http://processwire.com/talk/topic/1237-history-module/#entry11098

$category in this code is a Page object (of Page class) so you can add and populate a property on the fly to the objects and use that on runtime. Like a virtual field that isn't saved to page.

Thanks for thinking and creating the code. This is exactly what I liked to achieve. Also very kind of you for the heads up on getting the data later on. Things are getting more clearer to me now. I think I got the configuration part almost ready. Since I already worked out the syncing part, I'm now ready to figure out how to make the selected templates fields to the MailChimp fields. Exciting times. Thanks again!

Should be fixed now I keep forgetting what that was like - now I'm in control of IT at my current job so have IE auto-updating every time a new version comes out (fortunately we don't run any legacy web apps).

Ah, this does make a lot of sense and a perfect fit for PW. Import the xml data feed entries as PW pages and keep up to date via a cronjob. In this case i wouldn't go for a separate database. Create a template "feed_item". Add fields to the template that map to corresponding data you want to import from the xml feed. You can add as many of your own fields to go next to that. For the actual importing/updating you can write something yourself with the PW API, i'm a noob so can't really help you there but i'm sure Ryan or other veterans can help. You could also take a look a look at this (alpha) module for some inspiration or maybe it works for your use case: http://modules.proce...ss-data-import/ http://processwire.c...ller/#entry1647 Using this approach you eventually have all of the feed data and your own added fields as PW pages/data. From there you can display and do with it whatever you want.

I think either is a good idea. But maintaining the files ready-to-translate is good just so that people don't have to click to add each of them manually. So I will plan to prepare that. Currently I locate the files with a grep command in the shell to find them all: cd wire grep -Rl '[>_][_nx](' * | uniq It's not a 100% as it may include 1 or 2 things it doesn't need to, but should catch everything translatable. core/Fieldtype.php core/Inputfield.php core/InputfieldWrapper.php core/LanguageFunctions.php core/SessionCSRF.php core/Wire.php modules/Fieldtype/FieldtypeComments/CommentForm.php modules/Fieldtype/FieldtypeComments/CommentList.php modules/Fieldtype/FieldtypeDatetime.module modules/Fieldtype/FieldtypeFloat.module modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module modules/Fieldtype/FieldtypeRepeater/InputfieldRepeater.module modules/Inputfield/InputfieldAsmSelect/InputfieldAsmSelect.module modules/Inputfield/InputfieldButton.module modules/Inputfield/InputfieldCheckbox.module modules/Inputfield/InputfieldCheckboxes/InputfieldCheckboxes.module modules/Inputfield/InputfieldDatetime/InputfieldDatetime.module modules/Inputfield/InputfieldEmail.module modules/Inputfield/InputfieldFieldset.module modules/Inputfield/InputfieldFile/InputfieldFile.module modules/Inputfield/InputfieldFloat.module modules/Inputfield/InputfieldForm.module modules/Inputfield/InputfieldHidden.module modules/Inputfield/InputfieldImage/InputfieldImage.module modules/Inputfield/InputfieldInteger.module modules/Inputfield/InputfieldMarkup.module modules/Inputfield/InputfieldName.module modules/Inputfield/InputfieldPage/InputfieldPage.module modules/Inputfield/InputfieldPageAutocomplete/InputfieldPageAutocomplete.module modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelect.module modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelectMultiple.module modules/Inputfield/InputfieldPageName/InputfieldPageName.module modules/Inputfield/InputfieldPageTitle/InputfieldPageTitle.module modules/Inputfield/InputfieldPassword.module modules/Inputfield/InputfieldRadios.module modules/Inputfield/InputfieldSelect.module modules/Inputfield/InputfieldSelectMultiple.module modules/Inputfield/InputfieldSubmit/InputfieldSubmit.module modules/Inputfield/InputfieldText.module modules/Inputfield/InputfieldTextarea.module modules/Inputfield/InputfieldTinyMCE/InputfieldTinyMCE.module modules/Inputfield/InputfieldURL.module modules/Jquery/JqueryWireTabs/JqueryWireTabs.module modules/LanguageSupport/LanguageParser.php modules/LanguageSupport/LanguageSupport.module modules/LanguageSupport/ProcessLanguage.module modules/LanguageSupport/ProcessLanguageTranslator.module modules/Markup/MarkupPageFields.module modules/PageRender.module modules/Process/ProcessField/ProcessField.module modules/Process/ProcessForgotPassword.module modules/Process/ProcessHome.module modules/Process/ProcessList.module modules/Process/ProcessLogin/ProcessLogin.module modules/Process/ProcessModule/ProcessModule.module modules/Process/ProcessPageAdd/ProcessPageAdd.module modules/Process/ProcessPageClone.module modules/Process/ProcessPageEdit/ProcessPageEdit.module modules/Process/ProcessPageEditImageSelect/ProcessPageEditImageSelect.module modules/Process/ProcessPageEditLink/ProcessPageEditLink.module modules/Process/ProcessPageList/ProcessPageList.module modules/Process/ProcessPageSearch/ProcessPageSearch.module modules/Process/ProcessPageSort.module modules/Process/ProcessPageTrash.module modules/Process/ProcessPageType/ProcessPageType.module modules/Process/ProcessPageView.module modules/Process/ProcessPermission/ProcessPermission.module modules/Process/ProcessProfile/ProcessProfile.module modules/Process/ProcessRole/ProcessRole.module modules/Process/ProcessTemplate/ProcessTemplate.module modules/Process/ProcessUser/ProcessUser.module modules/System/SystemUpdater/SystemUpdater.module modules/Textformatter/TextformatterEntities.module templates-admin/default.php templates-admin/topnav.inc

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).

@Soma are you running the latest? I'm not getting the notices here, doing the same thing. But if the notices are the same as the one you mentioned earlier, you don't need to worry as the condition is expected (though the notice isn't). I can add an extra check to prevent notices there, but want to make sure we're running the same version first. @Renobird there actually isn't such thing as a single image field to ProcessWire beyond that output formatting setting. All image fields are multi-image fields behind the scenes. If you enter "1" for max files, and output formatting is ON, then PW takes the first image from it and makes that the value of your $page->image field. So this does a good job of hiding the fact that all image fields are multi-image fields, because anyone that uses them in their regular site development never knows the difference. Likewise, PW's image inputs are monitoring that max files setting and limiting the input to just 1 image. In your case, you are trying to modify the field value, so you have to do the same thing that PW's inputs are doing. My suggestion would be to just set your "max files" setting to 0 so that you are developing with a multi image field. The maxfiles=1 is primarily for output convenience and in your case it's less convenient, so just stick to a multi image field and maybe go back later and adjust it back if you'd like to. This is the same approach PW takes, as any code administratively dealing with images/files is not considering that max files setting until just before output or input.