Leaderboard

You can have a look at this tutorial (in german), it shows the pw basics: https://code.tutsplus.com/de/articles/4-reasons-to-choose-processwire-as-your-next-cms--cms-25062 ( Grüße aus Oberfranken )

Put this in your ready.php (I'm not sure if this hook affects errors and exceptions too) wire()->addHookBefore('WireLog::save', function($e) { if ($this->wire('user')->hasRole('superuser')) { $e->replace = true; $e->return = false; } });

ProcessWire detected that this isn't set in your hosts server setting and warns you about that. I never have seen this warning on any of my 40+ projects, hosted by differend hosting agencies. And it wouldn't be a good pratice to silently change server settings, as it may have a special reason, (that is, by its nature, out of the scope of the PW installer). PW does several checks with the installer, and some more, less important ones in intervals, only visible for the SuperUser. Long story short: your host simply misses the local setting. It is the same like with your Computer System, e.g. Windows. If it wouldn't have set any locale, you may get the (for you) wrong english settings. Wrong date, time and float values, etc. etc. It is a missing PHP init setting on your (bought) host.

I think you have to call save on the field object, not the global $fields. EDIT: what about: $page->set("hiden_field", $value); Because I think you are trying to save the actual field (in the whole PW context), not the field that actually belongs to the page. This would set the field value so it get's saved after the hook.

Thanks for feedbacks !

@ukyo: first of all, thanks for extending WireMail. I think this makes your module more useful in the long run. Now, sadly there's a bit of a downside to this: a week ago Ryan pushed an update to the dev branch (related to this issue) that changed the way WireMail modules are found by the core. In short, the class name must now start with "WireMail". One can get past this auto-detection feature by manually specifying (in a config setting) the name of the WireMail module to use, but in order to work optimally both now and in the future, I'd still consider renaming this module to something that starts with "WireMail". Thanks again, and sorry for the trouble

So I made a mistake by not taking into account the ProcessWire's module naming convention. I totally forgot the fact that if module name starts with Fieldtype it becomes a fieldtype and PW will treat it like any other fieldtype. Like it would try to let you add a new field with that fieldtype. Which we do not want for our GraphQL extension modules. I already faced bugs because of this on admin side. So naming rule for GraphQL extension modules will be changed from suffixing the name with GraphQL to prefixing the name with GraphQL. So it is GraphQLFieldtypeMapMarker instead of FieldtypeMapMarkerGraphQL. Other than that, everything is the same as before. I'll also update the previous post to reflect this change. Sorry if this causes inconvenience to anyone. The updated version of ProcessGraphQL that works with new rules is available for use in latest release.

Hi @fermion, willkommen in der wunderbaren Welt und der hilfreichen Community von ProcessWire. Wir schreiben hier meistens in Englisch, damit es alle verstehen können. Ich hoffe du verstehst was die meisten hier schreiben. Now I will continue in english: Regarding your question about a risk for setting the locale. I would recommend to set the locale and date format to the corresponding language. Here is the code I use on a large website in my _init.php: $lang = $user->language->name; if ($lang == "default") $lang = "de"; $date_lang = array(); switch ($lang) { case 'en': setlocale(LC_ALL, 'english_gbr', 'english_britain', 'english_england', 'english_great britain', 'english_uk', 'english_united kingdom', 'english_united-kingdom'); $date_lang[0] = "%A %B %dth %Y at %I:%M %p"; $date_lang[1] = "%B %dth %Y"; $date_lang[2] = "%I:%M %p"; $date_lang[3] = "%A"; break; case 'nl': setlocale(LC_ALL, 'english_gbr', 'english_britain', 'english_england', 'english_great britain', 'english_uk', 'english_united kingdom', 'english_united-kingdom'); $date_lang[0] = "%A %B %dth %Y at %I:%M %p"; $date_lang[1] = "%B %dth %Y"; $date_lang[2] = "%I:%M %p"; $date_lang[3] = "%A"; break; case 'fr': setlocale(LC_ALL, "fr_FR", "fra", "fr_FR.UTF8", "French_France"); $date_lang[0] = "%A %d %B %Y à %kh%M"; $date_lang[1] = "%d %B %Y"; $date_lang[2] = "%kh%M"; $date_lang[3] = "%A"; break; default: setlocale(LC_ALL, 'de_DE.UTF8', 'de_DE@euro', 'de_DE', 'deu_deu', 'German_Germany.1252'); $date_lang[0] = "%A, den %d. %B %Y um %k.%Mh"; $date_lang[1] = "%d. %B %Y"; $date_lang[2] = "%k.%Mh"; $date_lang[3] = "%A"; break; } Yes, normally your content is embedded in "fields" in ProcessWire. Then in your template file you output the content of the field in a HTML structure you like, for example a div or a metatag. I agree, that there are not much german tutorials that cover ProcessWire, but I think this is because almost the whole developer community is used to speak and understand english. Anyways: Here is a nice tutorial in german (there are more in the same channel) You will find a nice blog post "Warum ProcessWire die beste Wahl für Ihre Website ist (nicht immer, aber in den meisten Fällen)" on my website, which isn't a tutorial, but an explanation, why and when to use ProcessWire.

I updated WireMailPHPMailer module to PHPMailer v6. I will update WireMailPHPMailer support post. I have request for deletion of this topic and WirePHPMailer from module directory.

I plan to do so, yes.

I don't have any reason for not extending base WireMail class. This is why i updated module and now module extending bas WireMail class. Now you have 2 usage types: 1. Use directly PHPMailer class 2. Use extended send method For InputfieldHelper requirement, its easy to create configurable modules with this module and usable module for many cases, i won't remove requirement of this module. Like i mentioned, i am author of WireMailPHPMailer, i am not caring about module usage statics, if someone need PHPMailer module, they can use it. - I tested swift mailer module (smtp) - I tested base WireMail class (smtp) - I tested mailgun (curl) I am not prof. of mail sending but when i make simple mail send tests with same settings (mailgun not included), https://www.mail-tester.com/ test result not ok for me (problem with DKIM). My test result with PHPMailer 10/10, this is why i am using PHPMailer library with my modules.

Simple Contact Form Using Google Recaptcha & Valitron validation library I just finished creating a simple Contact-Form for a client's website so i thought it would be really helpfull to share it with the community. The contact form uses: Google recaptcha for validating the user is not a robot (https://github.com/google/recaptcha) Valitron validation library for validating the form fields (https://github.com/vlucas/valitron) Twitter Bootstrap 3.0.0 for form HTML The contact-form is located inside a contact-page, so the bare minimum you need in order to setup your own is: contact.php (template file used by your contact-page) _contact-controller.php (file used as a controller for your contact-form functionality like send email, validate fields etc) 2 extra lines inside your composer.json file So, let's start: First you need to update your composer.json file adding 2 lines inside the require object: "vlucas/valitron": "^1.2", "google/recaptcha": "~1.1" Here is a sample composer.json file: { "name": "processwire/processwire", "type": "library", "description": "ProcessWire CMS/CMF", "keywords": [ "cms","cmf", "content management system" ], "homepage": "https://processwire.com", "authors": [ { "name": "Ryan Cramer", "email": "ryan@processwire.com", "homepage": "https://processwire.com", "role": "Developer" } ], "require": { "php": ">=5.3.8", "ext-gd": "*", "vlucas/valitron": "^1.2", "google/recaptcha": "~1.1" }, "autoload": { "files": [ "wire/core/ProcessWire.php" ] }, "minimum-stability": "dev" } open console and navigate to processwire root folder (where composer.json file is) on this step i assume you have already setup composer for your project, otherwise google it run the following command: composer update this will create a vendor folder (if it does not already exist) and download valitron and google recaptcha libraries. Then open your contact-page template file(usually named contact.php inside your templates directory) and add the following: * Note: The form below uses bootstrap 3.0.0 css, so if you are using something else you need to make the appropriate changes. <?php namespace ProcessWire; include('_contact-controller.php') ?> <div class="container"> <div class="row"> <div class=" col-md-4"> <h2>Contact Form</h2> <?php if($session->flashMessage):?> <div class="alert <?=!$session->sent && (!$v->validate() || !$resp->isSuccess()) ? 'alert-danger' : 'alert-success'?>" role="alert"> <?php echo $session->flashMessage;?> </div> <?php endif;?> <form id="contact-form" method="post"> <div class="form-group <?=$v->errors('name') ? 'has-error' : ''?>"> <label for="name">Name</label> <input class="form-control" name="name" id="name" type="text" value="<?=$sanitizer->text($input->post->name)?>"> </div> <div class="form-group <?=$v->errors('email') ? 'has-error' : ''?>"> <label for="email">Email</label> <input class="form-control" name="email" id="email" type="text" value="<?=$sanitizer->text($input->post->email)?>"> </div> <div class="form-group <?=$v->errors('message') ? 'has-error' : ''?>"> <label for="message">Message</label> <textarea class="form-control" name="message" id="message"><?=$sanitizer->text($input->post->message)?></textarea> </div> <div class="form-group"> <!-- Google Recaptcha code START --> <div class="g-recaptcha" data-sitekey="<?=$googleSiteKey?>"></div> <script type="text/javascript" src="https://www.google.com/recaptcha/api.js"> </script> <!-- Google Recaptcha code END --> </div> <button type="submit" class="btn btn-primary">SEND</button> </form> </div> </div> </div> <?php //here we remove the flash-message because it is already shown above the form. $session->remove('flashMessage'); //reset 'sent' variable for future submit $session->sent = false; ?> Next create a file inside you templates directory with name: _contact-controller.php: and set the required variables($googleSiteKey, $contactFormRecipient, $contactPageID) <?php namespace ProcessWire; /** * here we include Valitron & Google recaptcha libraries * make sure the path is correct in your template */ include(dirname(__FILE__) . "/../../vendor/vlucas/valitron/src/Valitron/Validator.php"); include(dirname(__FILE__) . '/../../vendor/google/recaptcha/src/ReCaptcha/ReCaptcha.php'); /** * here we add the form field values to Valitron */ $v = new \Valitron\Validator(array( 'name' => $sanitizer->text($input->post->name), 'email' => $sanitizer->email($input->post->email), 'message' => $sanitizer->text($input->post->message), ) ); /** * validation rules set for each form field * For more details on Valitron/Validator usage visit: * https://github.com/vlucas/valitron */ $v->rule('required', ['name', 'email', 'message']); $v->rule('lengthMin', 'name', 5); $v->rule('email', 'email'); /** * set Google recaptcha site-key & secret-key * create a new key from: https://www.google.com/recaptcha/admin */ $googleSiteKey = 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'; $googleSecretKey = 'YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY'; /** * set the email of the contact form recipient(usually the website owner) */ $contactFormRecipient = 'your@company.com'; /** * set the id of contact-page in order to redirect there when the form is sent */ $contactPageID = '1045'; //here we check whether the 'name' field exists inside post variables (which means the form is posted) if ($input->post->name) { //if fields validation passes if ($v->validate()) { $reCaptcha = new \ReCaptcha\ReCaptcha($googleSecretKey); $resp = $reCaptcha->verify($input->post->{'g-recaptcha-response'}, $_SERVER["REMOTE_ADDR"]); //if google-recaptcha validation passes if ($resp->isSuccess()) { //This is the HTML message $message = ' <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Contact Form | ' . $input->post->name . '</title> </head> <body> <p>' . $input->post->message . '</p> </body> </html>'; //here we send the form to $contactFormRecipient wireMail($contactFormRecipient, $input->post->email, "Contact Form | " . $input->post->name, $message); //here we set a flash-message to notify the user that the form was successfully sent $session->flashMessage = 'Thank you for your message! We will get in touch with you shortly.'; //save in session that the form is sent $session->sent = true; //finally redirect user to contact-page $session->redirect($pages->get($contactPageID)->url); } else { //self explain $session->flashMessage = 'Error while validating you are not a robot!'; } } } ?> Thats all! You now have a simple contact-form working with captcha and field validation! I would be more than happy to help anyone having problems on the setup.

v1.7.7 is uploaded, docs will come later I'm happy with the asmSelect + Select2 result. The jump on click is still present but I think it's a minor issue. There are also 2 extra field config settings: placeholder and limit for FieldtypePage and FieldtypeOptions, you can find it under the Input tab. Currently it's working with asmSelect variants only. I think these additions make using asmSelect much more convenient, feels native after using it once or twice @adrian That top checkbox would mess up the look a bit, but it would be handy otherways.

@fermion You may find two (or more) well written articles in the german c't magazin: https://www.heise.de/ct/ausgabe/2015-7-Websites-betreiben-mit-dem-Open-Source-CMS-ProcessWire-2562549.html And there was an article in 03.12.2016 (interessante CMS-Alternativen zu Wordpress) but cannot find it atm. Ah, here it is: https://www.heise.de/ct/entdecken/?jahr=2016;ausgabe=25;sort=seite_auf;seite=6 There are three articles in it. Better you buy the whole magazine for 4,50 instead the online articles one by one.

Playing around with this, I have tested repeaters and there is some code to get titles in addition to the index from FieldtypeOptions (Not sure if you like this). Just sharing what I have. $this->addHook("Pages::findObject", function($event) { $event->return = $this->pages->findArray($event->arguments(0), $event->arguments(1), $event->arguments(2), true); }); $this->addHook("Pages::findArray", function($event) { $selector = $event->arguments(0); $fields = $event->arguments(1); $fields_pages = $event->arguments(2) ?: []; $type = $event->arguments(3) ? \PDO::FETCH_OBJ : \PDO::FETCH_ASSOC; // build sql string $sql = "SELECT\n p."; // add fields of pages table $fields_pages[] = 'id'; // make sure we return the page id $fields_pages = array_unique($fields_pages); $sql .= implode(",\n p.", $fields_pages); foreach ($fields as $f) { $field = $this->fields->get($f); if (!$field) continue; $fieldtype = $field->type; $f = strtolower($f); // fielddata is always stored in the "data" column of the field's table // multilang fields have several data columns identified by the language id // we use a variable to query the current user's language, eg data1234 $data = "data"; switch (true) { // if it is a multilang field we append the language id to query the correct column case $fieldtype instanceof FieldtypeTextLanguage: case $fieldtype instanceof FieldtypeTextareaLanguage: if ($this->user->language->name != 'default') $data .= $this->user->language->id; // no break here intended! // build sql query case $fieldtype instanceof FieldtypeText: case $fieldtype instanceof FieldtypeCheckbox: $sql .= ",\n (SELECT $data FROM field_$f WHERE pages_id = p.id) AS $f"; break; case $fieldtype instanceof FieldtypePage: case $fieldtype instanceof FieldtypeRepeater: $sql .= ",\n (SELECT GROUP_CONCAT($data SEPARATOR ',') FROM field_$f WHERE pages_id = p.id) AS $f"; break; case $fieldtype instanceof FieldtypeFile: $sql .= ",\n (SELECT $data FROM field_$f WHERE pages_id = p.id) AS $f"; //$sql .= ",\n (SELECT description FROM field_$f WHERE pages_id = p.id) AS ".$f."_desc"; break; case $fieldtype instanceof FieldtypeOptions: $sql .= ",\n (SELECT $data FROM field_$f WHERE pages_id = p.id) AS $f"; $sql .= ",\n (SELECT title FROM fieldtype_options WHERE fields_id=(SELECT id FROM fields WHERE name = '$f') AND option_id=$f) AS " . $f . "_title"; break; default: $sql .= ",\n '$fieldtype not supported' AS $f"; } } $pages = $this->pages->findIDs($selector); if (count($pages) == 0) { $event->return = []; } else { $sql .= "\nFROM\n pages AS p"; $sql .= "\nWHERE\n p.id IN (" . implode(",", $pages) . ")"; //echo '<pre>' . $sql . '</pre>'; $results = $this->database->query($sql); $event->return = $results->fetchAll($type); } }); Testing with: foreach ($pages->findArray("template=families, sort=title, limit=5000", array('title'), array()) as $p) { foreach ($pages->findArray("parent=" . $p['id'] . ",sort=title, limit=5000", array('title'), array()) as $m) { foreach ($pages->findArray("parent=" . $m['id'] . ",sort=title, limit=5000", array('title', 'sku12', 'Sound_Sample'), array()) as $s) { echo ($p['title'] . ' ' . $m['title'] . ' ' . $s['title'] . '<br>'); $repeater = $s['sound_sample']; if ($repeater) { foreach ($pages->findArray('id=' . str_replace(',', '|', $repeater) . ",limit=5000", array('name', 'Sound_Type_ss', 'Files_ss'), array()) as $r) { echo '<h5>' . $r['files_ss'] . '</h5>'; echo '<h5>' . $r['sound_type_ss_title'] . '</h5>'; } } } } }

I've not heard of plans to automate the process, so, for each new install, you will have to set the configuration.

Yes the $page->set() works! thank you very much

Just in case you haven't crossed it:

Hi Marco (ciao Marco, compaesano ;)), I'm supposing you're following padloper docs (I never used it), but I suggest you to follow this nice categorization of contents by kongondo, to grasp some concepts : https://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/ As I said, I never used Padloper so I don't know its api in details, but I would go for Fieldtype Page for product variations (color, angle, etc...).

Hi @barneyy and welcome to PW! Perhaps you'd be happy with this AceEditor module instead? http://modules.processwire.com/modules/inputfield-ace-extended/

@bernhard: Another thing to keep in mind. Field Names can contain uppercase characters whereas the database fields are all lowercase, it seems. So after getting the type with the name possibly containing uppercase chars, the field name has to be converted to lowercase for the DB table "field_xyz" foreach ($fields as $f) { $field = $this->fields->get($f); $f=strtolower($f);

Thanks for the update @joshuag, great to see Recurme continue being updated. I haven't had opportunity to update my current installs yet, but have a new project Recurme would be ideal for.

PHPMailer for ProcessWire v3. Module Directory - Github repo I am author of WireMailPHPMailer. Old module using PHPMailer v5 and its extend WireMail base class. No more update will come for old version, but its still working :). This module using PHPMailer v6 and not extending WireMail base class. This module integrating the PHPMailer mailing library into ProcessWire v3. Usage almost same with original PHPMailer library (no need to include PHPMailer files). Here is a simple example usage : Using directly PHPMailer library $mail = wire("modules")->get("WirePHPMailer"); $mail = $mail->mailer(); $mail->addAddress("email@domain.ltd", "Someone"); $mail->isHTML(true); $mail->Subject = "WirePHPMailer"; $html = "<h1>WirePHPMailer</h1>"; $text = "WirePHPMailer"; $mail->Body = $html; $mail->AltBody = $text; $mail->send(); Using module like classic WireMail $mail = wire("modules")->get("WirePHPMailer"); $mail->from("from@domain.ltd") ->fromName("A From Name") ->to('email@domain.ltd') ->subject('A Message Subject') ->body('A Message Body') ->bodyHtml("<h1>A HTML Message Body") ->send(); Note : This module requires InputfieldHelper, PHP>=5.6.0, ProcessWire>=3.0.0 module.

Without a basic idea about PHP you probably won't get far with processwire imo. About your question"How to eliminate..?" It is all in the PHP files in "/site/templates/". Probably _main.php in your case.

Hello @ all, I have no idea, but approval via email does not work in my case. Here are all my get variables that will be submitted by clicking the link in the email: code gKB6jlhWTowUeahUNX6OWWvBYBxYf1D41I5LZb4ws1YsA73jmk7sQeOoU1QAy4L6f1IAnmaSKXRjINOtGFDKO92e10Y5IuTzmuHOwkGI8bWtcXaIGstDB_xzq9hhwvZx comment_success approve field comments page_id 2006 As you can see all parameters are there. As far as I know the file CommentNotifications.php is responsible to save the new status "approved" after clicking the link, but in my case nothing changes and I do not get any message on the frontend. Tracy does not complain about anything so I dont know how to check where the problem is. Is there someone who could give me a hint to check out whats going on after clicking the link to find out the problem. Best regards EDIT: Ok, I see! This doesnt work if the comments were not rendered with the render function. So using your own markup to output comments inside a foreach prevents the status change after clicking the approval link. Solution: Copy the whole Fieldtype comments directory in site/modules and make all the markup changes there. Load comment form and list via the render function and everything is fine.

To follow up from @teppo's point - is there any reason your old WireMailPHPMailer need to exist? I assume it's because PHPMailer 6 requires PHP 5.5? It sounds like Ryan might be moving PW to a 5.5 minimum sometime shortly, so maybe it's ok moving forward.

You could easily switch the mail provider or the Module extending WireMail. A downside of not using one of the big mail providers is the real chance that your email will be seen as spam on certain receiving hosts or mail providers. The mail reputation score matters when sending any email. I guess the real deal with using PHPMailer, in my opinion, is are you sending out using a properly configured SMTP gateway or not.

Just wanted to let everyone know that I sent out an email to everyone who purchased Recurme with the updated Recurme Module Package. Thanks again to everyone who tested the changes and feedback. Especially @adrian

Have to agree with this. The biggest benefit with WireMail modules is that they unify the way email is sent within ProcessWire, and thus allow both third party modules (like Tracy, Mail Debugger, and a number of others) and built-in core features to a) automatically benefit from installed WireMail modules, and b) hook into that process in a consistent way if need be. I'd say that unless you've got a very good reason not to extend WireMail, you really should. That being said, thanks for your work on this module.

@ukyo - thanks for your work on this! Please don't take this as a criticism - it's an honest question - why did you decide to not extend WireMail? I am sure you have a good reason. I think there might be other reasons as well, but the first limitation I see is that Tracy's Mail Interceptor won't work with this, nor will the new Mail Debugger module. My other question is about your choice to make InputfieldHelper a requirement. I read through the support thread for that module and I still don't get it. I am sure I am missing something and it is probably very useful for certain tasks, but I do think it will be a barrier for getting people to install your WirePHPMailer module, especially when there is already three other working mail modules. Perhaps if you could better explain the advantages to this over those other mail modules, it might help. Cheers!

Thank you @horst for everything you have done for images in PW - you deserve way more recognition than you are getting!

current state: https://github.com/processwire/processwire/commit/8fe1eb13f4cbc85c6d5dad093fc559c438c92667#commitcomment-27795259 - sadly I will not have more time this week.

Sounds to me like there's a bit of a misunderstanding here. First of all, fields are connected to templates (home, basic-page, etc.) and field values are applicable to pages using that template, so technically there's no such thing as a field with the same global value everywhere. You can solve this in a different way, though. Taking a step back, what you originally asked for was ... The easiest way to achieve this would be adding those fields to an existing template – such as "home" – and filling in the values for a page using that template – in this case your home page. Then you can do something along these lines in your _foot.php file: <?php echo $pages->get(1)->footer1; ?> In other words you can fetch a specific page ("1" in this case means the page with ID 1, i.e. your home page) and then output the value of the field ("footer1") from that page. From what you've written above, it sounds like you might've created a new template called "footer", added fields to it, and then perhaps created a new page using this template too. Sound familiar? If so, you can also use that page as well (instead of, say, your home page) to store your footer values: in your _foot.php you can get that page and output the value from it with <?php echo $pages->get('/footer/')->footer1 ?>. Does this make sense to you?

Would be cool to add support where possible. Not sure how you've handled the AsmSelect limit in the as-yet-unreleased AOS update, but maybe part of the JS could be broken off into a piece that is generic to all Page Reference inputfields. It would identify the underlying form element that contains the actual field value, and on change it would check if the limit is reached. If so it would add a class to inputfield container, and trigger some event for the container, e.g. 'limitReached'. If you go that way others can contribute pull requests for the remaining Page Reference inputfield types without reinventing the wheel for the limit check. I'd be happy to contribute here.

@tpr Fantastic! Great addition. @adrian thanks for suggesting.

I think it would be used quite often in a datatables type application, but I also am not sure about just how far to go in terms of getting away from SQL which is already very effective. I guess my main goal is to remove the need to understand the PW table/field structure/relationships, but you have put a lot more thought into this than I, so feel free to ignore my ramblings

Update: So I've been using Pete's dashboard module instead of the technique described above; it's quicker to setup, and easier to clone to other installs, and no need to have code in various places like the themes folder and in ready.php The hope/plan is to turn it into a full widget enabled dashboard module that i can install on various installations a) without having to do any hardcoding b) enable control over which widgets are shown on the dashboard (by user/role/permission) c) allow for easy configuration of colors, icons, columns, etc. To achieve this I setup some templates for different widget types, one is a shortcuts widget, another is a page lister widget; these each have pages and fields to configure them; i can set them to appear by user/role. in the future i can add different types of widgets as needed and then include them in the needed user's dashboard. This is using a combination of a free (MIT licensed) admin theme for bootstrap, but instead of using bootstrap as the css layout, it uses a tiny grid called rwdgrid which i s 2KB; it uses the box, and other widget classes from the admin theme.