Leaderboard

You've found one of the times where a custom table would be best The connection is already done actually if you're using the same database as your ProcessWire install (may as well) - this way you can use the existing $database connection. SiNNuT's example above should probably be $mydatabase to differentiateas that bit of code is for connecting to another database entirely. PDO is basically a database abstraction layer (think my terminology is right there). The underlying database is still mySQL, but PDO means that the same queries could be used for many different types of database backend (Microsoft SQL server etc). There's an example from StackOverflow here that I'll borrow from and amend to do a basic query using ProcessWire's $database: http://stackoverflow.com/questions/767026/how-can-i-properly-use-a-pdo-object-for-a-select-query $query = $database->prepare("SELECT * from your_table where field_name = :name"); $query->execute(array(':name' => $name)); while ($row = $query->fetchAll()) { // Do something with your rows } The reason for preparing the select query with the :name placeholder (in this example) is that your variable (or string) for :name gets properly escaped to prevent SQL injection. It's a little more verbose, but it does the job nicely. I'm pretty sire you could just have done "WHERE field_name = $name" but the above is safer if you're not sure what someone might pass to that query. For your counting requirements you might be able to do adapt the following query from this forum topic: http://processwire.com/talk/topic/3515-processwire-24-compatibility-for-modules/ ): $query = $db->prepare("SELECT COUNT(*) FROM my_fake_table WHERE name=:name"); $query->execute(array(":name" => $name)); $count = $query->fetchColumn(); The queries are a bit different to regular mySQL, but there are a lot of PDO query examples out there - a quick Google search for PDO SELECT DISTINCT should get you started.

Using SQL I can select rows using "DISTINCT", for example if I have 100000 rows with different IP addresses, I can count all the distinct IP addresses in a table (or field) with a single SQL query in a split second. To my understanding to do this using the api and selectors I would need to foreach through every single page, which is mighty memory intensive and slow. Correct? Yes. 'distinct' and 'group by' like functionality can't really be done very efficiently using the API. So if, like it seems in this case, we're talking about lots of rows/pages/fields you probably want to use an SQL query instead of the API. A google search like "site:processwire.com/talk sql distinct group by" will give you some interesting threads on the subject like, http://processwire.com/talk/topic/2047-group-by/?hl=unique#entry19148 and http://processwire.com/talk/topic/2038-distinct-selector-in-processwire/ If so, I still have a need for direct sql queries, even if using pages rather than custom tables. I've searched for examples of how to do these and gather the $database var is used, but there don't seem to be any clear examples of connect, insert, select etc using PDO.Can someone point the way if such exist? Do I need to "connect" or is a connection already available, is this what $database represents? Yes, $database gives/creates a PDO instance from ProcessWire $config API variable, like this (from wire/core/WireDatabasePDO.php): $database = new WireDatabasePDO($dsn, $username, $password, $driver_options); So the connection part is easy, $database is always available. From there on you can just use a 'select distinct' query and PDO (such as the example Diogo mentioned). Just as well for inserts, deletes etc. I don't think this i specific to PW, it's just SQL/PDO Of course when you use PW pages you could easily use the PW API to handle all the stuff it is really good at, and just use some direct SQL queries where you need it. When using pages make sure the fields you connect to say a 'logentry' template are unique to that template. This is because a field table only contains a pages_id reference and it's data, and it would need a more complex query if the table contained data belonging to other templates. Then there also is the option to create you own fieldtype/inputfield, let say FieldtypeLogentry. This way you can have one field hold as many columns of data you need and it would be only one database table. I haven't yet created a fieldtype/inputfield myself but i've heard say that it's not that hard. Anyway, lots of options, just choose the best according to your needs and data(base)structure. If a custom table works best for you, go for it.

A Pw field is its own table in the database so don't worry about it A lot of us usually set up a config page or something under the admin for things where you'll collect data with not so many fields. Of your example above requires dozens of fields of data then maybe a custom db table is the way to go, but honestly it's not a problem storing stuff as pages in Processwire - you get API access if you ever need to pull statistics and it's not adding overhead just having the pages simply exist I'm your site. I've set up config pages before for anything from a list of countries and associated country codes and currencies (simple 3 field template to use as a select field on a checkout as well as currency lookups etc - you can use markup cache in the template so it only re-queries to build that list once a week (or far longer in this case as countries don't change that often). I've also created a config page for simply storing Yes and No as pages to use as radio buttons on a form - this felt the strangest but I knew I'd want to pull some stats later on and there were a few yes and no questions so I had a few fields like this. The hardest part is un-learning stuff you've learned from other systems, plus the fact that every field is a table and that that's not as crazy as it sounds and certainly not as resource hungry as you might automatically assume (I know I did) as ryan has been very careful in how the system works and it works fast for many hundreds of thousand of pages and beyond - and that's when you're doing searches. For statistical data that just sits there and doesn't do much a lot of the time for example, well that's just like having untouched data sitting in your database - it's there albeit a bit more visible which is maybe why it bothers you So yeah, for simple stuff you want to store like what you've posted, if it's not stacks of fields then use pages, but if not then your own db table is fine and it's easy enough to query it with some $database commands.

$config->paths->[property] refers to the server disk paths, and $config->urls->[property] refers to the corresponding URL. A Page object is something represented in a database, not a disk path on the server. So you can't draw a literal relationship between server paths and a page, since there is no physical file or directory for a page. Where you can draw the relationship is that the term 'path' or 'paths' always refers to the internal, server-side representation. Whereas the term 'url' or 'urls' always refers to to the external, client-side representation (something you would deliver to the browser).

You can create your own databases and execute queries easily with PW. Here is an example from Martijn that I found with a quick search (there are many more in the forums) http://processwire.com/talk/topic/4691-can-i-use-my-own-database-table-in-processwire/?p=45770 That said, I thinks it's proven already that PW can handle that amount of pages, and using them instead of custom tables would give you the benefit of being able to use the API of course. I guess I'm not exactly saying "what the hell man, just use pages!", but you need to find a balance between performance and how easy it will be to work with that data, knowing that performance will be also dependent on the system your site will live in and that there are cool tools like pro-cache that could help you with that.

Plase correct me if something is wrong, I'm still learning the processwire way xd. According to the API Docs http://processwire.com/api/variables/page/ $page->path The page's URL path from the homepage (i.e. /about/staff/ryan/) $page->url The page's URL path from the server's document root (may be the same as the $page->path) So I have to migrate a site from development to production server and all the links were messed up. Why? Because I was using $page->path for redirects. Changed redirects to $page->url and Presto! everything works fine. And, When to use $page->path? Use $page->path when importing other page. example $people = $pages->get('/system/people'); $friend = $pages->get($people->path . $input->urlSegment1); Use $page->url when you need a redirect $session->redirect($friend->url);

Hey leoric, take a look at this post, where the kind Macrura gave me (and us all ) some insights on how to filter a form's results based on different criterias. It should point you out on what you are trying to achieve. Let us know!

I'm not an expert in this, but you can have a hidden field in that form with a random number or string generated with PHP only for the logged in user, store in in a session and check for it when the form is submitted. edit: in your case it's not a form, but you can still pass some info to the page, that can be sent back to server together with the file.

Here's a video of a module we're working on that I thought you guys might like. The module, Lister, provides a different type of Page List than the tree that you usually interact with in ProcessWire. It gives you a table of pages with customizable columns, filters and actions. Rather than try to explain what it does, I figured I'd show you. This module also uses a new (soon to be released) Inputfield invented by Apeisa, developed by me, and sponsored by Avoine, called InputfieldSelector – it's what you see on the configuration screen as well as the Filters tab. I recommend bumping up the size/quality to 720p so that you can properly see everything. The video has no sound... I tried to do one with narration, but that didn't work out.

Short tip Use the ajax powered search to find pages you want to edit—it's a super-fast way to get around the admin. Longer (but same) tip I was on the cusp of not writing this because it is likely so obvious to so many, but just in case you are like me in terms of navigation in the Admin for editing pages... In PW 2.4 the new search makes finding pages lightening fast. While some themes from before 2.4 was released display recently edited pages to help speed navigation, the new default theme in 2,4 doesn't; and I missed that a bit. But the new search is super fast so now whenever and wherever I am in the Admin, if I want to edit a page I just type in the search box, it ajax-pops, one click and I'm in the page ready to edit—no need to visit the page tree Thanks to Ryan and crew for this small but great advance OK, back to work.

uuh, 20:14 time for crime scene and soup. See you later!

@SwimToWin: to get all fields from a page (template) you can use a snippet like this: foreach ($page->template->fieldgroup as $field) { But you have to check what types of field you can export to csv, I think. I'm not sure but I think so. Or maybe I'm wrong. If you want to check for fieldtypes you do it like if($field->type instanceof FieldtypeFile) // or FieldtypeText, or ...

Soma has an excellent script above that uses the new WireArray::explode() function to bulk-export pages to CSV. But the script requires that you hard-code any custom fields for your pages. Is it possible to get the field names and field values dynamically (meaning, it is not necessary to hard-code each field key and value)? Example: (to illustrate my point -- this code snippet does not work at present) $array = $pages->find("template=foo")->explode(function($items){ foreach ($items as $key => $item) { $arr[$key] = $item->$key; } return $arr; # Or, perhaps just cast using (array): # return (array) $items; }); $fp = fopen('export.csv', 'w'); $i = 0; foreach ($array as $fields) { // Add headings to the first line. if($i==0) fputcsv($fp, array_keys($fields), "\t"); fputcsv($fp, $fields, "\t"); $i++; } fclose($fp); Note: Page fields are exported with their ID ("1001"), in a future version the script could look up these Page IDs. See also: PHP.net: get_object_vars StackOverflow.com: How do I convert an object to an array? StackOverflow.com: Convert PHP object to associative array

My best new toy in town

It can. Our sites directory is a good example of this, as it does pretty much everything you describe with FormBuilder. However, we review the submissions before approving them to be published on the site, and I always recommend this even if FormBuilder will let you publish directly. For instance, I've had a few submissions that were spam (though not obvious at first). Anything that gives users access to publish something on your site needs some eyes on it, unless you are dealing with a limited group of trusted users. But FormBuilder will let you do either.

Is $page->image a single image (max files = 1?). If so, access $page->image is an object of type Pageimage, which has no remove() or delete() or deleteAll() methods. Those are instead methods of the WireArray that contains the file(s)/image(s). You could access that a couple of different ways. One way would be to get the "unformatted" value, which for files, always returns the containing WireArray: $page->getUnformatted('image')->delete($page->image); Another way would be to access the 'pagefiles' property of the image, which also refers to the containing WireArray. $page->image->pagefiles->delete($page->image); I mention the above examples for explanation, but PLEASE IGNORE THE ABOVE. Any time you are performing manipulations to a page, you should have the page's output formatting turned OFF. So there really isn't any situation in which you would use the above API examples... because it would mean you are modifying a page that is in an output-ready state, rather than a change-ready state. That's why ProcessWire throws an exception if you try to save a page with output formatting state active. The second point I want to make is that simply calling a delete() is queuing a deletion, not executing it. You still need to $page->save() or $page->save('image') before the deletion is committed. Given all this, I think this is what you want: $page->of(false); // turn off output formatting $page->image->delete($page->image); // you can use this line... $page->image->deleteAll(); // ...or this line (choose one) $page->save('image'); // or use $page->save(); if also saving other changes

I think that usernames as MD5 hashes are going to be difficult to look at on the admin side, and kind of defeats the purpose of the name field being a readable, unqiue identifier. I would create a separate field to handle your md5 hash and add that to your user template. Lets say you created a text field called user_hash and added it to your user template. You could have it automatically updated every time a user is added or saved just by putting some hook code in your /site/templates/admin.php file $pages->addHook('saveReady', function($event) { $page = $event->arguments(0); if($page->template == 'user') { $page->user_hash = md5($page->name . time()); } });

One of the main reasons for creating a Wiki from scratch is because what is needed really isn't quite a wiki at all. In its trues sense a WikiWikiWeb (the first one) is a collaborative anarchic information repository that uses a common markup system and has no editorial structure. That is great if you want to create a Wikipedia clone (and have all the headaches that go along with it), but not necessarily much use if what you want is a formal document (articles are documents) repository with submission, editorial and publishing protocols. If you want the first, use Wikimedia or one of the thousand and one similar versions out there. If you want something more structured, then designing one from scratch could be very interesting. I am sure you will get lots of advice when you need it!

@ adrian THANK you very much!! This two articles are great... and with this sentence and your code example echo $page->Departure_AUI ? "<div>Aui: {$page->Departure_AUI}</div>" : "";made it "click" in my head and again I learned something important, now I have to do only the "cheatsheet" and finally understand it myself, this would certainly dissolve another big knot in my head ... but one step after the other

You are already connected. The example I gave above and an understanding of the db structure are all you need.

Processwire is currently our #1 choice for all things CMS. Latest Processwire-built site and many more coming: Reims & Co http://www.reims.fi/ Signup to our mailing list for future updates and cool projects: http://www.nordenswansiirila.fi/

Thanks for fixing my sloppy code Also, here is a great article on ternary operators: http://davidwalsh.name/php-shorthand-if-else-ternary-operators Anything you think you might be sacrificing in PW by not using templating syntax, is more than made up by the abilities of simple everyday PHP. Ryan also wrote a good article here: http://processwire.com/api/why-php-syntax/

I'd recommend using d3.js for data visualization: http://blog.pixelingene.com/2011/07/building-a-tree-diagram-in-d3-js/

really amazing! this is going to make updating large product catalog pricing, and other details something that the client can do with a little training.. sure beats any custom admin page listing i have done so far! not sure if this is possible, but one feature that I use in my custom page lists is icons for certain statuses; for example, if there is text in the body field i might show a fontawesome text icon; or if the page has images, a picture icon; this lets the admins see at a glance what pages might be missing images (helpful when setting up a site, and loading products for example); this could be done with llister as is, by using a filter, but i also wonder if there was a way to have a status column, like "if condition a, "insert html here"; if ($body) echo "<i class="fa fa-file-text-o"></i>"...

You might want to try what Ryan suggests here: http://processwire.com/talk/topic/1142-lots-of-sessions/?p=30237. Session garbage cleaning isn't currently working on certain systems with default config (more about that here). Garbage cleaning for sessions is always random and it's possible that it just hasn't happened for a while. Hard to say without knowing a bit more about your environment, how often new sessions are created etc. Anyway, above solution shouldn't cause any harm either, so I'd try if it helps.

Unless I'm somehow missing your point here, inputfield doesn't matter when working over API. Insert values and save the page, that's it: $page->of(false); $page->page_field = $pages->get('name=my-page'); $page->page_field = 1; // etc. $page->save(); For more examples take a look at this post.

If you're using Universal Analytics (the new/beta Google Analytics), here's how to add an event ... ga('send', 'event', { 'eventCategory' : 'Your Category Here', 'eventAction': 'Your Action Here -- like click, view, etc', 'eventLabel': 'Event Label Value Here' } );

Really difficult to say much without much info... PW version? Server environment? Any hooks doing things in Admin? Any modules doing stuff in the background? etc?

Hi Felix, be sure utf-8 is selected when saving your csv sheet. That should do the trick for you.

It's not necessary here, as ProcessWire doesn't include the http host with url() calls... just the path. So you can prepend the http host yourself, or make a custom function to do it for you. For example, you make an uppercase "URL" property to refer to your own version: wire()->addHookProperty('Pagefile::URL', function($event) { $event->return = "http://www.domain.com" . $event->object->url; }); Usage: <img src="<?=$page->image->URL?>">

Hi 3fingers, Here is the code that processes the form: https://gist.github.com/outflux3/5690429 here is the form itself: https://gist.github.com/outflux3/5690423 i didn't post the form results, but that's just a table that shows the results; hopefully the processor and form code will help! -marc