Leaderboard

We're proud to release our next and new version of ProcessImageMinimize (1.0) and the minimize.pw service. As mentioned here and on Twitter we've worked hard the last two weeks. The whole service has been rebuilt from the ground to support all the wanted features of the community. It's faster and more reliable, it works out-of-the box and has a new pricing structure. Images are processed async. behind the scenes The service works on a queue now. The service has new compressions scripts with higher quality output, especially for jpg files Build to scale: We can scale the servers in under a minute and handle thousands of images without any problems The module uploads the image and waits until the image is minimized. If activated, the module is now able to replace the original image file instead of creating a .mz variation If activated, the module automatically sends every new image to the service The module also works with apeisa Thumbnails module (CropImage), adding an getMzThumb($name) method While the image is beeing minimized, the module creates a temporary image. You can now set a quality of 100 on your image config without problems Direct link to the new dashboard at the module settings page The module now tells you if you have no volume left. The module also features the "classic" way of using the minimize()/mz() API method on PageImages. A new dashboard for customers features statistics and a quick overview You can see traffic, compression rates, saved bandwidth and more for each website using your license key. You can browse old invoices. New pricing structure The pricing is now based on a volume-based point system. Buy more volume(=images) for your license if you need them. No yearly price, no auto-renewal. And 1000 2000 images for free. A new website with an overhauled design and more feature information A new little minigame to compare minimized JPGs. All the old features like secured https connections, the fail-safe module and our image size reductions. The few existing customers are migrated with some extra volume You can read about the features at our new website. Ready to start? Download the module and read the documentation at Github For the first week, we will give all new users 2000 instead of 1000 images for free. So signup and try the service. This should be enough for alle small- to mid sized projects. If you need more than those two thousand images, you can buy another 5000 for around 19€ or 15000 for 39€. You don't have to update your license key on your module configuration after buying more volume. Paying for the service also removes the three site limit. Attached is a screenshot of our development dashboard and the new homepage. Please note, that we currently don't support a full ProCache installation. At least one PHP call on any site has to be made in order to activate the module. We have a plan to solve this problem but it's not implemented in this release. Also the stats don't display the correct amount of images sent for old customers, because we haven't tracked them before. Thanks for your previous feedback. Thanks to all the developers using our beta. You really helped us. We hope that we can provide a valuable service to the (growing) ProcessWire community. Feel free to ask any questions. Submit your first impressions of the service, the website or any other aspect. As mentioned before, we want to be open and honest.

PW is chosen, WP is followed.

This module is improved and extended successor to Version Control For Text Fields. It handles everything it's predecessor did -- providing basic version control features for page content -- and quite a bit more. Download or clone from GitHub: https://github.com/teppokoivula/VersionControl. This module requires ProcessWire 2.4.1 or later, mostly because of the file features, which require certain Pagefile and Pageimage methods to be hookable. There's no sensible way around this limitation; for those stuck with < 2.4.1, Version Control For Text Fields will remain a viable option. What does it do? While editing pages, fields with old revisions available show up with a new icon in their header bars. By hovering that icon you get a list of available revisions and by clicking any one of those the value of that particular field is reverted to that revision. No changes are made to page until you choose a revision and save the page, which means that you can keep switching between revisions to get an idea what's really changed without inadvertently causing any content to change. The module also adds a History tab to page edit. This tab opens a view to the history of current page in the form of "revisions" -- each of which is a group of changes to page fields processed during one page save (similar to revisions in various source control applications). There are three actions you can perform on these revisions: adding comments, live previewing what the page might've looked in that revision and restoring the page to specific revision. One specific feature that has been a big thing for me personally is support for file (and image) fields, as the original version control module felt rather incomplete without it. I'm hoping to take this a lot further performance, stability and feature wise, but as it stands right now, it's already included here and should be fully functional. Watch the video preview here I prepared a little screencast outlining most of this: http://youtu.be/AkEt3W7meic. Considering that it was my first screencast ever, I'd like to think that it wasn't that bad.. but I might give it another shot at some point, this time planning a bit before hitting "record" Upgrading from Version Control For Text Fields For those already using Version Control For Text Fields, I've added something extra. If you upgrade that module to it's latest version, you should see a new checkbox in it's settings screen saying "Don't drop tables during uninstall". If you check this, uninstall the module and then remove it's files (this is required in order to install Version Control), your old data should be automagically imported to Version Control. Import has only been tested with limited amounts of demo data. Proper tests are yet to come, so please be careful with this feature! Update, 21.6.2015: as of today, this module is no longer in beta. While all the regular warnings still apply (making changes, including installing any new modules, on a production site should always be considered risky) Version Control has gone through pretty extensive testing, and should be as stable as any other module out there.

If you have little to no web development skills, WordPress is probably best platform for throwing together pre-made themes and plugins to create something resembling a website or blog that is relatively straightforward to manage. But it won't necessarily be "good." Scalability, extensibility, customisation, performance, suitable page size, code quality, upgradability, integration... many things that are an afterthought, difficult to accomplish, or require even more mediocre plugins to address. I can't think of any projects where I would use WordPress over ProcessWire.

return $page->children(); in: Admin / Setup / Fields / Edit Field: name-of-the-field tab: Input (Selectable Pages) use custom PHP code to find selectable pages

I am sure some of you must have noticed my stumbling around in the dark while getting used to the ProcessWire system. Someday I hope to emerge as a user who brings more to the table than just silly newbie questions. I am sitting down with a mug of really good coffee so I thought I would offer my feelings and reactions to ProcessWire thus far… Quick background: I am a photographer with a long history in photojournalism and commercial work. I have also enjoyed doing web work for years. I built quite a few static sites before searching for a CMS system that felt like home. I must have tested about a dozen or so before spending some real time with Wordpress and then MODx. I liked Wordpress but the template system was awkward for me to me customize. I then found MODx Evo. I stuck with Evo for years and found it very designer friendly. I am not a code developer at all but Evo allowed me the flexibility to design static test pages using clean HTML and then create my Evo template from that foundation. MODx uses a system of combining placeholder code using Chunks, programmed Snippets and Template Variables (TVs) for dynamic forks in the road. Forgive me: I have never been well versed in web tech jargon. One of the features (or liabilities) with MODx is that it uses its own template language. When you deploy a Snippet you need a Snippet “Call” to set parameters on how the Snippet will function. Usually you would need a special template for the Snippet as well. This process is not totally intuitive and has its own learning curve. Then along came the entirely new branch of MODx called Revolution, or Revo for short. Revo was more powerful but also more complex. The nice thing with Revo is that you could spend more time away from the root folder or using an FTP client to upload and install Snippets. The Package Management system is a powerful means of installing and updating the various Snippets and plugins. Updating these building blocks in Evo is more of a pain; manual copy and paste effort required. What I did not like with Revo is that much of the placeholder and template syntax changed from Evo. The changes were subtle but deadly if you confused the two. The main issue I have with Revo is how slow the Manager (admin) system is. The amount of stuff (very techie term here) in Revo is overwhelming. Some of my clients who used the Revo Manager sporadically would always forget how to do things. To be honest I would have the same issue on occasion. With MODx we had Evo, then Revo, then the whole cloud system and now MODx III. It sort of gets confusing. To counter this the forum now has a zillion sections that cater to all the MODx project branches. But I find doing a search on my issues or questions revealed some confusing links to information that focuses on a different branch or is outdated to the system I am working with. I guess this last year was a difficult year for MODx: growing pains and money, etc. The whole technology of Revo, the Cloud and the loss of some of its main core programmers (Shaun McCormick) has created some signal-to-noise-ratio issues. Last year was a terrible year for me personally as well. The joy of buying a new project house was crushed by the death of my father and my only sibling (in South Africa) in the space of just four months. Coming out of this fog I sought of stumbled on some interesting chatter about MODx users switching to ProcessWire. The rest of this quick moving journey has been interesting to say the least. My reaction to PW has been filled with both initial confusion and admiration. I thought my not knowing any PhP was going to be a deal breaker. I sort of had initial writer’s block with the blank page. The PW installation would go well, but then what? But after playing around with several local test installs I can see how liberating and powerful the PW API, the template system and Fields really are. I am slowly picking up some basic use of PhP statements. Doing so is more valuable and efficient than the MODx learning curve with it’s proprietary template syntax. I suspect my working knowledge of the PhP that will make using PW easier will only grow with time. That is my hope for sure. The thing I like about the PW Admin is the speed and the whole weight of the backend. Compare the jQuery Admin to the heavy, heavy MODx Revo Manager and there is no contest. It works better on the iPad as well. My clients have commented on how much “stuff” there is in the Revo Manager. I can’t wait to show them how fast and simple the PW Admin is by comparison. One of my issues is letting MODx go. The community has been great. I cant tell you all how much I admire and appreciate folks like Susan Ottwell, Bob Ray, Jay Gilmore and countless others. Susan has over 20,000 posts on the MODx forum. Just about all of them are consistently helpful and insightful. Being a heavy forum contributor can lead to one’s becoming impatient and suffering from burnout, but Susan’s helpful attitude has been amazing. But my heart tells me that I am better suited to learning ProcessWire rather than the awkward mix of MODx Evo and Revo that I have been using to this point. I think I am also trying to duplicate some MODx procedures when I work with my PW test projects. I think that time will be on my side as I become more comfortable doing things the “ProcessWire way”. Anyway, I am not sure where I am going with this, I just wanted to offer my $.02 and to say how grateful I am with all of you who have shown patience with my initial learning. Cheers, Max

I hear with ravensburger you can have beautiful paintings on your wall too, some people will be satisfied with that. Other people prefer a Dali, da Vinci or van Gogh. I prefer a framework where i can decide how to do the things i want to build, not the other way around. ProcessWire gives me that freedom. Like Craig mentions i wouldnt knwo any project i build in the past two year or so where i would use Wordpress over ProcessWire

If you want queries that PW did while inserting or updating those pages, in debug mode use $database::getQueryLog(). That'll return you the full query log, from which you can grab just the parts you need. Another method would be updating database tables manually with custom SQL, but then you'd have to update/insert at least pages (including sort fields), pages_access, pages_parents (in some cases) and each field-specific table individually. You said that "[...] insert and update certain images and [...]". Depending on various factors (amount of images, file sizes, resize settings etc.) updating and/or fetching images could be very expensive operation. Just saying.

Since you guys asked for it, I'll take a stab at a case study on the development process. Most of the development was done in about a week and a half. I started with the basic profile, but it ended up being something somewhat similar to the Blog profile in terms of how it's structured. Below I'll cover some details on the biggest parts of the project, which included data conversion, the template structure, the front-end development and anything else I can think of. Data Conversion from WordPress to ProcessWire One of the larger parts of the project was converting all of the data over from WordPress to ProcessWire. I wrote a conversion script so that we could re-import as many times as needed since new stories get added to cmscritic.com almost daily. In order to get the data out of WordPress, I queried the WordPress database directly (my local copy of it anyway) to extract what we needed from the tables wp_posts for the blog posts and pages, and then wp_terms, wp_term_relationships, and wp_term_taxonomy for the topics and tags. WordPress stores its TinyMCE text in a state that is something in between text and HTML, with the most obvious thing being that there are no <p> tags present in the wp_posts database. Rather than trying to figure out the full methodology behind that, I just included WP's wp-formatting.php file and ran the wpautop() function on the body text before inserting into ProcessWire. I know a lot of people have bad things to say about WordPress's architecture, but I must admit that the fact that I can just include a single file from WordPress's core without worrying about any other dependencies was a nice situation, at least in this case. In order to keep track of the WordPress pages imported into ProcessWire through repeat imports, I kept a "wpid" field in ProcessWire. That just held the WordPress post ID from the wp_posts table. That way, when importing, I could very easily tell if we needed to create a new page or modify an existing one. Another factor that had to be considered during import was that the site used a lot of "Hana code", which looked like [hana-code-insert name="something" /]. I solved this by making our own version of the Hanna code module, which was posted earlier this week. Here's an abbreviated look at how to import posts from WordPress to ProcessWire: $wpdb = new PDO("mysql:dbname=wp_cmscritic;host=localhost", "root", "root", array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'UTF8'")); $posts = wire('pages')->get('/posts/'); $sql = " SELECT * FROM wp_posts WHERE post_type='post' AND post_status='publish' ORDER BY post_date "; $query = $wpdb->prepare($sql); $query->execute(); while($row = $query->fetch(PDO::FETCH_ASSOC)) { $post = $posts->child("wpid=$row[ID]"); // do we already have this post? if(!$post->id) { // create a new post $post = new Page(); $post->template = 'post'; $post->parent = $posts; echo "Creating new post...\n"; } $post->of(false); $post->name = wire('sanitizer')->pageName($row['post_name']); $post->title = $row['post_title']; $post->date = $row['post_date']; $post->summary = $row['post_excerpt']; $post->wpid = $row['ID']; // assign the bodycopy after adding <p> tags // the wpautop() function is from WordPress /wp-includes/wp-formatting.php $post->body = wpautop($row['post_content']); $post->save(); echo "Saved post: $post->path\n"; } What I've left out here is the importing of images, topics, tags, and setting the correct authors for each post. If anyone is interested, I'll be happy to go more in depth on that, but didn't want to overwhelm this message with code. Template File Structure This site makes use of the $config->prependTemplateFile to automatically include the file _init.php before rendering a template file, and $config->appendTemplateFile to automatically include the file _main.php after. So the /site/config.php has this: $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; You may recognize this as being the same setup from the Skyscrapers profile. The _init.php includes files containing functions we want to be available to all of our templates, and set default values for the regions we populate: /site/templates/_init.php /** * Include function and hook definition files * */ require_once("./includes/render.php"); require_once("./includes/hooks.php"); /** * Initialize variables populated by templates that get output in _main.php * */ $browserTitle = $page->get('browser_title|title'); $body = "<h1>" . $page->get('headline|title') . "</h1>" . $page->body; $side = ''; $renderMain = true; // whether to include the _main.php file The includes/render.php file that is included above includes several functions for generating markup of navigation and post summaries, or any other shared markup generation functions. Examples are renderPost(), renderNav(), renderTags(). This is similar to the blog.inc file from the Blog profile except that I'm letting these functions generate and return their own markup rather than splitting them into separate view files. I personally find this easier to maintain even if it's not as MVC. The includes/hooks.php sets up any hooks I want to be present for all of my templates. I could have also done this with an autoload module, but found this to just be a little simpler since my hooks were only needed on the front-end. The main hook of interest is one that makes all posts look like they live off the root "/" level rather than "/posts/" (where they actually live). This was in order to keep consistency with the URLs as they were in WordPress, so that the new site would have all the same URL as the old site, without the need for 301 redirects. /site/templates/includes/hooks.php /** * This hook modifies the default behavior of the Page::path function (and thereby Page::url) * * The primary purpose is to redefine blog posts to be accessed at a URL off the root level * rather than under /posts/ (where they actually live). * */ wire()->addHookBefore('Page::path', function($event) { $page = $event->object; if($page->template == 'post') { // ensure that pages with template 'post' live off the root rather than '/posts/' $event->replace = true; $event->return = "/$page->name/"; } }); Our /site/templates/_main.php contains the entire markup for the overall template used site wide, from <html> to </html>. It outputs those variables we defined in _init.php in the right places. For example, $body gets output in the <div id='bodycopy'>, $side gets output in the right <aside>, and $browserTitle gets output in the <title> tag. /site/templates/_main.php <?php if($renderMain): ?> <html> <head> <title><?=$browserTitle?></title> </head> <body> <div id='masthead'> // ... </div> <div id='content'> <div id='bodycopy'><?=$body?></div> <aside id='sidebar'><?=$side?></aside> </div> <footer> // ... </footer> </body> </html> <?php endif; ?> We use the rest of the site's template files to simply populate those $body, $side and $browserTitle variables with the contents of the page. As an example, this is an abbreviated version of the /site/templates/post.php template: /site/templates/post.php // functions from /site/templates/includes/render.php $meta = renderMeta($page); $tags = renderTags($page); $authorBox = renderAuthor($page->createdUser); $comments = renderComments($page); $body = " <article class='post post-full'> <header> <h1>$page->title</h1> $meta </header> $page->body $tags $authorBox $comments </article> "; if(count($page->related)) { $side = "<h4>Related Stories</h4>" . renderNav($page->related); } What might also be of interest is the homepage template, as it handles the other part of routing of post URLs since they are living off the root rather than in /posts/. That means the homepage is what is triggering the render of each post: /site/templates/home.php if(strlen($input->urlSegment2)) { // we only accept 1 URL segment here, so 404 if there are any more throw new Wire404Exception(); } else if(strlen($input->urlSegment1)) { // render the blog post named in urlSegment1 $name = $sanitizer->pageName($input->urlSegment1); $post = $pages->get("/posts/")->child("name=$name"); if($post->id) echo $post->render(); else throw new Wire404Exception(); // tell _main.php not to include itself after this $renderMain = false; } else { // regular homepage output $limit = 7; // number of posts to render per page $posts = $pages->find("parent=/posts/, limit=$limit, sort=-date"); $body = renderPosts($posts); } The rest of the site's template files were handled in the same way. Though most were a little simpler than this. Several were simply blank, since the default values populated in _init.php were all that some needed. Front-end development using Foundation 4 The front-end was developed with the Foundation 4 CSS framework. I started with the Foundation blog template and then tweaked the markup and css till I had something that I thought was workable. Then Mike and I sent the _main.php template file back and forth a few times, tweaking and changing it further. There was no formal design process here. It was kind of a photoshop tennis (but in markup and CSS) where we collaborated on it equally, but all under Mike's direction. After a day or two of collaboration, I think we both felt like we had something that was very good for the reader, even if it didn't originate from a design in Photoshop or some other tool like that. I think it helps a lot that Foundation provides a great starting point and lends itself well to fine tuning it the way you want it. I also felt that the mobile-first methodology worked particularly well here. Comments System using Disqus We converted the comments system over to Disqus while the site was still running WordPress. This was done for a few reasons: Disqus comments provide one of the best experiences for the user, in my opinion. They also are platform agnostic, in that we could convert the whole site from WP to PW and not have to change a thing about the comments… no data conversion or importing necessary. Lastly, ProcessWire's built-in comments system is not quite as powerful as WordPress's yet, so I wanted cmscritic.com to get an upgrade in that area rather than anything else, and Disqus is definitely an upgrade from WP's comments. In order to ensure that Disqus could recognize the relations of comment threads to posts, we again made use of that $page->wpid variable that keeps the original WordPress ID, and also relates to the ID used by the Disqus comments. This is only for posts that originated in WordPress, as new posts use a ProcessWire-specific ID.

Here's a video of a module we're working on that I thought you guys might like. The module, Lister, provides a different type of Page List than the tree that you usually interact with in ProcessWire. It gives you a table of pages with customizable columns, filters and actions. Rather than try to explain what it does, I figured I'd show you. This module also uses a new (soon to be released) Inputfield invented by Apeisa, developed by me, and sponsored by Avoine, called InputfieldSelector – it's what you see on the configuration screen as well as the Filters tab. I recommend bumping up the size/quality to 720p so that you can properly see everything. The video has no sound... I tried to do one with narration, but that didn't work out.

I can't say I use PW for a long time, but I as a basic php coder/designer (newbie) I am definitely sold to PW. Can't tell you enough how painful Wordpress and Joomla are. True there are many plugins available, but none of them are same preferred coding. On top of that they all interfere with CSS because of integration in these plugins. Many times, even if you find a nice theme, you end up searching which part was doing what that you want to modify. In the time I have used PW I never once looked back on other CMS because PW give me the feeling truly anything is possible. Besides, I like the learning curve of it. I also called some payment providers Mollie/iDeal to see if integration is possible, and of course it is. That will be the next fase in my website design. Thinking SEO, layout, coding, security, any kind of website - PW is my favorite!

@darrenc The way you submit enhancements/fixes to a project on github is to first fork the project, then make the changes to your forked version, then submit a pull request to the original project. Ryan will receive notification of your PR and he can then review and accept the changes as is, or modify them as needed. Obviously it's hard to know whether your changes will be coded the way Ryan would prefer or not. Depending on the change it might be just as productive to simply submit an issue asking for the enhancement. You could look through some of the previous PR and issues and see if you think your enhancement suggestion and your coding quality would make it better suited to one approach or the other. Sorry, not a definitive answer, but hopefully helpful.

Philipp this is great news. The service really has expanded. Many improvements are in.

The instructions for this module say to use the path relative to your templates directory, eg: styles/mystyles.css or scripts/myscript.js There is a setting in the module config: "Allow Directory Traversal: Enable the directory traversal option to make it possible to add files from outside of the template folders. (../)" which you can use if you need to access css and js files above the templates directory, but otherwise they should all be in subfolders of "templates" and linked to with a path relative to templates. Make sense? EDIT: not relevant to this module, but path vs url - depends on what is being done with the file being linked to. If it's a css or js file, typically you are going to want the url option. The path option is the full server path to the file which is useful for php operations on files, but no good for front-end display/calling of files.

I really feel stupid to ask this, I hope I could have deleted this post. Its simple doing page->parent = new_parent

Important note: Please remove the older version of the ProcessImageMinimize module before installing the new version. If you experience database problems after updating the older version, please run the following SQL query on your database: CREATE TABLE process_image_minimize (image_id VARCHAR(255) NOT NULL PRIMARY KEY, reference VARCHAR(24), state INT(2) NOT NULL, processed VARCHAR(255), force_replace INT(1), created_at INT(11) UNSIGNED NOT NULL, updated_at INT(11) UNSIGNED NOT NULL); CREATE UNIQUE INDEX minimize_api_reference ON process_image_minimize (reference) USING BTREE; CREATE INDEX minimize_api_state ON process_image_minimize (state) USING BTREE; This will manually create the necessary database table.

Those modules are purely written for this setup. You take them out of the site then they won't function. I don't see value for those in Modules section, that list should be clean. (less is more) - If you want to get insight of the working for the tabs (ProcessPageEdit::buildForm) go for Soma's TemplateNotes - For the Process module, take a look at ProcessHello (ryan's great howto do process modules ) In basic, modules are not hard to do. When you know what to hook, and you know how to get the $event object and you know how to give it back, then it's not much different from working in your templates. There are many modules around here. And in a lot of circumstances others already have done these three things for you. If you take those as starting point, you only have to write some basic PHP. Don't let the word .module "fog" your mind

Ok, so I have added support for automatic populating the video title into the image description field for both Youtube and Vimeo. Not sure how much longer this method will work with Youtube, but I think it's simpler to keep using v2 of their API for the moment. I implemented both cURL and file_get_contents methods for Youtube and simplexml_load_file for Vimeo. Let me know how it works for everyone and I'll tweak methods if needed.

Very nice work. I've been actively following this post. The amount of help provided on this forum is outstanding.

Ralf needed a parental Pedigree and I helped him to setup a very basic site. I quite liked the building of it and it resulted in doing 'to much' just for fun. I Asked Ralf if I could make it to a site profile so that someone else could profit from it to. Horse template Family Tab (Horse template) Pedigree (d3js) Unfinished Horse ( Horses created by Pagefield, but not yet edited ) Menu building /processwire Menu front-end / Download The Profile: pedigree_profile.zip

Thanks for the replies. I decided to purchase the Form Builder. I'm not sure if I'll use it anytime soon, but I feel it's important to put a bit of money back into PW if we can manage it. I think I'll have a look into creating a few functions soon to tidy up my code a bit. I've just spent the last few days reformatting my initial sloppy code. But I'm still loving it. This is the longest time I've spent doing any kind of programming since Amiga E on the er, Amiga.

On the popular gaming plattform PlayCatan (http://playcatan.com/), we use Processwire as CMS for all help pages, FAQ, game manuals and news. The contents are embedded as single pages via colorbox.js and iFrames, so the do not interfere with a potentially running Canvas game. We use Markdown and some custom tricks for the content editors. So far it is a great pleasure

Hi and welcome to Processwire. Sounds like you've dived in and are having a good play around. The fun thing with PW is there's never one particular way to do things, and you can use it as a framework and bend it to your will. Looking forward to reading more from you. Enjoy the journey

I didn't post anything for the pedigree. The pedigree part can be done later on the horse template. Don't overcomplicate things, just build things from the bottom up. The part I posted goes till you have a list of horses. (Pagearray) That array you can loop and link to the individual horse. ( So forget about the pedigree till the navigation structure is complete. ) These are in the group contexts just search filters: - a checkbox, named: horse_owned, (horse template should also have horse_owned checkbox, checked means you're owning the horse ) - a checkbox, named: for_sale, (horse template should also have for_sale checkbox, checked means you're willing to sell the horse ) - an Inputfield type Page, see structure above name the field 'types' (IS this Field for the Select "- a Page field, [stallions, Broodmare, Colt, etc..]" ) Inputfield type Page in the horse template just to identify what horse type it is. But it the Group template it is used as a filter. (the code is fro the group template) Here you gonna test if the UrlSegments matches the checked horses in the group template. This way you can control which horses to list. If your navigation setup is complete, I can help you to setup the pedigree function inside the horse template. I would advise you to leave it alone for now.

Create this structure: [ later on used for the Inputfield type Page (Multiple) ] Home | +-- Types (template: types) | +-- Stallions (template name: type) | +-- Broodmare (template name: type) | +-- Colt (template name: type) | +-- Foals & youngs (template name: type) | +-- etc. // both templates need no template files To the template 'type' you add a textarea with a WYSIWYG editor if wished. On the Horse Template 1 ) a checkbox, named: horse_owned, 2 ) a checkbox, named: for_sale, 3 ) an Inputfield type Page, see structure above name the field 'types' Group template ( Our Horses & Horses for sale ) Assign the same fields as above to this page. 1 ) a checkbox, named: horse_owned, 2 ) a checkbox, named: for_sale, 3 ) an Inputfield type Page, with the structure drawn above ( Name it types ) The real purpose of these fields in the 'group' template are for building the search query to the horses you want to list. (Tell you later more about this) Enable urlSegments to this template. Create a Page with the group template named 'Our Horses' Check the checkbox 'horse_owned', so it has the value of 1 Leave the checkbox 'for_sale' unchecked. For the 'types' field select: [x] Stallions [x] Broodmare [x] Colt [ ] Riding Horses [ ] Foals and young horses Those checked pages are used for the urlSegments. Basic structure of the PHP file could look like this: $segment = $input->urlSegment1; $types = $page->types; if ($input->urlSegment1) { $name = $sanitizer->name($input->urlSegment1); $type = $pages->get("template=type, name=$name"); if ($types->has($type)) { echo "<h1>{$type->title}</h1>"; // echo $type->body; // assumed the textarea added is called body // scaffold the search query $query = array( 'template' => 'horse', 'types' => $type, 'horse_owned' => $page->horse_owned, 'for_sale' => $page->for_sale, 'limit' => 10 ); $query = array_filter($query); // remove all boolean false elements from array $string = ''; foreach ($query as $key => $value) $string .= "{$key}={$value}, "; $string = rtrim($string, ", "); $horses = $pages->find($string); if(count($horses)) { echo "jay we have the horses"; } else { echo "Sorry, at the moment we don't have the horse that you're lookin for." } } else { throw new Wire404Exception(); } } else { echo "<ul>"; foreach ($types as $type) { echo "<li><a href='{$page->url}{$type->name}/'>$type->title</a></li>"; } echo "<ul>"; } (not fully tested, so could have a bug or 2 )

I needed to update this module as I needed the enhanced functionality. ( putting images, audio etc in the RSS ) my tip: Love ProcessWire

Well I can give you the parser for free: Just put the "wp-import" folder in the same directory as "site" and "wire" and add the name of your xml file in the folders "index.php". --- And if you still prefer a real module you can support development via (for example) PayPal mail@nico.is --- Edit: Forgot to add the attachment wp-import.zip

How complex can it be if it's just posts? You also have the PHP's own XML parser that I find quite easy to work with. Or maybe you can even convert that XML to CSV and use Ryan's module to import it.

There are multiple ways to handle XML in PHP, but for simplest tasks (reading) I prefer SimpleXML. After that it's all about iterating posts in XML and creating matching pages for them via API. Hope this helps a bit. PS. I did notice that you posted this on jobs board, but still wanted to point out that the XML part is really nothing to be worried about. If you're familiar with handling ProcessWire content via API, this should be a piece of cake, unless post data from WP is very complex

I would try to work as much with what PW gives you and adapt the CSS, I think there's even an responsive theme in Formbuilder... but could be wrong. If you really need to adapt the HTML markup and CSS classes used by the InputfieldWrapper you can. As in this thread already mentioned: from the InputfieldWrapper.php core class /** * Markup used during the render() method - customize with InputfieldWrapper::setMarkup($array) * */ static protected $defaultMarkup = array( 'list' => "\n<ul {attrs}>\n{out}\n</ul>\n", 'item' => "\n\t<li {attrs}>\n{out}\n\t</li>", 'item_label' => "\n\t\t<label class='ui-widget-header' for='{for}'>{out}</label>", 'item_content' => "\n\t\t<div class='ui-widget-content'>\n{out}\n\t\t</div>", 'item_error' => "\n<p><span class='ui-state-error'>{out}</span></p>", 'item_description' => "\n<p class='description'>{out}</p>", 'item_head' => "\n<h2>{out}</h2>", 'item_notes' => "\n<p class='notes'>{out}</p>", ); Using the form inputfield object you could simply $form->setMarkup(array('list' => "<div {attrs}>{out}</div>")); The same exists for the classes used. But at the end I don't know if messing with it helps. Rendering form fields: As I said earlier, it's always possible to render a certain field explicit. echo $form->get("name")->render(); You could even use the form building method in this thread starting post and render fields where you like. There'll be still markup being outputed depending on the inputfieldtype, but maybe allows for more flexibility. $showform = true; $form = $modules->get("InputfieldForm"); $field = $modules->get("InputfieldEmail"); $field->attr("name", "email"); $field->label = "Email"; $form->append($field); if($input->post->submit) $form->processInput($input->post); if($form->getErrors()) { $showform = true; } else { $showform = false; // form valid, do something } if($showform) { echo "<form action='#' method='post'>"; echo "<div class='row'>" . $form->get('email')->render() . "<div>"; ... } Anything is possible, just use what you need. Think it's almost same as you would work with fields or pages.

<form action="/actions/post-comment" method="post"> You need a trailing slash, I think Pw does a redirect and you loose the POST request. Please try this once again and make sure it does still not work. Edit: To be bullet proof: <form action="<?php echo $pages->get(ID_OF_PAGE)->url; ?>" method="post">

The key is: "title client.title" HF

Hi Jason, if you're doing it just for a few pages, you don't need any module/plugin; you can do this simply by using templates! Create field 'redirectTo' – customizable, of course Set that field to be 'single page', and select the inputfield you wish Create template 'redirectPage' – again, custom put following code in your template file Create page that links to original page you've made your virtual page Code for your template: <?php /* * Template: redirectPage * * Used to redirect URL adress to other page with 301 HTTP code */ $session->redirect( $page->redirectTo->url ); I actually use this at least once each site.