Leaderboard

1) You can set some fields that load only when you access them. that what.it do already .only autoload field.join w page 2) You can set "$config->dbCache = true" for caching the queries. that.what it do already two .you no need two set it 3) I think the search is the major problem concerning the memory consumption because by default the PW need to search in every field and so in every DB table. But i made a module that store all the keywords extracted from those fields in only one, doing so PW search in only ONE table without any JOIN. pw already have.this it called fieldtypecache

Unless you have many thousands of text-heavy pages, the %= selector isn't noticeably slower than any of the others. Just to expand on Soma's answer above, it's easy to achieve 'AND' or 'OR' functionality in selectors. Nik's Selector Test module (mods.pw/2r) is great for quickly testing selectors, BTW. 'OR' first... $pages->find("body%=process|examp"); will find pages including either of the part words either side of the pipe symbol '|'. 'AND' isn't really much trickier... $pages->find("body%=process,body%=examp"); Pages found must match all selectors, so that's an 'and'. I usually build my selector string without search terms, then explode() the search terms on space characters and foreach() them on to the end of the selector string. It's all about thinking the PW way.

I saw this website after it was tweeted by smashingmag, and had to share it here http://designersfriend.co.uk/ Very risky idea, since it could become very unfriendly for non-coder visitor, but I think Andy did a great job with the planning, and I happen to find it very intuitive.

The search.php file that comes with the default profile includes the following line: $matches = $pages->find("title|body|sidebar~=$q, limit=50"); That error suggests to me that you don't have the sidebar field in any of your templates, so you should remove "|sidebar" from the search.php file and I think you should be fine.

Hi. Looks like the problem was with my account being over quota. Sorry for the spam. Message to others: file writes failing? Check your disk space!

ProcessWire Site Profile Using Zurb Foundation 4 This is a drop-in replacement for the default ProcessWire site profile. See the live demo at: http://processwire.com/foundation/ It is mobile-first and fully responsive, capturing all the benefits of Zurb Foundation 4. Ready to be expanded upon with built-in support for deeper levels of navigation nesting in the sidebar. Pagination ready with Foundation-specific pagination output, when/if you want it. Improved search engine, relative to the basic profile. Library of Foundation-specific markup generation functions included, primary for generation of navigation (in _nav.php). Uses ProcessWire 2.3+ prepend/append template file settings making it easy to work with. It is largely stock Foundation 4 in terms of look and feel, with a few tweaks. To Install Download this profile from GitHub or mods.pw/4u. Start with a copy of ProcessWire 2.3 or newer, and its default site profile. If starting with an uninstalled copy of ProcessWire Replace the /site-default/templates/ directory with the templates directory from this profile. Replace the /site-default/config.php file with the config.php file from this profile. Run the ProcessWire installer. If starting with an already-installed copy of ProcessWire Replace the /site/templates/ directory with the templates directory from this profile. Add the following two lines to your /site/config.php file: $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; Desktop Screenshot Mobile Screenshot

Very clever, but close to 'too damn clever for its own good'.

I think this should do what you are looking for: $pages->find('created_users_id=n'); where n equals the id of the user you are looking for. If you are searching for the currently logged in user, you could replace this with $user->id PS, Welcome to PW!

This should work: $myArray = $session->myArray; $myArray['one']['two'] = 'foo'; $session->myArray = $myArray;

Hi Hieu Do, What you're worried about is one of the biggest strenght of Pw. Having each field in a separate table does scale very well - mySQL is very fast when Joining optimized tables, like Pw generates them. Plus you have the advantage that each field can store as much metadata as needed with different table structures. Also in Pw you can label your fields different in each template context, this is supporting you to reuse existing fields. For example: In your 'member' template, just give your title field the label 'Forename + Lastname' My suggestion is: Give Pw a try, it's faster than every CMS/CMF I used before. Additionally there is the template cache, markup cache and a module from ryan called ProCache which completely bypasses MySQL + PHP serving you html pages That's the default behaviour. Pw only joins and loads fields you access, unless defined as autoload. Not quite sure what you mean here. You can specify in which fields you want to search your keywords

One of the ways you can show support for ProcessWire is to help get the word out by including a small "Powered by ProcessWire CMS" tagline (ideally linking to processwire.com) in the footer of sites that you develop. This is a big help to the ProcessWire project. But I know there are many cases where it just doesn't work to do that because the client thinks of it as gratuitous. I think it's important to communicate to your client that it's not gratuitous at all. It is doing the right thing by showing appreciation and support for a software that is running their site at no cost. Even so, it's not always as simple as that, and I completely understand. We have no requirement or expectation that sites developed in ProcessWire do this. We just encourage and appreciate it when you can. Let your client decide One thing I've been doing lately is to put the control into my clients hands. They really appreciate that I've given them control over it… more so than if I'd left out mention of ProcessWire completely. It also makes them feel good as they are the one showing support, not just their site developer. Here's how to do it in 1 minute: 1. Create a new "checkbox" field in Setup > Fields called "toggle_powered" (or whatever you want to call it), and enter the following for label and description: 2. Add the "toggle_powered" field to your homepage template. 3. Edit the homepage and check the box (if possible in your situation). 4. Edit the template file or include file that contains the site footer and paste in the following: <?php if($pages->get('/')->toggle_powered): ?> <p> <a id='processwire' target='_blank' href='http://processwire.com'>Powered by ProcessWire Open Source CMS/CMF</a> </p> <?php endif; ?> The code above is an example, so adjust the markup, size, wording and placement to suit the site.

InlineEditor 0.0.3 A simple, inline editor that allows you to edit text based content directly in pages themselves. Only use this to experiment. Please do NOT use this on live sites. 0.0.3 Updates Refactored process module Editor now shows result sent by server rather than a generic message New in 0.0.2 Editing repeaters work (actually always did from the beginning) All editor bar colours are now configurable through the admin panel All editable areas are now given a dashed border Few other fixes! Module page: http://modules.processwire.com/modules/inline-editor/ GitHub page: https://github.com/Sinmok/InlineEditor-for-ProcessWire Credits: Big thank you to apeisa for Fredi - whos Module inspired me to make this. It also provided a solid foundation on how to make my own module Ryan - For the whole CMS and the HelloWorld module which taught me how to hook on to page::render! Screenshots:

This works as well, FYI. $page->of(false); $page->save();

I see now what happened. I deleted the basic-page template, thinking I would use the Home template as my "basic-page" template (I'm kind of radical that way). I didn't realize you could tell templates that they could not be used for any other pages, which is the default setting for the Home template.

OK, here are a few more points to consider Dave: The “clearfix” class comes and goes (there in initial TUT_article.php code under section “Template File” as a class for article_maintext; but no longer present in the resulting example under section “Adding the Fields”). It is part of the CCS so should be in the HTML I think, as it is needed for the layout to work as intended. Hence, it should be in the latter example of finished code as well to avoid confusion. When the fields are defined under “Creating the Fields” and referenced under “Creating the Article Template File”; there is just one image field, “article_images”. However, under section “Creating a Template”, that field (that has been setup to hold two images) has become the two fields “article_mainimage” and “article_secondimage” . You could go both ways I guess; I used the method with one field (that best corresponds to the tutorial text) and that works as described. Additionally (but less of a problem), the field “article_meta_keywords” appear in the image under the “Creating a Template” section (without having been defined or referenced before) instead of the actually defined field, “article_metadescription”. The keywords-part is also unnecessarily in the TUT_header.inc under the early “Header and Footer” section. As it is not used, it should probably be removed. Other than that, I ran through the whole thing and everything works! The one caveat is that I (for understanding and training) rewrote the php code references in the HTML myself using full php -syntax, so I can't vouch for there being no errors in the example code in that regard, but I followed along with the examples so I doubt it. All in all, not a bad way to take the first tentative steps into the world of php and cms in general - and ProcessWire in particular - for someone who is new to all this (like I am). Thanks again for your help! /ND

I think this is similar to this? http://processwire.com/talk/topic/691-wireinput-only-allows-one-dimensional-arrays-why/ $input doesn't do multidimensional arrays either...Advice is to use $_POST, etc..in such cases

Split the words and search separate with %.

jtborger, You misunderstand something, but I'm not sure what exactly The following code: foreach($page->field_page_reference as $t) does not return you all possible options, but the ones that are selected on the current $page Let's say you have two pages with the same template, each assigned a Page field to it which can hold multiple pages references. Page A: You select 30 Pages in the Admin Page B: You select 2 Pages in the Admin Then when doing the loop, you will iterate over the selected pages only.

Selector operator "~=" means that at least one of the fields you've defined (teaserBody, contentHeadline, contentBody) has to contain all specified words. Order doesn't matter, though. Are you absolutely sure that's the case? This could also have something to do with either stop words or length limitations, so you might want to test it with longer words and/or change selector from "~=" to "%=". This is a bit slower, but so far I've been using it pretty much everywhere without any severe performance issues.

Do you use xdebug? http://www.wunderkraut.com/blog/fatal-error-maximum-function-nesting-level-of-100-reached-aborting/2013-01-31

Just a little note to let you all know I just love PW even more after using the few lines above to create my import module for some plain old html website. It is so easy to use the PW api... Thanks guys! Perhaps you can extend it a bit more with some exception catching to make a more 'real world' example. But don't know if that is the scope of this post (or posts like this). I could post my import example, it is the same as above but just a little more.

Some ideas seem great in paper, but then they don't work at all. What I like in this site is that it woks because it was very well thought. I can imagine all the difficult decisions that had to be made to balance the usability and the respect for the original idea of making it look like pure code. I must say I am impressed by how it works well. Not forgetting that his target are webdesigners and not final clients. I like it!

OrganizedFellow, holy *** that Emmet stuff is pretty awesome! Thanks for sharing!

@Hieu Do: there was some discussion about Apache Solr a while back, though I don't think anything concrete came out of it (not yet, at least.) Most of the modules publicly available are listed at the modules directory, so you might want to check that out at some point.

Did you create all the required .php template files, as per these instructions? http://processwire.com/talk/topic/572-release-discussions/ I have used this in a couple of sites without problems, so as horst says, it should be an easy fix to get this working. Whether it suits your needs is another story - it is a very basic (but effective) forum. Actual proper user integration with other forum software will be much more complicated. You could potentially install some and style to match your PW site though with less effort. Here is a recent thread that might want to start following as Pete is looking to possibly build some forum integration: http://processwire.com/talk/topic/3536-forum-integration-module/

@adrian Thanks so much for the help. This was a preliminary question for my upcoming project, and I will let you know if I have any issues! Thanks for the welcome, I was lucky enough to find out about Processwire and it has quickly become my go-to CMS. @renobird Thank you!

You can use scripts in commandline mode or in HTTP environment that include the pw index.php like this for example: // the absolute path or relative path to processwires index.php $PATH2PWindex = dirname(__FILE__).'/index.php'; // $username and $pass to a superuser $PWuser = ''; $PWpass = ''; // ... require_once($PATH2PWindex); wire('session')->login($PWuser,$PWpass); if(!wire('user')->active || !wire('user')->hasRole('superuser')) { echo "\n\nERROR: Incorrect UserLogin!\n\nScript stop now!\n"; exit(1); } after that you are logged in as superuser and can do all API stuff you like. I use this above as external CLI-Script and ask for credentials in shell window. You have to access the API via wire('pages'), wire('session'), etc instead of $pages or $session. http://processwire.com/api/include/

I think this is a very good point - the thing is, different sections of your site will use different fields, so why would you want to pull in every field for pages that don't need them? You have to bear in mind that it's perfectly acceptable to have a template with just a Title field in ProcessWire (there are many practical uses) so why call in a body, summary or image field if there isn't any body, summary or image content? The whole system is designed to only access the data necessary for the page you're viewing. It's also worth noting that if you are using it for a site with hundreds of thousands of pages, there are a few caching options like MarkupCache or ProCache - the latter of which will make your site lightning fast as essentially it serves a static version of a page and bypasses PHP and mySQL completely Of course there are situations where you might have to think about the best caching methods for your particular project, but if you ask around on the forums people will point you in the right direction.

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

I always liked Foundation 3, but it just seemed slower (on my computer) than other frameworks. Foundation 4 doesn't seem slow at all anymore. I was initially confused by the syntax with class names like "small-4 columns" and "large-8 columns", etc. But it's actually very simple: if you want a div to have 4 columns at small (mobile) and at large (desktop) then use "small-4 columns" ...Foundation is literally mobile-first, so the "small" settings inherit through to the large settings, unless you override them. But if you want it to only have those 4 columns on at large (desktop), and 1-column stacked on mobile, then use "large-4 columns" ... which would be like the behavior of Foundation 3. If you want to define different column amounts for small and large, like say 2 columns at small (mobile) and 4 columns at large (desktop) then specify both in the class, like "small-2 large-4 columns". I never got far enough in Foundation 3 to say for sure, but I don't think it had that distinction...I think it just stacked everything at small.

Hi Hieu, first of all welcome to PW! When i saw all the tables created from PW i was afraid too, but there are some functionalities that maybe can help: 1) You can set some fields that load only when you access them. 2) You can set "$config->dbCache = true" for caching the queries. 3) I think the search is the major problem concerning the memory consumption because by default the PW need to search in every field and so in every DB table. But i made a module that store all the keywords extracted from those fields in only one, doing so PW search in only ONE table without any JOIN. 4) There is also the cache of the entire page. Look at this module and here I must say that currently i don't had the chance to do a site with a million records, it would be interesting if we can do a test with tons of pages ! USSliberty

Hi Hieu Do. Welcome to PW and the forums! PW can easily handle 100's of thousands of rows. This question has come up before. I can't find the relevant forum posts atm but am sure someone else will give you a better answer. Meanwhile, this answers part of your question: http://processwire.com/about/what/ Edit: Here's are other useful threads... http://processwire.com/talk/topic/2503-question-about-extreme-scale-hundred-of-thousand-maybe-millions-of-pages/ http://processwire.com/talk/topic/37-internal-optimisation/

I just posted version 2 of this profile, which makes typographic tweaks to several styles. It also adds support for photo captions, seen on the typography tests page. Also, there is now a demo site of this profile. I'm okay with only supporting IE9 and newer for the desktop view. IE8 and lower can have the compatibility mobile view. It's not like IE8 and older are blocked. They just simply get a view that works consistently in older browsers (which is basically the mobile view). I think this is smart, and better than trying to make old browsers display like new browsers. Supporting old versions of IE always means extra bulk and shenanigans in the code. The less legacy-IE monkey business, the better, IMO. But if you are building a complex desktop grid for an audience using old IE versions (like inside a government office that has standardized on IE7 or something) then Foundation is probably not the right framework for that. Here's what this profile looks like in IE8 if you are interested. The rule is that you have to start and end an attribute with the same style quote. Otherwise, they are interchangeable. I prefer to use single quotes myself. But if I'm copying/pasting something, I'm not going to bother going and changing double quotes to single quotes either. But ultimately the biggest reason is what Teppo highlighted: what makes the most sense in the context where they are used.

Greetings, Very interesting. I have been on the fence regarding CSS/JS frameworks for some time (experimenting but never full adopting them), but Foundation has been the one I like the best. I just have not felt sufficiently motivated to stop using my own code. And yet, I understand that it might be best to just start using a framework. With your new profile, it might make the jump even easier! I look forward to giving this a try, and I will report back on my experiences. Ryan -- THANK YOU so much for all your tremendous work, creativity, and endless generosity. Thanks, Matthew

Found the solution myself, I can't just set the second parameter of pageName to true, I have to set it "Sanitizer::translate". Correct code that works: $page->name = $this->sanitizer->pageName($page->title, Sanitizer::translate)."-".date("d-m-Y", $page->getUnformatted(date));

I eat them.

Today I just want to show a new page build with ProcessWire. It's nothing fancy but the client is more than happy. http://www.rv-heidenheim.de (german content) The local horse club had an old ugly Flashwebsite which we relaced with a fresh and modern PW site. The goal was to create an easy system to maintain content and to inform people about the club. Behind the scenes: Processwire with ProCache let the site run faster than any horse in the barn. Using the PageLink Field to create a menu structur. Skeletton 960px grid but right now we removed the mediaqueries. We will add the mobile view later. The weater widget uses this jQuery plugin. All widgets in the sidebar are pages and fully configurable by the backend user. A year ago, this was my first Processwire page. But it was never released and we made a complete new second version last month. First time I've used an icon font. Try fontello.com to build your own icon font. The site was designed on a friday evening and only 24 hours later the whole site was done. Using PW it's just a charm to build such small sites and let people insert their content.

Greetings, Excellent discussion topic! Sometimes, I offer a few initial designs, but the client can only choose one. Or more often, after a site is launched, I "experiment" to show the client what's possible. Other times, when competing for a project, I create a couple of designs but don't "win" the bidding war (by the way, I no longer get involved in bidding wars). The problem is, my designs are usually so specific to the project that after I move on it is rare where I can use just that one again. Maybe we could have a "PWDribble" area where we can post these designs? Maybe sharing them would be helpful to others? Thanks, Matthew

I think the drop-down menu would make sense, especially if it can be added to with further modules. Maybe it would make sense if the select box uses "optgroup" tags so that each module's actions stand out separately?

Ok, I'm convinced Gosh*

The main reason it's not there is just because $input is another layer on top of $_POST (or $_GET or $_COOKIE) and I wanted to limit the overhead of it as much as possible, at least until we needed it. Didn't want to enable the possibility of someone posting endless multidimensional arrays from a security standpoint. But ultimately if the need was there, I would add it. And now that its come up, we might as well add it. Probably what I will do is just limit the recursion to 2 or 3 levels to keep it safe. I don't see any potential issues with adding it. If you've had the need for it, then I'm sure others will to. If you want to submit a pull request, I'll bring it into the core. Otherwise, I'll plan to add and commit an update to the core soon. Thanks, Ryan

I wish my wife would pick up knitting– If she is home I'm in trouble if I get near the computer. In fairness, she's been quite supportive in me cutting my client work 50% to focus on PW. But I do miss the evening hacking.

I've been looking through the code and it looks very nicely put together. A few comments on things I wasn't sure about: <?php if (!$post->discussions_message) wire('session')->redirect("./?discussions_title={$post->discussions_title}"); if (!$post->discussions_title) wire('session')->redirect("./?discussions_message={$post->discussions_message}"); There might be issues sending all that copy through a redirect header, especially straight out of the $post input. I'd recommend instead saving it to a $session variable and then just redirecting to something like "./?missing_something=1", and then pull your discussions_title or discussions_message from the $session var instead. With any API vars, these are all equivalent: <?php $page = Wire::getFuel('page'); // older style for static use $page = $this->fuel('page'); // older style for internal API $page = wire('page'); // newer style for external API, internal or static use $page = $this->page; // internal API internal API = classes descended from Wire external API = other classes or other applications or command line API It doesn't matter which you use, but just wanted to mention they are all the same because I saw you 3 different versions. The $this->page is the 'prettiest', but relies on the class or one of it's parent class(es) checking the fuel and matching it. This is something that WireData (the class you are using) does, so you can use that format if you prefer it. That's the version I usually use, though technically it has a little more overhead than the rest. If you want one that you can use anywhere regardless of context, I would just use the wire('page') function. For your render() methods, I recommend adding an output formatter to your discussion_message. It's likely that title will already have an output formatter applied to it (htmlentities by default), though maybe good to double check. Here's how you would add a textformatter during your install (second to last line): <?php $field_message = new Field(); $field_message->type = $this->modules->get("FieldtypeTextarea"); $field_message->name = 'discussions_message'; $field_message->label = 'Message'; $field_message->textformatters = array('TextformatterEntities'); // or TextformatterMarkdownExtra $field_message->save(); Double check that it works (written in browser). Another option might be to dispense with textformatters completely and send any output through htmlentities() or the filter_var() that you are using in the inputs.

Thanks Soma, good post! A couple things to mention: 1. You need to save a page before adding files to it. So you'd want to have another $p->save() before the part where you add an image. This is because in order to place a file in the page, it needs to exist on disk first (so that it has a place to copy the image to). Before you save a page, it only exists in memory. Though if you found that actually worked, let me know–maybe I found a solution in a late night coding session and forgot about it. 2. To add a single image, you'd need to do $p->image = 'path/to/image.jpg'; rather than $p->image('path/to/image.jpg'). This is because there is no Page::image() function. I updated your post for this. 3. For others looking at this code sample, you may need to add a $page->setOutputFormatting(false) depending on the context and if PW gives you an error about needing to turn off output formatting.