Leaderboard

Not quite.... Nope. Not really.... The most important thing to remember about repeaters is that behind the scenes, they are actually real pages (see /admin/repeaters). Not unlike the recommendation to be cautious with $page->children, if you have too many repeaters (and especially with lots of fields), you will be loading all of them into memory when you call the repeater. With $page->children, you can at least do $page->children('limit=20'); So, the issue is about memory/efficiency. Nothing to do with MySQL (which can easily handle millions of rows - of course, we don't load all of these into memory at once ). In conclusion, repeaters do not scale infinitely...

This is a reworked website of Imre Baksa, a Hungarian actor and director. His former (static) website was also made by me back in around 2009. He asked me to do a redesign but I decided to involve ProcessWire to make content management easier. http://baksaimre.hu/ Lesson 1: templates - no thanks It is tempting to use ready-made templates for a project because most of the work is done, there's some tweaking here and there and mission completed. Okay, this is the theory. I have to admit that I have never found a suitable template/theme for my projects, but being a web designer this is the way it should be, I guess. This time I found one that looked fine: Landed from HTML5 UP. In fact there was a self-made design for the site and this template looked 90% similar, so it really seemed to be an easy task to bring it into ProcessWire. Soon turned out that some of the fancy features of the template required advanced JavaScript knowledge. That means, I had to dive into it and learn how it worked. I did so and I was able to tweak things then, but I wasn't satisfied with the outcome. So I went back to the drawing board and dropped the template. This experience reassured that starting from scratch would have been a better choice on the long run. The good thing is that I learned some new things that will come in handy in the future. Lesson 2: template engines - Latte is still my best friend I was using Nette's templating engine, Latte in previous projects and I liked it a lot. It is similar to Twig, which is more widespread, so I decided to try that for learning purposes. This sounded like an easy journey because ProcessWire supports Twig through modules. However, at the end of the day I sort of regretted that. Latte has some small helper features that makes templating easier, and these differences made up a huge difference. Maybe I'm getting old but I felt Twig more of a nuissance after Latte. Finally I got rid of Twig and I guess I will never look back I will keep using Latte in the future even if I have to bootstrap it manually. Lesson 3: frontend development is hard Having ProcessWire at hand, backend is the minor part in web development, at least in smaller projects. I've used only a few jQuery plugins but making them work together nicely was a real challenge. At the end I had to make a compromise by removing SmoothScroll because it didn't work well with JScrollPane. Even so, I had tough times to eliminate content "jumps" when a lightbox is opened, and to make JScrollPane work the way I wanted to work. Making the whole thing responsive added another level of complexity as features needed to be destroyed/reinitialized on different screen sizes. I like to polish things as much as possible but the current state of the web makes it almost impossible to reach certain level of perfection. Moduling up This was the project where I felt that a link checker button would be helpful so started to develop InputfieldURLChecker. I use this in a few projects and it does the job nicely. My other pet PW module FEEL also got some polish during site development. For site-wide settings I used MultiValueTextformatter so I didn't need to create a field for every setting, just one for all. Other modules used: SEO: must have! Admin Template Columns for better admin layout Page List Image Label: to add featured image to the list of pages in the admin Pageimage Remove Variations: remove unused image variations Forms: one step closer to simpler form processing For the contact form I used Nette Forms, because it is so easy to add forms to the site with it, with frontend & backend validation in one go. Processing them still needs some sweat, but this time I finally put together a class to make this easier. Surely it still needs some iterations but it's a huge help: it takes only a few parameters to save submissions as Pages or send email to the admin or the visitor. For email templates I also used Latte (what else? ). I also created a "json_storage" field to store submission. The beauty is that while it's only one field (a textarea), in the admin it is displayed as formatted key-value pairs using a hook. Summary The site looks fresh and the year knob on the left makes it fun to use. Content management is easy as 1-2-3 thanks to ProcessWire, even if it's mostly me who will deal with the updates. While it's not visible on the site, in the background there are many improvements to my development tools and workflow that will be of huge help in the future.

Hi, Nice looking site. Well done. Would you mind sharing what is your workflow for using Nette components (Latte template engine and Nette Forms) ? Thanks

Thanks for the responses! To be honest, it's not like I'm on a crusade to make this happen, it's just an idea that I kept reminded of so I thought why not throw it out there. (Reading back on my posts I may say sorry if my tone implied otherwise; I was just focusing on the arguments too much ) @teppo I think whatever I meant by the .htaccess thing ignored the case of having to make manual changes; I had the impression the upgrade process takes care of that. @szabesz yes I think you're partially right: it would just look "cleaner" haha. I'm not that concerned about my workflow; strict convictions about small things bring about much overhead @justb3a thanks for wireshell! I haven't seen it before, I just checked it out, it looks awesome! (omg drush reminds me of much struggling with drupal)

Have a read here: http://processwire.com/api/fieldtypes/repeaters/ And this post: https://processwire.com/talk/topic/4442-pw-performance-with-hundreds-of-fields/?p=43643

You can build your selector string like any normal string before you pass it to the find function. If a field has been left empty, you can simply not include it in the selector. $selector = "template=user, roles={$role}, include=all"; //fixed part of the selector that is always used if ($input->post('country')) { //sanitize etc. $selector .= ", country={$inputcountry}"; } //repeat for other inputs

This module, while having "Core" in it's name is not installed by default. You'd need to install it manually, just use the classname ProcessWireUpgrade to get it from the modules directory.

In the last few weeks I've notices some request (e.g. here and here) to be able to get pages based on if they are selected in page fields of other pages. I think adding a method for this would be a nice addition to ProcessWire, as it's often the case that the pages itself are options we just want to get, if they are used somewhere. Currently the task "Get all tags used by some blogposts" has to be done manually like this: $tags = $pages->find("template=tags"); foreach($tags as $tag){ // Filter unavailable if(! $pages->count("template=posts, tags=$tag") ) continue; // Do stuff with it } Now it would be nice to have something like this, where we don't need to have a selector for tags (this is done by the pagefield already). // Find all pages, which are selected in the "tags" field of the selected posts $available_tags = $pages->findSelectedPages("template=posts", "tags"); I'm not that big a MySQL guy, but I can imagine this not only improving readability, but also reducing database calls.

What @Martijn said....but I'll attempt a guess If you are talking about a HTML class to add to your uploaded images (uploaded in a page edit session) to target with your CSS, ProcessWire doesn't output markup so you will have to add those on your own at runtime, e.g. $out = ''; if(count($page->images)) { foreach($page->images as $image) $out.= '<img src="' . $image->url . '" class="myImageClass">'; } echo $out; If you are talking about images you insert in the RTE, you can use the RTE to add your classes Welcome to PW and the forums

I don't understand your question, maybe same goes for other people.

It's a really nice documentation site - much appreciated.

Very nice site!

http://modules.processwire.com/modules/process-hanna-code/ I am guessing your HC exists on the page with ID 1187? So it will always evaluate to true. Use wire('page') to refer to pages originating the request.

Hi Roland, Nice work! You might want to know, that by blocking the Google AJAX Search API the site will not get through the "preloading" phase, it gets stalled at the flashing circle in the center. I use Safari with Ghostery installed which is set to block anything Ghostery "knows about", but by whitelisting this script in question, the site loaded just fine.

It will only auto-load if in your module's init method you call parent::init(); then your code after that. The other conditions have to be true as well, i.e. the resources have to be in the same directory as the module and they have to be named as: MyModuleName.module MyModuleName.js MyModuleName.css What class is your module extending? I don't think the above works with all module types

I'd additionally "paginate" the archive to something reasonable. E.g. only the first (or most interesting) 30, 50 or something articles per year and, if necessary, a link to show all articles of a single year (paginated as well). This will scale even as archive.

Hi jmartsch, Unfortunately, I haven't given this much attention of late, but will be getting back into it in January. At the moment, I'm busy moving both modules over to their new homes on Github, and publishing the new documentation site for Jumplinks. Hoping to get the forms module done soon - sorry for the delay.

Hi Mr. Rockettman, is there an estimate when this module will be ready for production? I would love to use it for my projects. It looks very promising.

Might be faster to just do a simple for loop from 2010 (depending on how far back your archive goes) to 2100 (or, say, the current year) and just check the page count for each year. That way you’re not loading any pages at all, and you don’t have to do any date magic. It would also probably result in shorter code. for ($i = 2010; $i <= date('Y'); $i++) { $c = $pages->count("template=artikel, publish_from>={$i}, publish_from<" . ($i+1)); if ($c > 0) $out += "<a href='/{$i}'>{$i}</a>"; } Maybe even throw limit=1 into the selector, or display the count for free.

Thanks for that. Okay, that's making sense. When you say it loads them all into memory when I call the repeater... when does this happen? Like when I do a $page->some_repeater type call? Is it not possible to limit that also? using $page->some_repeater("limit=10")? And I hope I'm not being totally obtuse here, but when you say it loads them into memory, I guess you mean the pageArray for each repeater, right? With regards the MySQL thing... okay, I wonder where I have got that idea from. Maybe it was fields I was thinking about? I'm sure I remember reading something about a suggestion to try and limit fields to a certain amount. Or something along the lines of pages being nigh-on infinitely scalable, whereas fields have a limit. Does that sound totally off the mark?

+1 for this. As LostKobrakai pointed out, this wouldn't be an extension of FieldTypeImage. Maybe just an InputField like that used for Image, but storing a reference similar to a Page fieldtype. One case where this would be very useful is for selecting the image that will be used in the og:image meta tag. You want a single-image inputfield that selects from the images that have been already loaded to Image fields on the page. I'd love a field that has a setting for which page(s) images would be selectable from. So you could fix a page or pages (e.g. current page) in the settings, or allow the selection of a page from the inputfield (like what is possible in an RTE field). I think a field like this would be a great asset in PW - if there are use cases for selecting images from external Image fields within an RTE field then there are bound to be use cases for selecting them in a dedicated "image reference" field.

Why not using existing methods? As @LostKobrakai said, git submodules are not used by many because of the peculiar workflow. There is a module to handle core upgrades: Core Upgrade. Or - if you're familiar with using git - you may consider using wireshell, this is a command line interface like drush for drupal. Instead of `git submodule update` just execute `wireshell upgrade`. If there are no changes the `index.php` and `.htaccess` files are updated as well.

// set new default language $default = $languages->get('german'); // redirect if (!$user->isLoggedin() && $page->localUrl($default) != $page->url) $session->redirect($page->localUrl($default));

Votes are in, and nearly unanimous: The module will be renamed to RockettForms when I get back into it. (Unable to commit enough time at the moment, but will get there.) Also, I plan to make this a 2.7-only module. If you think I should drop that to 2.6.1, let me know.

I sometimes use the code below (include doesn't loose context). <?php // Allow to cache to a variable function getPartial($path_to_file) { ob_start(); include($path_to_file); return ob_get_clean(); } $partial = getPartial($config->urls->templates . 'partials/myfile.php');

PW has to support a broad range of MySQL versions. One of PW's distinctions is making all of the data highly accessible, behaving as if it was all in memory ready to be used, while still being able to scale to millions of pages. One of the important keys to this is fulltext indexes. InnoDB did not support fulltext indexes for a long time, not until recently, in the overall MySQL timeline. While InnoDB now supports fulltext indexes, that's only if your server has a newer MySQL version that supports it, and a great many out there do not support it. Whereas it is universally supported on MyISAM, and has been forever. PW also performs reliably and particularly well with MyISAM (though does with InnoDB too). Like SiNNuT mentioned above, there are no foreign keys in MyISAM, so it's not even a consideration to be debated. While having foreign keys would have certainly saved time on the development side of PW, and are a nice-to-have feature at the DB level, the lack of them is not going to "lead to data inconsistency" either. We manage our table relations very carefully and thoroughly, as we know we don't have foreign keys managing that for us. To the end user of PW it makes no difference. I'm quite certain that whatever issue you are running into has nothing to do with the lack or presence of foreign keys. You can take advantage of InnoDB in PW now if you want to, and we've confirmed it working quite well across several installations. In fact, it's now an installation option available to you. If you click on the gear icon during install (MySQL settings screen) you'll see an experimental option to use InnoDB. While PW won't use features that aren't in both MyISAM and InnoDB (in order to be compatible with both), there are still some benefits to using InnoDB. Specifically, if the power goes out on your server, you won't have a potentially crashed table (needing a repair command). In addition, tables aren't locked during writes, making it work better in high traffic environments that are having to do a lot of INSERT or UPDATE operations in PW (i.e. constant updating or importing pages).

Ok, images and files fields aren't supported. It's not a matter of the textfield being multilanguage or not, it's how file fields and dependencies work. images.count>0 on a text field will only work if you upload a image via the dialog upload, cause that <input name="image[]"> is the one observed checking for its count. Once you save the image and reload the page that input is again 0. So it's not a bug but a "not supported" thing.

These should also work (on dev): // save directly from page object $page->save(array('quiet' => true)); // save just 1 field from page object $page->save('myfield', array('quiet' => true)); When quiet mode is set, the modified date is set to whatever is specified in the page. Meaning, the modified date is not updated unless you change it yourself. Quiet mode also lets you modify the modifedUser and createdUser for the page, if you want to. These are two properties you can't usually modify, but quiet mode lets you do it.

The trick is to build up a string variable eg. $selector, based on the options chosen by the user and using that variable as part of something like: $images = $page->children($selector); This assumes of course that all your images are child pages of the main gallery page. You'll probably want $selector to end up being something like: sort=-camera_model, sort=resolution, sort=-size The way to build $selector can be seen in the Skyscraper's search.php file. For example, this section: if($input->get->keywords) { $value = $sanitizer->selectorValue($input->get->keywords); $selector .= "title|body%=$value, "; $summary["keywords"] = $sanitizer->entities($value); $input->whitelist('keywords', $value); } Each section like this appends more component parts to the $selector string using the '.=' notation. The $input->get->keywords refers to a variable passed from your form using the GET method. You could of course also use POST. GET will put the variables in the URL like ?keywords=word& etc. This is useful for allowing a user to bookmark or share a query link. I am not exactly sure your plans for the resolution and size selects - sounds like you want to offer sorting highest to lowest and lowest to highest? If so, you can build your selector using sort options. Take a look at the sort options on this page: http://processwire.com/api/selectors/ Once you have defined your $selector and searched and sorted the children with it, you can simply foreach through the images: foreach($images as $image){ echo $image->url ...... //etc } Hope that helps.

http://responsivepx.com/?processwire.com (tnx Remy Sharp)

If that would be true, all my development sites would be in google index, but they aren't.