Leaderboard

I just saw this and think it's amazing. https://www.khanacademy.org/partner-content/pixar

Hi Sevarf2 Pw's solution with the extended paths uses another directory structure, so you need to migrate the files somehow. Here's a link to a gist from my migration script: https://gist.github.com/wanze/e8051e0bf754c2f75083 Basically I'm doing the following stuff: Rename "site/assets/files" to "site/assets/files_old" Create a new "site/assets/files" folder Loop the pages and copy all their files from old location to new location (using pageFileExtended) That's it. If anything goes wrong, all files are still available in the old directory. Cheers

I just attended one of the free A List Apart live-events and was quite amazed. The big topics that were discussed were how to chose a cms, evaluating not only the frontend, but also the author/backend user experience and workflow needs and finally the current interest in decoupled cm-systems. The great thing was, that on all of those topics I was constantly thinking how nice it is to handle these things in PW. Some may include more work than others, but in the end it's really avoiding lots of those mentioned difficulties / roadblocks with cmss. So my conclusion is really "I love my CMS" . For the curious I've included the link to the event page, where the hangout/transscript will be posted later and the hangout link, so you can watch it as long as the event page isn't updated. Maybe someone did even watch it live as well. http://alistapart.com/event/content-management https://plus.google.com/events/clcdcbjo5puojn47aprk5plkem0?authkey=CMP6kImisby_tgE

[news from the trenches] I created a page called "Question Bank" and populated it with 3 questions. I'm showing one per page and storing the answers in the session, along with the user id. I'm using the session values to mark the choice made (if the user goes back to a previous question) and I'll save it in the DB on the end of each quiz attempt. The code is on github (along with a db dump) -> https://github.com/sjardim/ProcessWire-Quiz-App This is the admin so far.

Here's a simple way to add autocomplete and 'tags' to your tags field, using admin custom files; you would first need to have admin custom files running and enabled for page edit. this example uses Tag-it! because it stores the tags in a way that seems to work with PW's field (note this is still proof of concept and being tested, but works so far); http://aehlke.github.io/tag-it/ 1.) add the tag-it.min.js to your admin custom files or paste it directly into your ProcessPageEdit.js file. 2.) paste in the CSS into your ProcessPageEdit.css file 3.) Initialize the tags after the plugin, in your ProcessPageEdit.js $(function(){ $(".Inputfield_images input[name^='tags_images_']").each(function() { $(this).tagit({ availableTags: ["kenburns", "test"], singleFieldDelimiter: ' ' }); }); }); you can set it up so that you initialize the field based on it's name and then set your tags with the availableTags option. the CSS needs to be adjusted to be compatible with the jqueryui settings used by PW admin; this is my current CSS, but needs some work still (though it works): ul.tagit { /* padding: 1px 5px; */ padding: 7px 5px; overflow: auto; margin-left: inherit; /* usually we don't want the regular ul margins. */ margin-right: inherit; border-top: 1px #ccc solid; } ul.tagit li { display: block; float: left; margin: 2px 5px 2px 0; } ul.tagit li.tagit-choice { position: relative; line-height: inherit; background: #BBCEF1 !important; } ul.tagit li span { color: black !important; } a.tagit-close { /* background: #eee; */ } input.tagit-hidden-field { display: none; } ul.tagit li.tagit-choice-read-only { padding: .2em .5em .2em .5em; } ul.tagit li.tagit-choice-editable { padding: .2em 18px .2em .5em; } ul.tagit li.tagit-new { /* padding: .25em 4px .25em 0; */ padding: 0; } ul.tagit li.tagit-choice a.tagit-label { cursor: pointer; text-decoration: none; } ul.tagit li.tagit-choice .tagit-close { cursor: pointer; position: absolute; right: .1em; top: 50%; margin-top: -8px; line-height: 17px; } /* used for some custom themes that don't need image icons */ ul.tagit li.tagit-choice .tagit-close .text-icon { display: none; } ul.tagit li.tagit-choice input { display: block; float: left; margin: 2px 5px 2px 0; } ul.tagit input[type="text"] { -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box; -moz-box-shadow: none; -webkit-box-shadow: none; box-shadow: none; border: none; margin: 0; padding: 0; width: inherit; background-color: inherit; outline: none; } there are a few other good tagging plugins for jquery and i've been gradually testing them and trying them out; but for simple needs, this example may be pretty workable. One other caveat - since the plugin initializes on the field and modifies the way it looks, it will trigger the changed field, and consequently ask you if you want to save the page, on exit, even if you didn't change any fields on the page... *plugin init edited to change the stored tag delimiter for PW image tags field

This module adds CSV import and export functionality to Profields Table fields on both the admin and front-end. http://modules.processwire.com/modules/table-csv-import-export/ https://github.com/adrianbj/TableCsvImportExport Access to the admin import/export for non-superusers is controlled by two automatically created permissions: table-csv-import and table-csv-export Another permission (table-csv-import-overwrite) allows you to control access to the overwrite option when importing. The overwrite option is also controlled at the field level. Go to the table field's Input tab and check the new "Allow overwrite option" if you want this enabled at all for the specific field. Please consider limiting import overwrite option to trusted roles as you could do a lot of damage very quickly with the overwrite option Front-end export of a table field to CSV can be achieved with the exportCsv() method: // export as CSV if csv_export=1 is in url if($input->get->csv_export==1){ $modules->get('ProcessTableCsvExport'); // load module // delimiter, enclosure, file extension, multiple fields separator, names in first row $page->fields->tablefield->exportCsv('tab', '"', 'tsv', '|', true); } // display content of template with link to same page with appended csv_export=1 else{ include("./head.inc"); echo $page->tablefield->render(); //render table - not necessary for export - just displaying the table echo "<a href='./?csv_export=1'>Export Table as CSV</a>"; //link to initiate export include("./foot.inc"); } Front-end import can be achieved with the importCsv() method: $modules->get('TableCsvImportExport'); // load module // data, delimiter, enclosure, convert decimals, ignore first row, multiple fields separator, append or overwrite $page->fields->tablefield->importCsv($csvData, ';', '"', true, false, '|', 'append'); Please let me know if you have any problems, or suggestions for improvements. Enjoy!

By default, the "Forgot Password" module is not turned on in v2.1. My thought was that lack of such a function is technically more secure (on any site or CMS). Why? Because having such a function active means your password is only as secure as your email (*though see note at end of this message). So I thought we'd start things out as secure as possible and let people adjust it according to their own need. But I'm rethinking that decision, and may change it to be 'on' by default. If you don't already have that "Forgot Password" module installed, it is relatively easy to reset your password with the API. Lets say that you lost the password for your account named 'admin' and you wanted to reset it. Paste this code into any one of your templates (like /site/templates/home.php in the default profile, for example): <?php $admin = $users->get('admin'); $admin->setOutputFormatting(false); $admin->pass = 'yo12345'; // put in your new password $admin->save(); …or if it's easier for you to copy/paste everything on one line, here's the same thing as above on one line: <?php $users->get("admin")->setOutputFormatting(false)->set('pass', 'yo12345')->save(); Replace "yo12345" with the new password you want and save the template. Then view a page using that template (like the homepage, in our example). The password for that account has now been reset, and now you are ready to login. Don't forgot to now remove that snippet of code from the template! Otherwise your password will get reset every time the page is viewed. Once logged in, here's how to install the Forgot Password capability: 1. Click to the "Modules" tab. 2. Scroll down to the "Process" modules. 3. Click "Install" for the "Forgot Password" module. That's all there is to it. You will now see a "Forgot Password" link on your login page. *ProcessWire's "Forgot Password" function is actually a little more secure than what you see in most other CMSs. Not only do you have to have the confidential link in the email, but the link expires in a matter of minutes, and PW will only accept password changes from the browser session that initiated the request. So an attacker would have to initiate the password change request and have access to your email at the same time, making it a lot harder for a man-in-the-middle snooping on your email.

Are you somehow missing the home.php file? Or is there an alternative file set in the template's settings?

Try changing file permissions (recursively), I often have to do this due to our server.

Above response was for your original post. Using the title is handy for smaller sites, but I do actually agree with you. Much of the module is really me testing things out. For consistency reasons, I'm going to make it dispay the path instead. Regarding font sizes, those were deemed best for the common 1366x768 resolution. Anything larger than that, and it just doesn't fit nicely for me. Sure, on a large screen (if I remember correctly, you're using a Mac), it would appear differently. For the time being, I'm going to leave that as it is. 404 Monitor is in dire need of an upgrade, which is one of the aspects that prompted me to do a rewrite. It's usable in its current form, but can easily get overcrowded. Also, it's limited to 100 404s (it stores all of them, though), which is something I'd like to deal with when it becomes a separate module. Glad you like it

Hi Peter - Jumplinks is my own successor to Redirects. It was originally developed for Bolt CMS, but has now been fully adapted for ProcessWire. At present, yes it's stable. All the issues that have been encountered are closed, and don't have any complaints so far. I think that Jumplinks is called earlier that Redirects in the event chain, so no clashing on that front. If the same redirect is defined in both, then Jumplinks will redirect first, and the Redirects module will not do anything. (I haven't actually tested this, but it should be the case.) I do have plans to upgrade Jumplinks - it's really more of a coding issue than a practical one. Essentially, the module will remain mostly the same, and the upgrade will be seamless. Unfortunately, I don't get much time to look at it - as such, I remind myself that the current version is stable, and ready for production use, and so it isn't really an issue when I start writing Jumplinks 2. However, the major part of Jumplinks 2 will be that the 404 monitor currently included with the module will be removed, and made available separately. Give it a spin - if you like it, you can switch over. When I'm done with v2 (which won't be any time soon), you can upgrade with no hassles. In the meantime, I do want to add the feature you suggested for Redirects, I think it's definitely quite useful for large sites.

It's too fat.

Yeah it looks nice, but I'm still confused why it's so hard for people to just let the page render statically (which shouldn't be a problem) and add all the fancy animation on top, so one could still read all the marketing speak without relying on loads of js. It's especially confusing when knowing that seven agencies where involved in the project.

Besides if you're changing the database structure, then you'd need to install / uninstall (or change the db manually, which is not as clean). btw: refresh button of the browser and/or modules > refresh.

No problem. Checkout the following code for more insight. All written in the browser, so it's not tested. But you get the idea. <?php // Create a form using the API. You can thank soma > $form = $modules->get("InputfieldForm"); $form->action = "./"; $form->method = "post"; $form->attr("id+name", "form"); $field = $modules->get("InputfieldText"); $field->label = "Name"; $field->attr("id+name", "name"); $field->required = 1; $form->append($field); $field = $modules->get("InputfieldHidden"); // A hidden field to populate which product should be stored in the session $field->attr("id+name", "product"); $field->attr("value", $product->id); // You can use the value (i.e. $product->id) to save the data $field->required = 1; $form->append($field); $submit = $modules->get("InputfieldSubmit"); $submit->attr("value", "Subscribe"); $submit->attr("id+name", "submit"); $form->append($submit); if($input->post->submit) { $form->processInput($input->post); if($form->getErrors()) { $out .= $form->render(); } else { // Always sanitize user data $name = $sanitizer->text($input->post->name); $product = $sanitizer->text($input->post->product); $session->name = $name; // Using $session->name you can get this data back on another page $product->product = $product; // Idem dito $session->redirect($pages->get("PAGE_ID")->url); // The page (PAGE_ID) you want to send the user to (i.e. the checkout page) } } else { $out .= $form->render(); }

@Christophe I think in your second menu you want $rootPage = $page->rootParent;

hello world sometimes it would very helpful if there would be a «cross asset selector». my idea is to upload the images/pdfs etc. just once in a manager (similar to soma's images manager) and then to be able to select the assets via regular image field (or a new one). clients wouldn't have to upload the images more than once (and crop, resize etc.) and it would save a lot of disk space. any feedback about the idea? thanks

soma's approach is one file/image == one page - this works great on central based assets like downloads (you could counting the downloads...) For images i used this approach in my first PW projects, too.....BUT i switched to the PW way of handling images. I've used some tools like: ChangeImageSelect - changes the $page of the image select dialog in PW Image Plugin for RTE's https://gist.github.com/mr-fan/4751ea179334139d1f76 AutoImagePages - to have a nice way to upload a buch of images and regardless get single images/pages from the uploaded files https://github.com/mr-fan/AutoImagePages but all this feels a little bit hackish and on the long run the users have to take different places while editing (1. upload images there 2. choose images here)...the Processwire appproach of taking files/images with the needed page (and for shure you have access to images from other pages if needed) is very straight and much easier for the enduser. (1. upload image 2. choose image - all in one place - the actual page) I was stamped by my former CMS to have a kind of media managment....but this is not really necessary on normal pages. And any kind of Overview (Files, Images) and Buchediting could be done with some modules like Lister Pro or BatchCildEditor. My current setup of using files/images: Setting for Content Images - images belong to the used page - images in the content right/left/something else - i use PageTableExtended to render different Typs of Contentblock like part_text, part_image_text_right....and so on (i don't images within RTE fields....so i strict provide my users given "minitemplates" to use - PageTableExtended rocks for such kind of contentblocks) - using CroppableImage or ImageExtra if needed - "cross assets" are under a special imagefield of the homepage (if there was less) and under a special gallery setup in the pagetree (if there was more)... - for special image things like sliders i use an extra PageTableExentended field that renders output in the backend and edit slides via PageTable Setting for Files - using a central hidden place in the pagetree - using one file == one page approach - counting download/access - with this i can provide clean urls like www.mywebsite.com/downloads/file.pdf - using PageTable field to build a User UI for adding new files easy (see screenshot in this topic) best regards mr-fan

Since Ionic is on top of Angular, here's a good article: https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/

So my errors show me that i've forgot one brace and set one wrong var name...and changed the condition to check the class on current... so this have to work as expected. Have you debug mode on in config.php? Get you PHP errors? Here is the right example: // top navigation consists of homepage and its visible children $homepage = $pages->get('/'); $children = $homepage->children(); // make 'home' the first item in the navigation $children->prepend($homepage); $count_children = 0; // render an <li> for each top navigation item foreach($children as $child) { //change the css class if child is current $class= ($child === $page->rootParent) ? " current " : ""; //count entries $count_children++; //check if we got the second/third or something else item if ($count_children == 1) { //counting starts by 0 so second item is 1! echo custom link echo '<li class="'.$class.'"><a href="'.$homepage->url.'#screen2">My custom title</a></li>'; } else { //normal menu entries echo '<li class="'.$class.'"><a href="'.$child->url.'">'.$child->title.'</a></li>';} } best regards mr-fan

You would just need to check if there is an expiration set, if there isn't, then just stick with the first image. If there is an expiration set, then check the dates and respond accordingly. untested, written in browser. $url = $page->timed_image->first()->url; // default to first image, make sure your image field is set to multiple. $expires = $page->select_timed_expire // assuming you set output format for this field to the same as $now. if ($expires){ if (date("Y-m-d h:i:s") > $expires){ $url = $page->timed_image->eq(1)->url; // if it's past the expiration, get the 2nd image. } } echo "<img src='$url'/>";

There are several options here. You could use $session for this. For example: <?php // First process your form and then set a variable $session->product = 1234; // 1234 is the ID of your product $session->amount = 1; // 1 is the amount ordered // On your other template you can call these variables echo $session->product; // This will get the ID echo $session->amount; // This will get the amount Be sure to $sanitize this if you want to do something with the data (i.e. save the order). Another option is to post the form to another page and get the data from there using $input. I've used both ways and came to a conclusion that sessions are more flexible. If you want to get fancy you can even store arrays in the $session.

If you wanna keep us informed about this topic would be nice. Since i've a old website that until now run with my former CMS - and at the day i will setup all new with PW i will need a kind of multiple choice module or application, too. Best wishes for your project, mr-fan

We're lightyears ahead.

Hi Guys, A new launch from us. Ensoul.co.uk - Interior Design, Architecture & Project Management, London. Background Based in London, Ensoul are Interior Architects specialising in high-end / luxury interiors, basement conversions, extensions, and residential renovations etc. We based the site on ProcessWire because it's agile, scalable and a pleasure to work with. Given that the Ensoul team will shortly be updating the site and blog in-house we needed a CMS that would also be intuitive for them to use. Overall the nature of the site is very visual and relies heavily on photography. It was essential the CMS had solid image management built in and this was another factor in choosing to run it on ProcessWire. More on that shortly. The plan This is Phase 1 (design and launch) of a multi phase project. Phase 2 consists of optimisation, refinement and a comprehensive SEO project. In particular we'll be redesigning the homepage, building a blog and looking to speed up page loads. With ProCache due to be installed very shortly, we plan to dramatically increase the site speed, minify a lot of the JS and gain points on Googles mobile speed test tool. Image Management I just wanted to highlight some of the nice image management features which ProcessWire brought to the table. 1. Background images Most of the pages have a large background image and we wanted the freedom to swap and change these on a page by page basis and test a lot of different photos. Given 80% of the page and background image is covered by content, not every image was going to work. We solved this simply by creating an image filed called Background Image into which we (or client) can drag and drop a photo of their choice. Any background photos are integrated into the jQuery Backstretch plugin In the case of the homepage where three background images are used, PW and Backstretch will create a slideshow instead. <?php // if Background_Image field contains more than 1 photo, echo the images in a slideshow // Mainly for Homepage if($page->Background_Image->count > 1 ) { $bgimage = $page->Background_Image; echo '<script>$.backstretch(["'; echo $bgimage->implode('", "', "url"); // results in url", "url", "url echo '"], {duration: 5000, fade: 1000});</script>'; } else // otherwise echo a single image on its own // Mainly for all other pages if($page->Background_Image->count == 1 ) { $bgimage = $page->Background_Image; foreach ($bgimage as $image) { echo" <script> $.backstretch('$image->url'); </script> "; } } ?> 2. Portfolio The Portfolio page is image heavy and features a masonry grid of photos which are then filtered by project type. On the front end, I was able to restrict each thumbnail and pop-up image to the size of my choice without having to crop each individual photo. To achieve this, I used a $thumb and $large variable and PW automagically handled the cropping. foreach($page->Images as $image) { $large = $image->width(800); $thumb = $image->size(340); echo ".... Creating the filters which toggle the display of rooms by type was surprisingly easy with ProcessWire. I used the image tag field which I hadn't really used before and quickly allowed me to tag a photo as a kitchen, bedroom or basement etc. It really was an eye opener into the power of PW: <div class="portfolioFilter"> <strong>View:</strong> <a href="#" data-filter="*" class="current">All</a> <a href="#" data-filter=".Kitchen">Kitchen</a> <a href="#" data-filter=".Bedroom">Bedroom</a> <a href="#" data-filter=".Bathroom">Bathroom</a> <a href="#" data-filter=".Sitting-Room">Sitting Room</a> <a href="#" data-filter=".Gym">Gym</a> <a href="#" data-filter=".Basement">Basement</a> <a href="#" data-filter=".Home-Office">Home Office</a> <a href="#" data-filter=".Kids">Kids</a> <a href="#" data-filter=".Garden">Garden</a> </div> <div class="portfolioContainer"> <?php foreach($page->Images as $image) { $large = $image->width(800); $thumb = $image->size(340); echo " <a class='fancybox-portfolio port-item {$image->tags}' href='$image->url' rel='gallery1'> <img src='$thumb->url' alt='$thumb->description' class='portfolio-thumb'> </a>"; } ?> </div> 3. Coverage Thumbs The client is receiving regular coverage in leading interior design magazines and at the end of the project I required a way to differentiate between Features and Opinion pieces. Again, PW made this very easy for me. I knew I could easily create a field called Coverage Type and select the type of coverage a publication should belong to. Traditionally I would have relied on the Page field to achieve this but I didn't need the initial more involved setup which that would require. Instead I opted for the new, simpler Options field instead. Featured Modules RenoTheme CoreConfig Upgrade Markup Simple Navigation CroppableImage FormBuilder ProCache (shortly) SEO Page Path History Redirects SiteMap XML ListerPro WireMail SMTP Conclusion That's pretty much it. I know some of the techniques here won't set the PW world on fire and probably are pretty basic but hopefully seeing the screengrabs and examples will help other beginners understand PW a little better. Thanks as always to the PW community who helped build this with their advice and answers along the way.

Thanks for taking the time to explore this stuff Peter. I like what you've done, particularly the tabs in the modal, for consistency with the Link dialog. I prefer icon/text of your drop zone to the one we've got now. Though I'd want the drop zone to be consistent whether in the editor or in the modal. There's also the consideration of what image field you'll be uploading to. If you've got multiple image fields on the page, you are going to have multiple fields to which you can upload to, so a single large dedicated drop zone in the modal would not work. However, I think taking your drop zone that appears in the page editor, and using the same exact thing in the modal would do a nice job of having an improved drop zone, while still allowing for the possibility that there may be multiple drop targets. I like what you've got going on the Image Gallery screenshot in grid mode, but it does blur the line between list mode and grid mode. Not saying that's undesirable, but that it's different from what was intended: for grid mode is to be the opposite of list mode, and keep it as minimal as possible with basically nothing but the images themselves. Whereas list mode is meant to spill all the beans. Behind the scenes, these two modes use the same markup as a matter of efficiency, just styled differently. So there are some limitations in that respect (they have to use the same thumbnails and such). When it comes to any image operation in a modal, the buttons are placed at the top because we don't want them to fall into a scrollable area that's hidden. An important function of the image editor is to allow for the option of working with the image at its actual dimension rather than scaled, which in many cases means part of the image may need to be in a scrollable region. After all, we have no way of knowing what the size of the modal will be as it depends on the client side. If we adopt a standard of having any buttons/inputs, etc. below the image, then in many cases they simply won't be visible. That's why the choice was made to keep those buttons/inputs at the top. However the buttons that affect the modal window itself (like closing it) are able to go outside the modal document and into the window footer. I prefer your use of defined labels for "width", "height", etc., rather than the current arrow icons. I was trying to save the translators some work there, but after using it awhile agree that text labels are better. As for cropping presets, I agree about the usefulness. But I also really didn't want to cancel the purpose of Horst & Apeisa's crop modules, which they've put a lot of work into and already do a great job of this, better than I could do. Maybe someday we can get those preset functions integrated into the core image editor with their help. But the current intention with the image editor is leave that need to dedicated modules, while accommodating the more basic general purpose cropping needs, especially for things like RTE inserted images where a preset isn't necessarily what you want. But if there's sufficient demand for "croptions" (love the label), maybe we can talk Horst and Apeisa into helping us get those in a future PW version. I'm conflicted on the Apply vs. Save Crop labeling. My eyes prefer Apply as you've got it, but that button is actually saving a crop rather than applying the crop to an existing image. I like to leave the option of letting the user determine whether the crop should replace the original, or whether it should become a new image. To me, the term Apply implies replacing the original, though maybe since we give them that choice separately, it's okay to use it here. I'll take it for a test drive.

I was thinking about launching a new CRM and calling it Vista — I don't see the problem.

Hello, I cannot completely understand the of() function. The field is text, textformatter is, say, Markdown. On saving, I put markdown code, why the need of setting of(false) on writing? Why the need to format values in input? Thanks!

I think Martijn is right and this really is a memory_limit issue. Especially if that file is an image, as it'll have to be processed to generate a thumbnail too. And once uncompressed for processing, a 90 MB image is going to be quite large. Even if not an image, 128 MB is still too little for this situation. I would bump it to 256.

I like Ryan's take on that problem, because it seems flexible and clean. The only issue is that the client or CMS user won't be able to see the image he needs, o even worse, won't be able to find it if there's not a descriptive page name. I've been have the same issues that @suntrop describes. I think some kind of visual queue would be more user friendly. The thing is PW won't guess anything about what's in you page (that's great) so it won't classify or make a distinction between a regular page or an image page. This falls somehow short in this kind of situations where you want to select an image page from an assets parent page and it will be hard (for the CMS user) to find it based on a select or text string. Maybe this kind of usage needs another kind of input field. Instead of an asmSelect (and multiple select), there could be an assetSelect, which could display images or uploads to a page in a modal window. Kind of what know Wordpress is using when selecting images attached to a post. I guess this doesn't contradict PW treatment of the data, but enforces the input field concept, which is more presentational and imposes a way of displaying/selecting data. From the distance this would look like an assets manager, but instead the input field turns any page into a an assets manager, without changing any data. Is this making any sense??

Then you would maybe create another role for them with only delete permission and remove the delete permission from the other role. Then assign the "delete role" to the template you want them to delete.