Leaderboard

PW Images Manager (beta) Just a weird little screencast trying to show how it works. (out of date a little, tags now use a textfield for easy copy/paste) This module allows you to manage images from one central repository. You create a root page "/images/" where you can then add categories and images as pages. From there the new admin page created "ImagesManager" will show categories and images added in a ajax data table, from where you can see and search/filter all images, upload and create new categories and edit images too. Every image will also show an image tag generated to copy into a textarea. This tag looks like this: {image=/path/to/image/imagename/, width=200}The width=100 is the thumbnail size used to output the image.You can also have additional segment to contain classes: {image=/path/to/image/imagename/, width=100, class=align_left}Or you can enter the id directly: {image=1033, width=100}Once inserted into a textarea field it will get parsed when saved and loaded automaticly. It will store an abstract id tag in Database and convert it back to the image HTML tag. So after first save you'll see the image inserted in a Wysiwyg and be able to resize and place it as usual. Once it's inserted somewhere Images Manager will show a search link with the pages containing the image (you can configure the fields int the module setting). You can change the image or move it to a different category, it will still work and show the correct image. This also works with multi-language fields.You can still also use the regular insert image dialog in TinyMCE and chose image from those pages. And it will start keeping track of those as well (they're the same after all). You can use those central images pages also with page fields to reference them single or even whole categories, search them with API and do what you like. Images Manager will also parse the page render on front-end and replace any found image tags with the HTML code. It will also look for a description on the image and output it as alt tag. If you want to have multi-language description you can add a `image_description` TextLanguage field to the image page template and have images parser use them. Along with this module, you can also install the `PageListImageLabel` module to add thumbnails to the image pages in the tree. To get it working you need to have the basic setup: 1. Create new `image` field with input setting to 1 max image 2. Create new `image` template and add `title` and the `image` field created before 3. Create a 'image-category' template with only title and allow the `image` template and `image-category` as child pages under family settings. 4. Create a `image-root` template with only the title field for the root of the images tree. Allow only `image-category` as child page under family settings. 5. Create the root page with the `image-root` under the home page as "/images/" 6. Done. The structure of the image repository looks like this /images/ /cagetory1/ /imagesxy/ /category2/ /image2/ /image3/ Now you can use the ImagesManager to add categories and images. But you can also still use the page tree to add new stuff as usual. The root path, template names and fields are configurable in the module settings. How to install the module: - Download the contents of this repository and put the folder renamed as "ImagesManager" into your site/modules/ folder - Login in to ProcessWire and got to Modules page and click "Check for new modules". You should see a note that the two new module were found. Install the "ImagesManager" module. - A new admin page "ImagesManager" should appear in the top menu. - You may configure the option on the module screen to suit your needs. Download at github https://github.com/somatonic/ImagesManager Thanks and enjoy.

Looks good Luis! Thanks for making this. One suggestion I would have (for now or a future version) would be to remove the dependency on a field named 'body'. Not everyone has a field named 'body', and others may have one or more other textarea fields they want to use this module with. So you could take an approach of finding all the textarea fields using TinyMCE and make them editable from your addDivs method: foreach($page->template->fieldgroup as $field) { if(!$field->type instanceof FieldtypeTextarea) continue; if($field->inputfieldClass != 'InputfieldTinyMCE') continue; // if you reached this point, this is a field that can be made editable }

I would say that the blog profile is not the best place to start. It uses more advanced techniques and was designed to be a demonstration of them– These are techniques I don't even use in my own site development, but felt like we needed a profile that would appeal to those looking for a dedicated MVC strategy. The best place to start really is the basic profile that comes with ProcessWire. When you understand that, you really can build anything. If you are wanting to go further, you might like to look at the skyscrapers profile. But the important thing to remember is that there is no "right" way to build your site in PW. This is why even tutorials can be a mixed blessing when you are learning, because they reflect one approach that may not necessary be the right one for you. Beyond the basic profile, you just need to read $page, $pages, PageArray and about Template files. Ignore everything else, because you may never need it. Don't feel like you need to remember or understand everything on those pages. But read through them and make note of what's there. These pages cover 99% of what you will do in ProcessWire from the code side… and probably a lot you won't ever use too. Once you get going and developing stuff, you'll want to keep the Cheatsheet open, which has sections that cover what's on those links above more succinctly. In ProcessWire, you should be comfortable with HTML markup and CSS. But it's less important that you know PHP. You only need to learn a few basics. You really don't need to know any more than you need to know EE tags. Know how to get in and out of PHP from HTML markup. i.e. <?php ... ?> Know what a $variable is – just a place to store a value. Most ProcessWire API functions return a value. Know how to use an if() statement. In PW, you'd use an if() to test if something had a value you wanted to output. Know how to use a foreach(). In PW, you'd use a foreach() to cycle through a page's children, or the results of a $pages->find(...). Know how to output a value, whether: <?php echo $value; ?> or <?=$value?> …both do the same thing. Know how to use include() to include another file, i.e. "<?php include("./header.inc"); ?> I think that covers all you would have to know to do most things from the PHP side in ProcessWire. Can anyone think of anything major I'm missing? Lastly, when you are developing, enable debug mode in /site/config.php: $config->debug = true; This will ensure that you get helpful error messages rather than ambiguous ones.

Something like that would be fine. If i understand correctly you want clients who create a page to be able to choose some predefined options for the way the content is displayed on the front-end. I think you envision about the same but anyway: Create a template called 'layouts'. This is only a container so only the title field needed and no template file. Create a template called 'layout'. This is only for other pages to reference, so only the title field needed and no template file. Create a page with template 'layouts'. Title can be anything, but layouts would probably make sense. Create children pages with template 'layout' for each layout you want. Fill in some descriptive titles: 2 Columns, 3 Columns, 5 Columns Add a page reference field to each template you'd like to add layout choices to. The parent setting to 'layouts'. Call the field 'layout' or whatever works for the clients. Now everytime a user who creates a page based on a template that has the page reference field, they can select wich layout they want. On the corresponding templates files you can use $page->layout to choose the file to include. About template vs template file: We've had discussions about this before but i must say i think that once you've taken a couple of moments to work with the system it's really quite obvious how the pieces fit together and what they do, or can do in PW.

Great thread. Must be the start point for newbies.

Marty, that is good dream to have (it would be superb feature). Soma: you are a machine.

errr.. no. I've added a profile picture.

maybe $images = $pages->find("parent=/visuals/, summary|title~={$input->q}, sort=title"); $images2 = $pages->find("parent=/visuals/, tags={$input->q}"); $images->import($images2); http://processwire.com/api/arrays/

I actually wrote a serious one line reply along the lines of "WTF?". Then I deleted it once my brain engaged

http://wiki.processwire.com needs one too !

Yes. It's the ternary operator http://www.tuxradar.com/practicalphp/3/12/4

Uuh, http://processwire.com/talk/forum/5-wishlist-roadmap/ /k

Title changed. No need to delete the posts IMO. They are part of the history

Matthew, a framework like Laravel is mostly based on the concept of routing. This is really an almost completely blank canvas. The routes describe what happens at specific points, this can be controller actions but something completely else just as well. Out of the box controllers say nothing about url's. You structure 'your' application from the ground up. PW on the other hand already is an application (a CMS/CMF) so a lot of choices have already been made. It's a very flexible app so you can override most of the behaviours but i'm not sure what you mean when you mention a ProcessWire controller.

It doesn't. They fit perfectly together

Soma, this is awesome! One minor suggestion: Instead of copying the image code by hand perhaps it is possible to copy it on click with Javascript? One major improvement: Somehow connect the image manager to a standard image field, so you can also insert existing images to it and / or mix it with single ones. Like I suggested here: http://processwire.com/talk/topic/1188-image-inputfield-like-in-tinymce/#entry10701 I know that we would need a way of symlinking to other images than the ones in the assets/files folder. But you are creative ;-) Great work!

Dear All, I was thinking about this over the weekend. One of the things I've run into with some MODX web clients is that they wanted to have many different options for different template files, for various sections or page types. They were able to create a page and switch the template files at will. I'm considering this method: - add a custom field: "template_file_name" (and a corresponding page to store the individual values in) - add a select field to most of the templates, so that the template_file_name is accessible to all the pages, to choose the template file used for display purposes. - create a small set of templates, containing my custom fields (perhaps 3, one for home, one for section lists, and one for articles) - create corresponding, *unchanging* template files that have nothing in them, except the code to pull in the template file name from the page, followed by an include statement to run the custom template file. I would also set the user role to not allow switching the regular templates. It seemed to me that this would provide the flexibility of having any number of custom template files that could be swapped out easily, without messing with the underlying template and field collection. I also have to say that it seems that it would be easier if the "template" was named something different, e.g. "field collection definition". It's really quite different than the function of the template files, but the names are so close that it's easy to misspeak. It's also initially confusing. Any thoughts? Peter

Regarding ProcessWire going for GPLv3, it's also discussed in another thread here. I'm not really sure what you're referring to here; could you please explain which part of the license this is based on? Edit: taking a closer look at the article posted above, I'm guessing this part about upgrading was based on last paragraph there? If that's the case, I don't think v3 actually changes anything. Licensing code under "GPL version x or any later version" is an old convention and other options they've mentioned still require permission from all authors (at least once) and neither of those are specific to v3. Edit 2: mixing GPL with other licenses seems to be rather difficult subject to grasp. I know this is going a bit off-topic, but still wanted to share this article that, in my opinion, helps to clarify how, when and why this can and should be done: http://www.zdnet.com/blog/burnette/gplv3-myth2-you-cant-mix-gpl-software-with-other-software/331.

<ul id="gallery1"> <?php $thumb = $page->thumbnail->size(220, 200);//outside of the foreach so it only runs once foreach($page->images as $img) { $thumbImg = $img === $page->images->first() ? "<img src='{$thumb->url}' alt='{$thumb->description}' width='{$thumb->width}' height='{$thumb->height}' />" : ""; //if this is the first image $thumbImg gets the content. If not, it's empty. echo "<li><a href='{$img->url}' rel='prettyPhoto[gallery1]'>{$thumbImg}</a></li>"; }?> </ul> edit: The code above will throw an error if you don't have any image uploaded in the thumbnail field. You should also prevent that error by checking for it.

@Grays sorry it took so long, but I was up to something that might solve some problems with sharing images. I create ImagesManager for these cases where you have lots of images shared on different pages. If you're still into the boat this might be interesting. http://processwire.com/talk/topic/3219-images-manager-alpha/

prose.io doesn't work with the www, only without. To what do you want to change the title?

Greetings, This is terrific news, and I'm glad INTERCAL is finally getting some recognition! I have found that development time -- compared with modern PHP frameworks -- can definitely be cut down by about 40% - 50%. There are some nice open-source plugins for importing VisiCalc scripts into INTERCAL. Then there are the PDF-to-card converters, which simultaneously create audio files that can be sent via the latest coupler technology. I think WordPerfect now supports templating for these cards. Finally, I'm finding that creative uses of GoSubs is replacing the need for functions in much of my code. Thanks for posting, Matthew

Ah, I've generally learned best/fastest from examples, deciphering the bits and such, hence me trying to pick apart the Blog Profile. Seems I was trying to fly before knowing how to walk! I shall revert back to the basic site and go from there once more as you have advised. Having "no right way" to build a site is actually one of the reasons I like PW, because I enjoy the freedom of being able to build sites the way I designed them (which was also one of the reasons why I was drawn to EE back in the days). So I do take the tutorials as they're meant to be taken... which, I think, is what led me here. I find myself stuck trying to take things "out of the box" so to speak because I don't know how to code any of it. I hope I'm making sense... But, Ryan, thank you so much for listing all those things I should take a look at. It's exactly what I need at this point - a direction to head towards, because I didn't even know where to begin and how much I'm supposed to "know" in regards to PHP. Looks like I'll be doing lots of reading shortly. By the way, in your example for outputting a value, is it generally more recommended to use the shorthand (is that the right term?) of coding or the full <?php echo $value; ?> and so on? I think I've been seeing bits of both throughout the forum and code bits, so it was something I was curious about. I figured it was just a shorter way to code the same thing, but are there any pros/cons of using one or the other and can the shorthand(?) be used everywhere? Just want to make sure I adopt the best practice right from the start! You may be right. As mentioned to Ryan above, I'm likely trying to fly before knowing how to walk properly. Part of the reason is because I'm also currently trying to convert a site built on EE over to PW, so I keep thinking ahead even though I really should be going at it slower instead of stressing myself out. I do have to admit that I'm hesitant to ask stuff in the forum right now, because I feel a bit like a headless chicken running around. I'd either be asking about every single little stupid thing or it'd be a case of not even knowing where to begin searching for what I need. I tend to try and work things out myself, so this is a point of frustration for me because I feel like I'm so stuck right now and not even knowing what specific thing to ask to get unsuck. Oh and thanks for the explanation in regards to page/pages. And to diogo too. I think I'll be heading over to the areas Ryan pointed out to familiarize myself a bit more on what I need to know and perhaps things will start to click in place. (Btw, yellowled, I actually know more PHP than I do JQuery, so that might tell you something about how lost I am...) Thanks all! I'm feeling a bit more, err, pumped up about jumping back in. You guys are awesome. EDIT: Holy, just saw that there were more replies. Will go read them and reply accordingly in a bit. EDIT 2: Um, I meant "to get unstuck"... and not unsuck. But I suppose unsuck works too.

What Ryan says is completely true, my knowledge of PHP is simple, but i've built some interesting/complex things using only the basics listed, and the fact that you can build almost anything using only those basics and the cheatsheet is the strength of it's underlying design. With PW, i think it's more about how you can visualize the relationship between your content in the backend and how you will output that in the front..so more like creative thinking, problem solving... it is for this reason that processwire is so much fun as @yellowled points out, because you find yourself being inventive and coming up with cool ideas that no other CMS would 'provoke'... it's nice to finally be able to say to clients "yes that can be done"

Better to participate now than to complain later https://docs.google.com/forms/d/1GPDA30gLd-5S8AAlZmwElS6RurOfQuWSAKqN7qMf-Io/viewform

I see you have made some nice tweaks there! New tune?

Ok, starting from the end. Put very roughly, $page represents a single page while $pages represents all pages. The methods from $page http://processwire.com/api/cheatsheet/#page can be applied to any object that represents a single page. $page, when used simply like this, represents the page that called the current template (usually by being viewed in the browser), but the $page methods can be applied to any Page object (other pages, even if they didn't call the current template). How do we get all those pages that are not represented directly by the variable $page? You guessed, using $pages http://processwire.com/api/cheatsheet/#pages $otherPage = $pages->get("/about/"); The get() method of $pages, returns always only one page. Meaning that $otherPage, is now an object equivalent to $page. Because of this, you can apply to it all the methods and call all properties of the object $page: echo $otherPage->id; While get() returns a single page, find() returns an array of pages, to be more precise a PageArray, and to those arrays you can apply any of the PageArray methods and call it's properties http://processwire.com/api/cheatsheet/#wirearray $pagesList = $pages->find("template=basic-page"); $pagesList->shuffle(); //same as: $pagesList = $pages->find("template=basic-page")->shuffle(); and because $pagesList is now a list with lots of $page equivalents inside it, you can go to each one individually and apply the same methods and call the same properties as with $page: foreach($pagesList as $individualPage){ echo $individualPage->id; } Disclaimers: I did an over simplification of the terms (same as in the cheatsheet). To make it clear: $page is a variable that holds a Page object that represents the current page. The methods I keep referring and that are on the cheatsheet, are in reality methods of Page objects, and not $page itself. The same applies to $pages and Pages. I must have some errors there because I'm far from a PHP specialist (even less concerning OOP). edit: Ryan, I saw that you answered before me, but I think to the first part. I will read now

I think this seems like a fine method. There are some users/access modules that you might find helpful, particularly the Page Edit Per User module, that does something very similar to what you are doing. Though your application sounds pretty comprehensive and involved, so you may find any of these modules more as starting points or educational examples rather than complete solutions. Yes. I don't understand the question. But it shouldn't matter where you save the page from. The save() function should always behave the same way. The idea of a "parent page" is purely for structure and doesn't have anything to do with whether a page is viewable. Well, except for access control. If the parent's template defines access and the child's template doesn't, then the child page inherits access from the parent page. I think so, but you are writing about something in-between working directly with an SQL database and working with ProcessWire, so there is some ambiguity there–I don't follow everything you are saying. The API is how you accomplish everything from the code side in ProcessWire. When you know how to put the API to work, you can really automate quite a lot, and accomplish almost anything. What would you use to intercept actions then? GET/POST vars? I don't think there's any problem with using URLs. Avoiding URLs doesn't improve security in any manner I can think of. You'd want access protection either way. Requests that make changes to a database should be POST based, and requests to present information should get GET based (whether using URLs, URL segments or GET variables). ProcessWire includes helpers for doing pagination. Here is more about pagination. Yes. Though most likely you'll call it something other than $page, since $page is the API variable for the currently viewed page. ProcessWire doesn't use a tag-based system, but of course they are very easy to implement for your own use. You might want to look at an existing tag engine like Twig or Smarty. Though if your needs are simple, a preg_match_all() with str_replace() is a reliable way to implement a simple tag engine. However, you may want to evaluate whether a tag engine is really necessary. PHP can do the job faster. So it really comes down to whether writing ":!:first_name:!:" over "<?=$first_name?>" is worth the overhead of a tag engine. One other thing I want to mention overall, is that this sounds like a completely custom application that may potentially be better suited to a full blown framework like Laravel. ProcessWire is both a CMS and a CMF, so it'll certainly do just fine with anything you can throw at it. But I'm questioning whether you need a CMS at all here, as it really sounds like more the territory of a dedicated framework. Personally, I would still build it in ProcessWire because that's what I work in. But you'll find a support system more focused on developing larger custom applications of this sort when working with a dedicated framework. You may still find ProcessWire to be a better fit for what you are doing, but do look at dedicated frameworks just in case.

Hello Ant Knight, You made a great post of Processwire.

You can only pass static strings to the __() function. At least, the translation parser will only be able to find static strings. The only reason you'd put a variable in a call to the __() function, is if you knew the text was already available translated, and wanted to retrieve the translated version. But that text would have had to appear statically, somewhere else in the file. To make a multi-langage image field, you can use a Repeater. Your repeater would contain two fields: 'image' and 'summary'. Make the 'image' field of type Image, and set to to contain max 1 image. Make the 'summary' field of type TextLanguage (or TextareaLanguage). The Image field is the next one on the list to make multi-language capable, so should be within the next major version of ProcessWire.

EDIT: Sorry, looking at the InputfieldPassword sourcecode it seems the is no pattern support. But if you dont't need "verify password" you can use a simple InputfieldText and give it a attribute password ($field->attr("type","password");) and a pattern like below. ORIGINAL POST: I think you can use field->pattern like this: $field = $modules->get("InputfieldPassword"); $field->label = "Password"; $field->attr("id+name","password"); $field->required = 1; $field->pattern = "^(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?!.*\s).*$"; //the regex pattern will be used for backend validation and in html5 browsers also for frontend validation $form->append($field);

That's true that the complexity requirements aren't configurable at present. Though I could feasibly make it configurable, but this is the first time the request has come up. Currently, the requirements are that the password must have at least 6 characters, one of which must be an ASCII letter of a-z or A-Z, and one of which must be a digit (0-9). These requirements are only enforced interactively, and in the PW admin. So if you populate a password to a user from the API side, like $user->pass = 'something'; there are no requirements. Meaning, you can choose to enforce your own requirements before populating $user->pass with a value.

OK, it's been a while since I looked at this, and much of it was inspired or guided by Ryan. I had to boil it down a little to make it generic enough to make sense, so this exact code hasn't been tested, but it should get you started. Here's a proof of concept that works. Template for your calendar page <?php function pagesToJSON(PageArray $events) { $json = array(); foreach($events as $event) { $json[] = pageToArray($event); } return json_encode($json); } function pageToArray(Page $event) { $data = array( 'id' => $event->id, 'title' => $event->title, 'start' => date("Y-m-d H:i:s",$event->start_date), 'end' => date("Y-m-d H:i:s",$event->end_date), 'url' => "./$event->id", // event ID is the url segment ); return $data; } if($input->urlSegment1) { // event ID provided as a URL segment to this page $event = $pages->get("id=$input->urlSegment1"); include("./includes/head.inc"); echo $event->title; echo $event->body; include("./includes/footer.inc"); } else if($config->ajax && $input->get->start && $input->get->end) { // fullCalendar making an ajax request of events $start = (int) $input->get->start; $end = (int) $input->get->end; $events = $pages->get("/calendar/")->children("sort=start_date"); $events = pagesToJSON($events); echo $events; } else { //display the calendar $config->scripts->add('/site/templates/assets/js/fullcalendar.min.js'); $config->styles->add('/site/templates/assets/css/fullcalendar.css'); $config->styles->add('/site/templates/assets/css/calendar.css'); $config->scripts->add('/site/templates/assets/js/cal.js'); include("./includes/head.inc");?> <div id="calendar"></div> <? include("./includes/footer.inc"); } // end else ?> head.inc <!DOCTYPE HTML> <html> <head> <title><?=$page->title?></title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <!-- CSS includes defined via $config->styles->add --> <?php foreach($config->styles as $url) echo "<link rel='stylesheet' type='text/css' href='$url' />";?> <!-- include jQuery --> <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.6.3/jquery.min.js" type="text/javascript"></script> <script>!window.jQuery && document.write(unescape('%3Cscript src="/site/templates/assets/js/jquery-1.6.3.min.js"%3E%3C/script%3E'))</script> <!--js includes defined via $config->scripts->add --> <?php foreach($config->scripts as $url) echo "<script type='text/javascript' src='$url'></script>";?> </head> <body> footer.inc </body> </html>

I think you want something like this: http://www.concrete5.org/documentation/using-concrete5/dashboard/workflow/ It's not actually useful for me since I'm the only one editing websites, although I'm pretty sure collaborative teams will definitely need something like this.

Yeah, thanks Ryan!!

The behavior you see here where sometimes it allows commas and sometimes it doesn't is because it depends on what other characters are in the strong. So it'll let a comma stay in "test, test2" but not "guns n' roses, mötley crüe". It's a little too strict, and this function could be a lot smarter, so I'm working on some updates to it that I'll post later this week.