Leaderboard

Locate head.inc in your templates directory, and remove the following line (probably line 67) from it: $children->prepend($homepage); Should do the trick. It's always good to read through the files, they contain a lot of informative comments to get you started.

I started with $pdo as an API variable name. But it didn't feel at home in ProcessWire, which uses clear names for all API variables (page, pages, users, input, sanitizer, etc.). The problem is $pdo feels like a brand name and someone not familiar with what PDO won't realize that it's referring to a database. So I thought it was best to call the API variable exactly what it is, which is a $database. Ultimately $database is more consistent with our API variable naming system than even $db, as none of the other API variables are abbreviated. As for confusion between $db and $database, I would only have that concern if we were planning to keep both mysqli and PDO long term. The $db will be deprecated and eventually dropped as an API variable. But we'll give it a major version or two.

FYI, this is still happening - made good progress on capturing and repeating changes to Templates today. I expect this will take a while though, as this is not quick and simple by any means - this is still a spare time project, and I have very little time at the moment...

Be careful not to pass values from $input directly into a selector. They would need to be filtered before going into the selector. // convert to unix timestamp then back to string, just to ensure it's valid (this is just one way) $date = date('Y-m-d', strtotime($input->post->date)); // sanitize name to be a pageName $name = $sanitizer->pageName($input->post->name); if($pages->get("parent.name=$date, name=$name, template=event")->id) { /* set error to 1 */ }

Thanks for the update Rasmus. Eagerly waiting and definitely paying (if you think about making it commercial).

Sorry I'm a little behind with messages here, I'll be caught up by mid week. But I've got a good excuse. Yesterday Karena Savannah Cramer was born. She is our 2nd daughter (Hanna Ryan, age 3 is our first). We will all be coming home from the hospital hopefully tomorrow.

Check it out this page with useful jquery plugins. Might help you!

Example: https://github.com/stojg/slycrop/blob/master/slycrop/code/SlyCropEntropy.php Seems like this might be a nice way to auto-crop.

Absolutely right, the first thing you should do when you want to develop your own templates is reading through all of the template files of the default site profile. Afterwards, be sure to also checkout Soma's Markup Simple Navigation module that makes rendering a really usable navigation really easy while still providing a lot of flexibility.

Edit: somehow I overlooked, that teppo already found the exact same thing ages ago... Don't mind, I just have to (!) get something done with Typo3 and try to make it standable by surfing through the Processwire forums... While directly linking to the URL in your menu is certainly the better idea, I think you just have a small error there: Should have been: <?php $session->redirect($page->redirect); I've been using this approach for quite a long time without any problems. It's nice if you want to provide a link to an external URL that may change over time.

In < PHP 5.4 you can't use this inside of closures i think.

I'd forgotten about Angular et al - thanks for the reminder. Basically, +1 to what boundaryfunctions said Javascript will get you an extremely fast interface for any web-capable device. Just remember though there are considerations like barcode scanners to think about. Though a USB barcode scanner essentially just a keyboard that types the code and presses enter (I've tried it, that's all it does once it's converted it to numbers ) I'm not sure whether it would be the same on a hand-held barcode scanner that runs your web app - it might not be that easy to talk to the scanner. Certainly for a smartphone you wouldn't be able to talk to a third-party barcode scanner app easily, but theoretically it could work on a "proper" handheld device for shops.

or $phpDatabaseObject

Not sure about next few days, but in week or two at least. Want to test it more here. But so far - it seems to provide super nice editing interface.

Did you try the #1 option fromm this link http://processwire.com/api/modules/multi-site-support/? This is how I have all sites in my server, and it works great. There is only one "wire" folder, so upgrading is just a matter of replacing that one folder.

I have new version coming that introduces ability to create new pages. I would be extremely happy to get some feedback about the methods and arguments I am planning. Currently it works like this: $fredi->newPage("templatename", "title|summary|body"); or $fredi->newPage("templatename", "title|summary|body", $parentPage); That would open new modal with title, summary and body fields. By default it creates new pages under the current page, but you can define alternative parent page there also. I have also created ability to set fieldWidths, just add =XX to fieldname and it gives the width. Those can be used both in edit and new page modals. Like this: $fredi->render("title|author=50|summary=50") I want to take this further: defining required fields and also for new pages prevalues and possible hidden fields. This means that simple string based fields definition doesn't fly that far, or it needs some super nice syntax. Ideas?

I just did the latest install on an Arvixe Windows Hosting IIS 8.0 - so far it looks like it is working okay. Still more testing to come. I take that back..lol!

And you can even ditch $news in this bit $news = $pages->find("template=news-item, section={$section}, sort=-news_date, limit=5"); ..... foreach($news as $newsitem) like this... (assuming you've ditched $section as well) foreach($pages->find("template=news-item, section={$page}, sort=-news_date, limit=5") as $newsitem) { //do your stuff } Power of nesting! Recently discovered this. It works a treat. For my testing, I have been leaving both styles in my code, commenting out the first of course, with notes about the second shorter version...for my learning purposes... //Aside: Btw, dear gurus, does the 2nd style affect performance? Other issues? If too long maybe can cause readability issues...

You can also ditch the ?>. You don't want any (invisible) characters after the >. I.e. trailing whitespace can lead to "headers already sent" errors. Those are notoriously hard to debug. Another thing you might consider is using a function. This way you can re-use the function in other templates. This might seem trivial or even more work, but in the long run you benefit when you want to change someting. function newsList($newsItems) { if (!count($newsItems)) return "There are no news-items found."; $out = ""; $out .= "<ul class='list'>"; foreach($news as $newsitem) { $out .= "<li class='list-item'>"; $out .= "<section>"; $out .= "<h5><a href='{$newsitem->url}'>{$newsitem->title}</a></h5>"; $out .= "<em>{$newsitem->news_date}</em>"; $out .= "</section>"; $out .= "</li>"; } return $out; } echo newsList($pages->find("template=news-item, section={$page}, sort=-news_date, limit=5")); Written in the browser, so not tested but I think you will get the idea.

I imagine what you want could be archieved nicely by some kind of offline-capable Javascript MVC app built with something like Angular.js, Ember.js, Backbone.js or similiar frameworks. This way you can make it feel very quick and at least do some meaningfull stuff, when the server is offline. You could still use Processwire for managing the data and quickly build a JSON API to communicate with.

After doing some testing here, it looks like we can run PDO and mysqli at the same time without any real problems that I can detect. So I'm going to backtrack a bit and go with Teppo's idea of keeping them both. Mysqli will be deprecated in PW, but remain there for a couple major versions at least just so that there's less chance of breaking backwards compatibility. The way I've set it up locally is that $db refers to mysqli as it always has, and $database (a new API variable) refers to the new PDO driver. So you can choose to use whichever one you want. The core and core modules will only be using PDO. The mysqli driver ($db) isn't actually instantiated until something calls upon it. That way there's only overhead of two database connections when/if your site needs mysqli for an older module or something. $db; // refers to mysqli $database; // refers to PDO As a result, it will not be necessary to consider PDO in order to make your templates/modules compatible with ProcessWire 2.4. But if you want to take advantage of PDO, while still being backwards compatible with older versions of ProcessWire, then you'd still have to have some duplication: if(wire('database')) { // Newer ProcessWire: PDO is available } else { // Older ProcessWire: only mysqli available } I'd imagine that once PW 2.4 has been out for a little while, people won't use $db (mysqli) at all anymore in PW. But using Teppo's suggestion, we can at least make it available for the foreseeable future, to reduce the chance of compatibility issues during future upgrades.

$cat = $sanitizer->selectorValue($page->title); // works $p = $pages->find("portfolio_categories*=$cat, template=portfolio, sort=-Project_Date"); This doesn't work because a page field doesn't work with operators and titles... as teppo explained. So you could imageine this: portfolio_categories*=mycategory could be seen same as: 1003|1004|1005*="mycategory" So you would need to give it a page id or a page array and PW will make the rest. portfolio_categories=$somecategorypage If you do echo $somecategorypage, the toString() method of page will output the id... So it would be like this now: 1003|1004|1005=1004 Or if you use a page array. echo $pageArray it will return a 1003|1004|1005 string which is usable also in a selector. 1003|1004|1005=1003|1004|1005

I've always happily used VI (VIM) and always will. But I found a way to make the newest PHPStorm look and behave like VIM, so that's what I'm slowly adapting to. So far I like it, it's a fairly impressive piece of software. Lets me still be in VIM (or at least trick me into thinking I am) while giving me all the power of PHPStorm. I was also motivated by their support of open source–they provided the full license for free for ProcessWire development.

You're right Ryan. I knew that onjegolders knows this, and just wanted to give him the idea of how to do it. But we can't forget that more people can follow these advises...

Looks like a good creative use of tags there. I hadn't planned on them being used that way, but it seems like a good use case. It makes me think I should add a hasTag() function or something, so you wouldn't have to do something like a strstr() and would instead have reliable word boundaries between tags.

Anyway, if you would decide to do that check, you could do it like this: if ($pages->get("parent.name=$input->post->date, name=$input->post->name")->id) // set error to 1 edit: Ryan has some important additions to this on a post bellow

I always start blank and do my custom css with some exceptions. For me layouting is easy once you know the ins and outs and css frameworks mostly just get in the way for my needs. And for special things and micro layouts they never provide what I need anyway. That of course is from a guy who does website layouts since over 15 years.

Not that it matters much, but you might want to reconsider that statement: http://nikic.github.io/2012/01/09/Disproving-the-Single-Quotes-Performance-Myth.html. Quotes don't matter, but concat method ("foo" . $var . "bar") on the other hand does tend to be slightly easier on eyes because many editors won't actually recognize a variable inside quotes (ie. string interpolation) as something that should / could be highlighted. So, essentially, use whichever you prefer. Just wanted to point out that micro-optimizations like these are a) futile and b) often misunderstood -- and thus generally not worth even thinking about

If you have few variations of sort you could do it with a switch statement: switch ($get) { case "name DESC": $sort = -name; break; case "name ASC": $sort = -name; break; // and so on... } If there are more variations you can automate it like this: $sort = explode(" ", $get); $order = $sort[1] == "DESC" ? "-" : "" ; $value = $sort[0]; $pages->find("template=basic-page, limit=10, sort=$order$value");

This also from the API docs.... http://processwire.com/api/selectors/

I haven't tried this module with languages support, but thanks for letting me know that they are not compatible. You should be able to retrieve the $languages API variable via the wire() function, i.e. wire('languages') or wire()->languages are both valid syntax. $languages is a PageArray and can be iterated. Multi-language field types implement FieldtypeLanguageInterface. If you wanted to find all multi-language fields in the system, you could do this: foreach(wire('fields') as $field) { if($field->type instanceof FieldtypeLanguageInterface) { // this is a multi-language field } } Something else to mention about multi-language fields (all of which are text-based, currently) is that their value is actually an object of type LanguagePageFieldValue, rather than a string of text. Its __toString() value is reflective of the user's current language. When outputFormatting is on (as it is on the front-end), it is converted to a string automatically. But when outputFormatting is off (as it is in the admin) the value is a LanguagesPageFieldValue object. There is also another type of multi-language field known as a Multi-language alternate field.These are quite a bit simpler in that they are just a regular field with any fieldtype. But they are recognized as multi-language by name convention. If you have a field named "myfield" and another named "myfield_es", and you have a language installed named "es", then "myfield_es" is assumed to be the Spanish version of "myfield", while "myfield" is assumed to be the default language version. On the front-end (outputFormatting on) ProcessWire knows to substitute one for the other when the user's language matches the field name. If there is a lot of code involved in configuration of an autoload module, then I prefer to put it in a separate file so that it's not taking up any memory for the non-admin requests that don't need it.

"Create Pages" defines if users with specified role can add pages with that particular template.

The simple PHP OR comparison solution is very common. The in_array solution is more flexible. The PW solution owns them all =)

You're mixing vanilla PHP with PW API. Selectors are PW specific. I don't know you guys know that you can also do this in PW (usually people miss this) if($page->is("template=home|basic-page")) echo "has template";

.. or optionally this way, especially if there are more than two options: <?php if ( in_array($page->template, array('home', 'basic-page')) ) echo "something"; In your example syntax you're comparing value of $page->template (which here returns template name as a string) with regular PHP string "home|basic-page". You can't include conditional logic within strings, they're essentially just chunks of plain text

*grunts*

I'm not really sure I get what you're trying to do here and what's wrong, but isn't this essentially what you're describing there: $start = 0; $limit = 15; $values = $pages->find("parent=/, start=$start, limit=$limit") If you need total count of possible results (without limit) you could always use $pages->count() to do that separately: $total = $pages->count("parent=/"); // or like @nik pointed out below: $total = $values->getTotal();

The problem is scalability. Putting them on top wil give performance issues as it has to reassign the index for all siblings.

This sounds like a good solution to me. I can see this being useful. Though I'd probably want to make any relative paths relative to the /site/templates/ dir, just to prevent any ambiguity about the starting point.

I don't like the idea of overwriting any persistent property with a transient value, in any model. It's just extremely bad practice. Having the ability to specify the template on render makes more sense - after all, you're not changing the template of the page, you're changing which template gets rendered. Not the same thing, unless you also plan on calling save() for some odd reason

Thanks for the info on Adminer. Looks interesting. I tried SQL Buddy recently too, and really loved the simplicity of it.

Maybe you could make a adminer based module so you could have a "database" link in "setup"