Leaderboard

I'm planning to bring the same import/export system that's in FormBuilder to Fields and Templates.

Here is a recent site done in processwire: http://licoriceensemble.com/ modules used include formbuilder procache cropimage version control for text fields after save actions based on a template by the great team at Elemis.

From: http://php.net/manual/en/language.basic-syntax.instruction-separation.php

Peter, depends what you have in mind. You can create custom admin pages and build your form using PW forms and API, so building on the foundation. The thread teppo linked to shows how to use inputs and form, whether for frontend or backend. Using PW components gives to plenty of possibilities to validate and manipulate and hook into various parts of the form and it inputfields. There around 400 hookable functions in PW http://processwire.com/api/hooks/. With this at your fingertips you can do almost anything pretty quickly, whether in backend or in front-end. It depends (as always) a lot what exactly you want to build and what the need are in detail and then look at what would fit best. Also remember all the PW backend stuff is built out of modules exactly the way you would build custom admin functionality and you always can look at how it's done or copy a module to site folder and start modifiying it. You could create your own admin pages and build mini apps that help editing, creating content and it's pretty straight forward. It would be in the same way for when building it in front-end. PW doesn't have a solution to all ready, but a strong foundation to build anything you want. I'm not sure what else you need to know or what you're exactly have in mind. I think you're still maybe need to play with that stuff to better understand all of that stuff and how to go about it in PW. So you should slowly start building custom admin pages I think and ask away.

have had some hours last evening (exactly 8 'til now) I think I can finish the import next time I get 2-3 hours. So, don't know when now. There is some trouble with chars in filenames and ID3-Tags that want not get into the DB, so I have played around with sanitizer, but have to go deeper and change the current behave. Here are a screencast of the backend, starting with an empty DB (no mp3 data in it) set one or more pathes, do a quick filesystem scan (without parsing ID3 etc) envoke a command line script to perform scan with parsing mp3 files and pull data into DB: (please look fullscreen or otherwise enlarge Video) https://youtu.be/Re08fuNFRao

Hi, I made new site in processwire for one crazy Czech band http://www.jinovatka.cz/. Full content admin, responsive, gallery, mp3 player, .....

I'm with teppo - I always use the semicolon, and he's right on it being optional (though I would suggest it should be standardised on the default template for those not as familiar with PHP as well as for consistency). But then again I always stick my curly brackets at the end of a line as well rather than on their own like all the cool kids, so I'm a heathen

Ahh no. I was calling it afterwards. Thanks diogo!

My little workaround <?php if(!$input->post->import && !$fieldsImport && !$input->post->generate): ?> <hr /> <h4>Separate Fields by comma like this: i,am,a,new,field</h4> <form name="importform" method="post" action="./"> <div class="span3"> <p><label>Field Prefix?</label> <input type="text" name="prefix" /></p> </div> <div class="span3"> <p><label>Field Tag?</label> <input type="text" name="fieldtag" /></p> </div> <div class="span3"> <p><label>assign to </label> <select name="template"> <option></option> <?php foreach($templates as $singleTemplate): ?> <option value="<?php echo $singleTemplate->name ?>"><?php echo $singleTemplate->name ?></option> <?php endforeach ?> </select> </p> </div> <div class="span12"><textarea name="string"><?php echo $input->post->string ?></textarea><p><input type="submit" name="import" value="import" /></p></div> </form> <?php endif ?> <?php if($input->post->import){ $fieldsImport = $input->post->string; $fieldsImport = explode(',', $fieldsImport); } if($fieldsImport): ?> <hr /> <form name="fieldform" method="post" action="./"> <div class="row"><div class="span12"><hr /></div></div> <ul> <?php foreach($fieldsImport as $fieldNew): ?> <?php $alleTypes = '<select class="required" name="'.$fieldNew.'"> <option selected="selected" value=""/> <option value="Checkbox">Checkbox</option> <option value="Email">Email</option> <option value="File">File</option> <option value="Image">Image</option> <option value="Page">Page</option> <option value="Text">Text</option> <option value="Textarea">Textarea</option> <option value="URL">URL</option> </select>'; ?> <li><?php echo $fieldNew ?> <?php echo $alleTypes ?></li> <?php endforeach ?> </ul> <input type="hidden" value="<?php echo $input->post->prefix ?>" name="prefix" /> <input type="hidden" value="<?php echo $input->post->template ?>" name="template" /> <input type="hidden" value="<?php echo $input->post->fieldtag ?>" name="tag" /> <input type="submit" name="generate" value="generate" /> </form> <?php endif ?> <?php if($input->post->generate){ $prefix = $input->post->prefix; $tags = $input->post->tag; $template = $input->post->template; $addedFields = $fieldgroups->get('name='.$template); foreach($input->post as $key => $val){ if($key != 'prefix' && $key != 'tag' && $key != 'generate' && $key != 'template'){ $f = new Field; if($prefix){$f->name = $prefix.'_'.$key;}else{$f->name = $key;} $f->type = $val; $f->save(); $f->tags = '-'.$tags; $f->save(); $addedFields->add($f); $addedFields->save(); echo "$key = $val <br />"; } } } ?>

*grunts*

ok, a little sum up. To understand what happens, here is the setup: Page called Clients, container for every client. every client got his unique number written to the title. The client template itself contains a set of round about 35 fields. I imported a set of data via CSV import Module. This set is provided by a client of mine who needs a new Intranet Solution. His client Database contains exactly 15987 entries. Every entry is one client and so every client is a page. As you can see in the screenshot, PW provides a automatic pagination. To handle this amount of data pagination is definitly not the best way. To edit and manage some clients you could use the built in search engine in the backend. Maybe I want to edit clients with the name Richard. I just pick my Clients Name field, type Richard in the Search box, et voila. What also could be interesting, is the performance of PW. Lets have a look: <? $pages->find('template=kunde'); ?> All clients in one PageArray gives me the following : Page generated in 33.5099 seconds. <? $pages->find('template=kunde,limit=50'); ?> Results in : Page generated in 0.0376 seconds. Rendering those sets of data doesnt affect our render time much. The following: <? foreach($pages->find('template=kunde,limit=50') as $client): ?> <p>Number: <?= $client->title ?></p> <? endforeach ?> Results in: Page generated in 0.0462 seconds. Conclusion: At a certain point you dont have to worry about how to order pages, instead you have to worry about how to catch your pageArrays as efficient as possible. Managing large amounts of data is somewhat to think about at the very beginning. I´m handling the clients in a tree like this: Home/Database/Clients/ Hope this was helpful

I'm afraid there's no selector you could use to filter based on nth record in a repeater. But there are other ways to get there. I'm assuming you've got a template "trip" with a repeater field "cities_repeater", correct? I'm asking because you're talking about a repeater but the structure (and get()->children()) looks like you've got pages inside each other. So, one option is to find all trips via Berlin, loop through the results and pick only those that have Berlin as a starting location. If the amount of trips starting from a city isn't going to grow too much (so that you don't need to paginate the results) and the amount of trips via a city doesn't get too high either, this would probably work out just fine. On the other hand, you can make the trips searchable with a selector based on their starting city with a little autoload module and a hook. Create a new field "starting_city", add it to the trip template and make it hidden. Then create a module hooking after Pages::save. In the hook check for the trip template and then populate starting_city with the first element of cities_repeater. And remember to save only the starting_city field to avoid an infinite loop . See Pete's example and Soma's comments in this thread for a code example. Now that you've got starting_city in a separate field it's a walk in the park to write the selector you're after: $trips = $pages->find("parent=/trips/, starting_city=berlin"); Do remember that in order to get that hidden field populated for all the trips, the hooking module must be installed before any trips are actually created. If you've already got the data in place, then you need to get the module working and either save each trip (no changes needed, just edit+save and the hook will kick in) or create a little script that populates the field for the first time.

Smells like a casestudy

What does autojoin do? Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. What sites should use autojoin? Autojoin is most applicable with larger sites. On smaller sites, there may be no benefit to using it or not using it. But it's good to know what it's for regardless. Where do you control autojoin? Autojoin is controlled per-field. You can turn it on by editing each field under Setup > Fields > [your field], and you'll see it under the 'Advanced' heading. When should you use autojoin? Autojoin causes the field's data to be loaded automatically with the page, whether you use it or not. This is an optimization for fields that you know will be used most of the time. Fields having their data loaded with the page can increase performance because ProcessWire grabs that data in the same query that it grabs the Page. Autojoin is a benefit for fields that are always used with the Page. This is best explained by an example. Lets say that you have a template for individual news stories called news_story. The news_story template has these fields: title date summary body sidebar We'll assume that when you view a page using the news_story template, all of the fields above are displayed. Fields that should have autojoin ON: Now consider a separate news_index template that displays ALL of the news stories together and links to them. But it only displays these fields from each news story: title* date summary In this case, the 3 fields above would be good to autojoin since they are used on both the news_index and news_story templates. If your title, date and summary fields didn't have autojoin turned on, then ProcessWire wouldn't go retrieve the value from the database until you asked for it it (via $page->summary, for example). Because the news_index template displays all the stories at once, and always uses the title, date and summary fields, it will perform better with title, date and summary having autojoin ON than with it OFF. In this case, it reduces the query load of the news_index template by 3 for each news story. To take that further, if it were displaying 20 news stories, that would mean 60 fewer queries, which could be significant. Fields that should have autojoin OFF: Now lets consider the body and sidebar fields, which are only used on the news_story template: body sidebar It would be desirable to leave autojoin OFF on those fields because there is no reason for the body and sidebar to be taking up space in memory when they are never used on the news_index template. While it might mean 2 fewer queries to view a news story, that is not significant and certainly not a worthwhile tradeoff for the increased memory footprint on the news_index template. Keeping autojoin OFF reduces a page's memory footprint. Conclusion Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. But if your situation doesn't involve lots of pages or data, then you don't need to consider autojoin at all (and can generally just leave it off). Additional Notes Not all fields have autojoin capability. You won't see the option listed on fields that don't have the capability. *The title field has autojoin on by default, so you don't need to consider that one. It was included in the examples above because I thought it's omission might cause more confusion than it's inclusion. Be careful with multi-value fields that offer autojoin capability (page references and images, for example). Because MySQL limits the combined length of multiple values returned from a group in 1 query, autojoin will fail on multi-value fields that contain lots of values (combined length exceeding 1024 characters). If you experience strange behavior from a multi-value field that has autojoin ON, turn it OFF. If you want to play it safe, then don't use autojoin on multi-value fields like page references and images.

This module generates a "stubs.php" file containing PHP-classes with documentation for the properties of each Template, based on it's fields - which means IDE support (auto-complete, inspections, documentation) for templates in modern IDEs that perform static analysis, such as PhpStorm. The output looks like this: <?php /** * Generated by TemplateStubs module 2013-04-13 15:29:33 * This file may be overwritten at any time. */ namespace tpl; use Page; /** * "basic-page" template * * @property string $title Title * @property string $headline Use this instead of the Title if a longer headline is needed than what you want to appear in navigation. * @property string $summary Summary * @property string $body Body Content * @property string $sidebar Sidebar * @property Pageimages|Pageimage[] $images Images */ class basicpage extends Page {} To use the generated documentation, start your template-file like this: <?php /** * @var tpl\basicpage $page */ Documentation and more details on this page: https://github.com/mindplay-dk/TemplateStubs You can consider this an alpha-release - I haven't tagged a release yet, and some details like template-class naming convention may change before I tag release 1.0.

I just switched form CodeKit to Guard. I have more control over how things work, it’s cross platform and more team friendly, and it's free. Might be worth a look for you guys as well: "Guard is a command line tool to easily handle events on file system modifications." https://github.com/guard/guard Here's a nice intro by Jeffrey Way on Nettuts+ http://net.tutsplus.com/tutorials/tools-and-tips/guard-is-your-best-friend/ Cheers

The lesson to take here is that you shouldn't be looking at php code without learning at least the basics. IMO the best way to start is by reading a good introdutory book on php, and only then start looking at code from others.

There's absolutely no technical reason behind these -- if I had to guess, I'd say that latter case just looked slightly better without the semicolon.. or it could have been simply an oversight, who knows. Personally I try to use semicolon at the end of each statement, one-liner or not, just to keep things consistent

I currently have a client who is going to have multiple editors on the website and wants the ability to preview all edits before they go live, so I'm really seeing where a more advanced draft feature would come in handy. Since they wouldn't want articles to be removed from the site while being edited, the published/unpublished system doesn't do much for them. Is this something on the radar? Aside from that, a simple preview button would also be handy. There is the module that does a good job of this, but last I tried it was causing bugs with the image uploader in 2.3. I think it would be really ideal to have this as a part of the core functionality, too.

What a fun project! Horst, you totally rock!

Thanks Ryan. Ok I think I can work around it. It's not a massive requirement to get it working without Javascript it's just I was trying to build an admin theme which was as lean as possible and I don't see the need for Javascript being used to generate the PageList. Also there is a weird arrow that appears when the list loads. My thinking was to go back to basics and start from scratch. Nico. I'll send you a PM, and maybe you can help me get round some of the issues I'm having.

But the pagetree is really flexible to design with CSS. If you send me a PM with some more informations why you don't want to use JS for pagetree I would try to help as good as I can

Im really busy these days, but fyi I setup a pw system with ~ 15.000 pages. Trying to write a little review the next days.

Hi Ovi, and welcome to the forums! That sure sounds weird, but looks like I'm not able to reproduce what you've described here. I've tried both 2.3 master and dev branches with a few different combinations of image fields. Which version of PW are you running? Do you have debug-mode on (in site/config.php: $config->debug = true;)? Have you checked the error log (site/assets/logs/errors.txt) and Javascript warnings/errors in the browser before/during save? Any traces of warnings let alone errors there? Any modules installed, apart from those coming with the standard package - selfmade custom ones maybe? Default admin theme in use? Does it make a difference if you reorder the image fields? I mean is it always the same field that is working, regardless of it being the first one in the edit form? You could also try and leave only a minimal set of fields to the template: title and both image fields, but nothing more. Still behaving badly? Sorry, quite a many questions - but those are the things I'd try at this point .

Ryan, just wanted to say - thank you for this module, it will allow making multilanguage sites a breeze, I've used LanguageLocalizedURL module on some sites I've developed, but having it naturally in core, makes me wink

What happens with render is that the $page object is momentarily replaced by the rendered page, so if you render a page inside the homepage, and in that page template you compare $page != $homepage, this will always be true. By doing like I did, you are comparing the real url in the browser with the rendered page url. This means that if the page it's called directly, the real url and the url from the $page object will match, but if the page is rendered from another page they won't.

Macrura, your solution won't work because inside the render() the $page object is the one from the rendered template, so ($page != $homepage) will always be true. But the same can be achieved by testing agains the url: if($page->url == $_SERVER[REQUEST_URI]) $session->redirect($pages->get(1)->url."#".$page->name); and in the homepage, something like: foreach($page->children as $p) { echo "<div id='{$p->name}'>"; echo $p->render(); echo "</div>"; }

welcome.mr kongdondo have no.avotor u do so one i make for u sarah yours i make next

@kongondo: It looks like you're trying to implement something that's in core already. Take a look at http://processwire.com/api/selectors/, especially "Limiting the number of results returned by a selector". There's a description of limit, start and even end, should you ever need it. In short: enable page numbers for your template and use only limit without start in your selector. You can get the total number or rows matched from $values->getTotal() and even render a pager using $values->renderPager() if you like.

Thanks Luis. - so have to say: I only want put together the basic stuff but also want to keep it modular and scalable. For example I personally only use mp3-files but if people use other formats like ogg they should be able to extend the class module for that easily. Maybe with some help it could become really nice and not only poor basic ;-) If someone has good skills on how to build / design / layout admin pages with that UI-stuff it would be really helpful if he/she could design the output for the backend. Also if someone is good with frontend design and want to collaborate that would be great too. I have a really short screencast of what I have done till now, (most of this was learning how to send green or red messages to admin screen, how / where to store config data, to create permissions and roles, and basically how to create a module that has a page in the admin section, ...): https://youtu.be/u_S8ajLkzRI Next steps are to parse ID3Tags, compare file-data with DB-data and import new tracks. Question: is it possible to store arrays or WireData on a page?

Create an account on transifex and I add you into a project. It seems to be a very nice tool for doing translations in collaboration. Translations are easiest way for many people to "give back", and current way isn't very easy to get started. In github model you don't even see the original strings, which makes it clumsy. I think that tool like Transifex would lower the barrier to contribute and manage translations.

Thanks, I'll set up a pull request shortly. But for the sake of finalizing the code here too, here is the revised version which does a few more checks and other things. Hopefully my logic is sound. Also, just in case someone is interested. I am using this along with my, not yet released, PDFImageCreator module(http://processwire.com/talk/topic/3304-pdf-image-generator/). The module generates images from all the pages of a uploaded PDFs. Then I use this addition to the Thumbnails module to allow admin users to crop out a carousel/slider image from the PDF image to be used on the site's homepage. if(!$page->$prefix) { if(!wire('fields')->get($prefix)){ //If field with name matching the crop name doesn't exist, create it $f = new Field(); // create new field object $f->type = $this->modules->get("FieldtypeImage"); // get a field type $f->name = $prefix; $f->label = ucwords(str_replace('_', ' ', $prefix)); $f->description = 'This field stores user cropped images from other image fields on this page. To see new additions, you need to save this page.'; $f->save(); // save the field } //Add field to the page's template //This is separated out in case the field already exists, but is not in this template $page->template->fields->add($prefix); $page->template->fields->save(); } $page->$prefix->add($targetPath); //Add the image to the field $page->save($prefix); //If the developer sets the maxFiles value for the field to '1' and there is already an image in there, then delete the first one after adding the new one. //This seems to be necessary because the maxFiles = 1 setting doesn't limit addition of extra images via the API if(wire('fields')->get($prefix)->maxFiles==1 && count($page->$prefix) > 1){ $page->$prefix->delete($page->$prefix->first()); $page->save($prefix); }

What any newbie should do first is learn Drupal. After 2 years of: awful theming, i.e. $element['#object']->field_video_embed['und'][0]['value'] instead of $page->field_video_embed searching through 500 line arrays to find out what module is injecting a certain markup in your code writing huge css files to deal with the divs nested within divs nested within divs nested within divs figuring out how to add a meta tag to your <head> using an API and an array getting carpal tunnel syndrome from constantly clearing the cache because Drupal is such a hog, everything has to be cached learning the Views module, a point and click interface that is 3X more annoying and difficult than learning and using straight SQL find a good host that is beefy enough to deal with the Drupal and has advanced caching capability After that, PW will be a walk in the park.

Uh. Looks like I should make some bug fixes

Just added that optional options array to the size() function, so it should appear in the core this week. Currently you can specify: quality (1-100), upscaling (boolean), cropping (boolean). The position stuff will be added later. $image->size($width, $height, $options); You can also choose a default set of options and specify them in your /site/config.php: $config->imageSizerOptions = array( 'upscaling' => true, 'cropping' => true, 'quality' => 90, );

This is great, very welcome addition!

More updates to the blog profile at http://processwire.com/blogtest/ Still not done with it, but lots of new tweaks. The biggest one is the addition of Tags, as well as an update to the InputfieldPageAutocomplete (committed today) that makes it work really well for tagging. Now when you are entering something in the autocomplete, if it doesn't match anything you can just hit enter and it adds it as a new page. This is assuming that you've configured the field to support that feature. Anyway, the point of this is that it's a very natural way of adding new pages with autocomplete.