Leaderboard

See it in action:

You can also remove the fields using the API.... Backup your site first, please! This was written in a function context so feel free to change it and use in a template file context. You could also wrap the code in a conditional if $user->isSuperuser... Changed and done... if ($user->isSuperuser()) { //first remove the fields from 'user' template before deleting them. $t = $templates->get('user'); $fg = $t->fieldgroup; $fg->remove($fields->get('your_field')); $fg->save(); //delete the fields $f = $fields->get('your_field'); $fields->delete($f); }

Hey Guys, The site isn't brand new, but runs for four months now. The client is a facility management & building-cleaning company from Hamburg, Germany. We had reworked the Corporate Design before we started the creation of the website. Quite modest colors characterize the website. Besides that, there is nothing really special about the site. ProcessWire 2.4 Responsive Layout a few "Cross-fields" (display data on different pages, but get it all from one central place to avoid redundant data like contact informations) Modules: Hanna Code Redirects (to keep the search engine ranking) Modules Manager ModestAdminTheme (my absolute favorite Admin theme) and most important: ProcessPreview by nico! Big thanks again for finalizing this nice module! This site will be constantly reworked and extended with smaller and bigger things. oellerking.de

So long as the field isn't a repeater, file/image, or PageTable, PW 2.5 (2.4 dev) can do it in one query, which should take about a second. PW 2.4 and prior cycled through each page to delete a field. So that could be a slow process, though it is a good process. PW 2.5 still has to cycle through every file/image or repeater/pagetable field since they all involve external assets that also need to be deleted. But if the field you need to delete isn't one of those, you may want to consider waiting for PW 2.5 since we may soft launch it as soon as next week. Or you could try out the dev branch locally to test things out and see if you want to use it live.

PageTableExtended Download here: http://modules.processwire.com/modules/fieldtype-page-table-extended/ Extends the Processwire PageTable field for rendering table row layouts. This is great for editors, because they actually see at a glance what the table rows consist of. What it does Turns the Processwire Fieldtype "Page Table" from this: into something like this (sorting capabilities of course still functional): See it in action: Requirements FieldtypePageTable installed (part of the core since Processwire 2.4.10.) Templates used for PageTable need a file associated (otherwise nothing gets rendered) This render method is meant for sites where the PageTable templates only render part of the layout, not complete websites. But you also can define what will be rendered (see below). Options Render Layout instead of table rows Check this for seeing the rows rendered. You can easily turn off the complete functionality by unchecking this. Path to Stylesheet Since the parts are unstyled by default, it is a good idea to define styles for them. All rendered templates are encapsulated in a div with the class "renderedLayout" so you can style them with: div.renderedLayout h2{ color: green; } The path is to be set relative to your templates' folder. Reset Admin CSS Since the parts are rendered inside the Admin, common styles of the Admin Interface apply also to your layout parts. This is not a bad thing, because especially text styles are well integrated in your admin's theme. But if you like to override the admin styles in your table rows completely (more or less), just check this box. Don't forget to define a custom CSS then! Advanced Since this module is meant for parts of your layout you already have defined for your frontend templates, it is a good idea to use a preprocessor like Stylus, Sass or Less for building the custom CSS file. Just outsource your layout part definitions in an extra file, compile that in a separete CSS file and use this as custom CSS for this module. Since your CSS is should be built in a modular way, this works pretty well ;-) Will write a tutorial with a use case once finished testing. Notes: Github: https://github.com/MadeMyDay/PageTableExtended If you want to get rid of the unnecessary step for entering a title before editing the page, just set the "autoformat" value as suggested in the PageTable settings. If you don't want to use a title field at all, see this post from Soma Will put it in the module repository once finished testing. Please test it and give feedback. I haven't used GitHub for a long time, please check if everything is in place and if this will work with the modules manager and the new core module installer once added to the repository. Have fun Module is in the repository now: http://modules.processwire.com/modules/fieldtype-page-table-extended/ Please use GitHub for instructions, I made some additions there.

He, if I get you right, you have version 2.4.10 installed and want upgrade to 2.4.17 (or the latest version available)? you should make a DB-backup rename your current wire folder to something like wire-2410 rename your current index.php to index.php.bak or something and then upload only the wire folder of the latest version and the index.php Regarding changes in the .htaccess file I have compared the 2.4.9 against the 2.4.17 and there were only 2 new lines added (row 150 + 151): # ----------------------------------------------------------------------------------------------- # Access Restrictions: Protect ProcessWire system files # ----------------------------------------------------------------------------------------------- # Allow screenshot files (for install.php only: this 1 line below may be removed after install) RewriteCond %{REQUEST_URI} !(^|/)site-[^/]+/install/[^/]+\.(jpg|jpeg|png|gif)$ # Block access to any htaccess files RewriteCond %{REQUEST_URI} (^|/)\.htaccess$ [NC,OR] You need to update that manually. Then you should start the site by log into the admin and also view your site from the frontend.

new german updates for actual PW dev 2.4.18 (04 September 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--modules--fieldtype--fieldtypecomments--fieldtypecomments-module.json wire--modules--inputfield--inputfieldpagetable--inputfieldpagetable-module.json wire--modules--languagesupport--languagetabs-module.json wire--modules--process--processtemplate--processtemplate-module.json pw-lang-de-dev-update.zip

for the upcoming PW version 2.5: here you find a list of files which I have translated (based on the actual dev pre 2.5). These are 122 files (updated). Not all have to be translated, but are "nice to have". If someone wants to start a new lang-pack, take the empty lang files from the zip. list of all files: wire--core--admintheme-php.json wire--core--field-php.json wire--core--fieldgroups-php.json wire--core--fields-php.json wire--core--fieldselectorinfo-php.json wire--core--fieldtype-php.json wire--core--fieldtypemulti-php.json wire--core--functions-php.json wire--core--inputfield-php.json wire--core--inputfieldwrapper-php.json wire--core--modules-php.json wire--core--pagefile-php.json wire--core--pageimage-php.json wire--core--pages-php.json wire--core--password-php.json wire--core--process-php.json wire--core--sanitizer-php.json wire--core--session-php.json wire--core--sessioncsrf-php.json wire--core--wirecache-php.json wire--core--wirehttp-php.json wire--core--wiretempdir-php.json wire--core--wireupload-php.json wire--modules--admintheme--adminthemedefault--adminthemedefault-module.json wire--modules--admintheme--adminthemereno--adminthemereno-module.json wire--modules--admintheme--adminthemereno--adminthemerenohelpers-php.json wire--modules--admintheme--adminthemereno--debug-inc.json wire--modules--admintheme--adminthemereno--default-php.json wire--modules--fieldtype--fieldtypecomments--commentfilterakismet-module.json wire--modules--fieldtype--fieldtypecomments--commentform-php.json wire--modules--fieldtype--fieldtypecomments--commentlist-php.json wire--modules--fieldtype--fieldtypecomments--fieldtypecomments-module.json wire--modules--fieldtype--fieldtypecomments--inputfieldcommentsadmin-module.json wire--modules--fieldtype--fieldtypedatetime-module.json wire--modules--fieldtype--fieldtypefile-module.json wire--modules--fieldtype--fieldtypefloat-module.json wire--modules--fieldtype--fieldtypemodule-module.json wire--modules--fieldtype--fieldtypepage-module.json wire--modules--fieldtype--fieldtypepagetable-module.json wire--modules--fieldtype--fieldtyperepeater--fieldtyperepeater-module.json wire--modules--fieldtype--fieldtyperepeater--inputfieldrepeater-module.json wire--modules--fieldtype--fieldtypeselector-module.json wire--modules--fieldtype--fieldtypetext-module.json wire--modules--fieldtype--fieldtypetextarea-module.json wire--modules--fieldtype--fieldtypeurl-module.json wire--modules--inputfield--inputfieldasmselect--inputfieldasmselect-module.json wire--modules--inputfield--inputfieldbutton-module.json wire--modules--inputfield--inputfieldcheckbox-module.json wire--modules--inputfield--inputfieldcheckboxes--inputfieldcheckboxes-module.json wire--modules--inputfield--inputfieldckeditor--inputfieldckeditor-module.json wire--modules--inputfield--inputfielddatetime--inputfielddatetime-module.json wire--modules--inputfield--inputfieldemail-module.json wire--modules--inputfield--inputfieldfieldset-module.json wire--modules--inputfield--inputfieldfile--inputfieldfile-module.json wire--modules--inputfield--inputfieldfloat-module.json wire--modules--inputfield--inputfieldform-module.json wire--modules--inputfield--inputfieldhidden-module.json wire--modules--inputfield--inputfieldimage--inputfieldimage-module.json wire--modules--inputfield--inputfieldinteger-module.json wire--modules--inputfield--inputfieldmarkup-module.json wire--modules--inputfield--inputfieldname-module.json wire--modules--inputfield--inputfieldpage--inputfieldpage-module.json wire--modules--inputfield--inputfieldpageautocomplete--inputfieldpageautocomplete-module.json wire--modules--inputfield--inputfieldpagelistselect--inputfieldpagelistselect-module.json wire--modules--inputfield--inputfieldpagelistselect--inputfieldpagelistselectmultiple-module.json wire--modules--inputfield--inputfieldpagename--inputfieldpagename-module.json wire--modules--inputfield--inputfieldpagetable--inputfieldpagetable-module.json wire--modules--inputfield--inputfieldpagetable--inputfieldpagetableajax-php.json wire--modules--inputfield--inputfieldpagetitle--inputfieldpagetitle-module.json wire--modules--inputfield--inputfieldpassword-module.json wire--modules--inputfield--inputfieldradios--inputfieldradios-module.json wire--modules--inputfield--inputfieldselect-module.json wire--modules--inputfield--inputfieldselectmultiple-module.json wire--modules--inputfield--inputfieldselector--inputfieldselector-module.json wire--modules--inputfield--inputfieldsubmit--inputfieldsubmit-module.json wire--modules--inputfield--inputfieldtext-module.json wire--modules--inputfield--inputfieldtextarea-module.json wire--modules--inputfield--inputfieldurl-module.json wire--modules--jquery--jquerywiretabs--jquerywiretabs-module.json wire--modules--languagesupport--languageparser-php.json wire--modules--languagesupport--languagesupport-module.json wire--modules--languagesupport--languagesupportfields-module.json wire--modules--languagesupport--languagesupportpagenames-module.json wire--modules--languagesupport--languagetabs-module.json wire--modules--languagesupport--processlanguage-module.json wire--modules--markup--markuppagefields-module.json wire--modules--markup--markuppagernav--markuppagernav-module.json wire--modules--pagepaths-module.json wire--modules--pagerender-module.json wire--modules--process--processfield--processfield-module.json wire--modules--process--processfield--processfieldexportimport-php.json wire--modules--process--processforgotpassword-module.json wire--modules--process--processhome-module.json wire--modules--process--processlist-module.json wire--modules--process--processlogin--processlogin-module.json wire--modules--process--processmodule--processmodule-module.json wire--modules--process--processmodule--processmoduleinstall-php.json wire--modules--process--processpageadd--processpageadd-module.json wire--modules--process--processpageclone-module.json wire--modules--process--processpageedit--processpageedit-module.json wire--modules--process--processpageeditimageselect--processpageeditimageselect-module.json wire--modules--process--processpageeditlink--processpageeditlink-module.json wire--modules--process--processpagelist--processpagelist-module.json wire--modules--process--processpagelister--processpagelister-module.json wire--modules--process--processpagesearch--processpagesearch-module.json wire--modules--process--processpagesort-module.json wire--modules--process--processpagetrash-module.json wire--modules--process--processpagetype--processpagetype-module.json wire--modules--process--processpageview-module.json wire--modules--process--processpermission--processpermission-module.json wire--modules--process--processprofile--processprofile-module.json wire--modules--process--processrole--processrole-module.json wire--modules--process--processtemplate--processtemplate-module.json wire--modules--process--processtemplate--processtemplateexportimport-php.json wire--modules--process--processuser--processuser-module.json wire--modules--session--sessionhandlerdb--processsessiondb-module.json wire--modules--session--sessionhandlerdb--sessionhandlerdb-module.json wire--modules--session--sessionloginthrottle--sessionloginthrottle-module.json wire--modules--system--systemupdater--systemupdater-module.json wire--modules--textformatter--textformatterentities-module.json wire--templates-admin--debug-inc.json wire--templates-admin--default-php.json empty lang pack: pw-lang-empty-2.5.zip EDIT: thanks to Nico/Ryan. Updated the lang pack. Now includes 122 files.

I think this will fix it: $newsposts = wire("pages")->find("template=254_news_article,limit=5,sort=-published_date,start=0"); Note the addition of start=0 - this is to override the insertion of start from the pagination code.

Adrian, I have about 8,000 pageTable pages under a single parent (invasive plant species database). I just consider it a closet that I'm never going to look in. So far I haven't had any issues.

Hey Martijn, I managed this by using the automatic naming option and by setting the title field to hidden and not required in the template context settings (so it doesn't affect other templates) and that seems to be working ok. The one thing I am really missing (and maybe this is just me) is for the PageTable sub pages to be stored in some sort of hierarchy when using an alternate parent page. I can see a complete mess of hundreds of pages ending up in there, with various -n name appendices. Maybe it would be unnecessary extra cruft, but what if sub parent pages (named to match the actual page that uses the PageTable field) were made to store the PageTable pages. e.g.: Home ----About (has a PT field called Sections) ----Portfolio (has PT field called Jobs) PageTableItems (hidden) ----About -------Sections -----------Section 1 -----------Section 2 -----------Section 3 ----Portfolio -------Jobs -----------Job 1 -----------Job 2 instead of the current situation of: PageTableItems (hidden) Section 1 Section 2 Section 3 Job 1 Job 2 I know the latter looks simpler, but I can see it becoming a mess and confusing when page names were automatically changed to avoid conflicts. Anyone agree, or am I on my own

Good points from Horst. On my sites I just replace the /wire/ directory with the new one. Actually I rename the old one to ".wire" (or something like that, just in case I need it back… never have though) then put in the new one. PW automatically takes care of any database changes, so you don't need to worry about that. Also, if it needs an .htaccess or index.php update, PW will tell you the next time you login to the admin superuser account. So I wouldn't worry about replacing anything but /wire/ unless PW starts harassing you about it. The htaccess change Horst found above only matters for the installer, which isn't applicable on a site upgrade.

No need for a form. <div class='myViews'> <a class='button switchLayout' href='#' data-view='list'>List view</a> <a class='button switchLayout' href='#' data-view='grid'>Grid view</a> </div> jQuery: $('myViews').on('click','.switchLayout',function(e){ e.preventDefault(); var whichView = $(this).attr('data-view'); $.get( document.URL, { layout: whichView }).done(function( data ) { $( ".myView" ).html( $(data).filter('.myView').html()); }); }) in your template: ... $layout = $sanitizer->text($input->layout); // is there a get variable from ajax? if($layout){ $session->layout = $layout; } else // or something in session? { if($session->layout){ $layout = $session->layout; } else { // standard view $layout = "grid"; } } include("./inc/{$layout}.inc"); // returns $layoutView ... html goes here ... <div class="myView"> <?= $layoutview ?> </div> ..... So basically: Fetch the click, identify the button, load the current page via Ajax and with a GET variable which tells the template which view to render. The response is filtered, so only the myView part is the replacement for the current .myView. Written in the browser, totally untested.

Thanks BernhadB Appreciated the pointer, I know everyone has their own preference, suppose I;m just interested in different peoples preference and approach and I know there are many ways to skin a cat I'm really enjoying PW so far and realising that it's a great CMF to get people learning and thinking about projects, the ease of defining a query is truly awesome I mean: $mything = wire("pages")->find("template=my_template, my_field=special, my_field_featured_start<=today, my_field_featured_end>=today, limit=4, sort=random"); is just so simply to grasp and execute, I love the ability to tap into any field you define. Give me another week or so and I'll hopefully be posting my approaches and opening them up to either gratitude or constructive criticism, I'm looking forward to participating in this forum P.S. Even over the last couple of hours I've realised my frustration last night looking at the simple blog tutorial I was able to deviate from it all together and hash some functions together, PW makes PHP fun!!!

This module is improved and extended successor to Version Control For Text Fields. It handles everything it's predecessor did -- providing basic version control features for page content -- and quite a bit more. Download or clone from GitHub: https://github.com/teppokoivula/VersionControl. This module requires ProcessWire 2.4.1 or later, mostly because of the file features, which require certain Pagefile and Pageimage methods to be hookable. There's no sensible way around this limitation; for those stuck with < 2.4.1, Version Control For Text Fields will remain a viable option. What does it do? While editing pages, fields with old revisions available show up with a new icon in their header bars. By hovering that icon you get a list of available revisions and by clicking any one of those the value of that particular field is reverted to that revision. No changes are made to page until you choose a revision and save the page, which means that you can keep switching between revisions to get an idea what's really changed without inadvertently causing any content to change. The module also adds a History tab to page edit. This tab opens a view to the history of current page in the form of "revisions" -- each of which is a group of changes to page fields processed during one page save (similar to revisions in various source control applications). There are three actions you can perform on these revisions: adding comments, live previewing what the page might've looked in that revision and restoring the page to specific revision. One specific feature that has been a big thing for me personally is support for file (and image) fields, as the original version control module felt rather incomplete without it. I'm hoping to take this a lot further performance, stability and feature wise, but as it stands right now, it's already included here and should be fully functional. Watch the video preview here I prepared a little screencast outlining most of this: http://youtu.be/AkEt3W7meic. Considering that it was my first screencast ever, I'd like to think that it wasn't that bad.. but I might give it another shot at some point, this time planning a bit before hitting "record" Upgrading from Version Control For Text Fields For those already using Version Control For Text Fields, I've added something extra. If you upgrade that module to it's latest version, you should see a new checkbox in it's settings screen saying "Don't drop tables during uninstall". If you check this, uninstall the module and then remove it's files (this is required in order to install Version Control), your old data should be automagically imported to Version Control. Import has only been tested with limited amounts of demo data. Proper tests are yet to come, so please be careful with this feature! Update, 21.6.2015: as of today, this module is no longer in beta. While all the regular warnings still apply (making changes, including installing any new modules, on a production site should always be considered risky) Version Control has gone through pretty extensive testing, and should be as stable as any other module out there.

Hi, this is exactly the way how my template "row-divs" works, but it also spreads the divs evenly across the row (2divs; col-md-6) or with specified col-size. Of course I could add this to homePage, (parent page) but this would come with 2 limitations I don't want: 1) you can't move/order the row/rows on the page, (this way it can be moved on admin backend, because they are pages ) 2) I have different row-templates, one example is the slider, also with children, which are required to be presented as single pages the render() function works very wel, thanks. Thanks for all the replies. I'm just moving from Wordpress to ProcessWire and it is a dream!

I think we need an option "don't ever display children here" as a template setting. At least for editors. Even I am a bit confused when I accidentally open a folder in the tree where all this data crap is in

Maybe you're right - maybe I shouldn't worry about it - maybe it really doesn't matter how messy it gets in there

I believe Wanze's solution to the filesystem limit problem has been added to the dev core: https://github.com/ryancramerdesign/ProcessWire/issues/432#issuecomment-40951719

(invasive Page species database)

Thanks, Adrian. I've just fixed the notices you mentioned earlier and removed the stray </em>. View Page seems like a worthwhile addition, but at the same time it makes the UI feel a bit stuffy. I'll have to give this a bit of thought

Quick response here, but I think what you want is $subPage->render(); You may also want to check out PageTable as an alternate option: https://processwire.com/talk/topic/7459-module-pagetableextended/

Antti - thanks for suggesting the cache field option here, but it still feels a little clunky to me. Seems to me that if I add a PageTable field that has a body subfield, and my site search selector includes the body field as a field to search, then PW should return pages that contain a PageTable field with a matching body subfield automatically. I think the current situation will catch people out and their search system won't work as expected. Maybe it's just me?

Can you work from Nico's Delete button module where he adds a delete action after edit, view, new: https://github.com/NicoKnoll/ProcessPageDelete/blob/master/ProcessPageDelete.module

For posterity, and in case anyone missed it: https://processwire.com/talk/topic/7459-module-pagetableextended/?p=72035

So behind the times @MadeMyDay - just submitted a pull request to fix some freaky things I was experiencing either due to a template delegation situation or some freaky admin code I've done but I think it could affect certain people in certain scenarios so best to be safe. And because I'm nice I made sure it was all still compatible with your instructions afterwards

I hadn't actually realised you could specify more than one template for a PageTable field! Did that get snuck in after one of the early versions or am I just blind in general? It actually makes an "article" system a lot easier to build where an editing user might want to dump in some text, then an image, then some more text exactly as you have, but with your module it's one step better as it's pretty much WYSIWIG. Inline edits would be nice as folks have said, but this is still really, really useful!

Yes, i think so. Especially if adrian is right and PW silently goes replacing symbols with dashes (won't be able to test myself the coming days).

One working and from all browservendors agreed standard would be sufficient.

Thanks for that post, my searches didn't unearth that. I know that session auto start is on, so I will have to see if I can turn this off just for this vhost via php.ini (I need it for some of my other local installs like WooCommerce). I'll give it a shot and see how I go, thanks for your persistence with helping me diagnose the issue. EDIT: resolved the login issue by setting session.auto_start to 0 for that vhost. Aside from my problems, is the issue with the admin usernames not throwing errors/validating something worth raising on github?

I'm using the DEV now for 4 or 5 months and didn't experienced any major bugs that prevent me from using it. You could start using DEV now I think.

Minor, but important update today. This morning's commits to PW 2.4.17 made the password field required for new users, which broke this module when using the automatically generated password option. I just submitted a fix for this. Please let me know if you have any troubles.

This is real clever stuff MadeMyDay ! Great Job...

Awesome stuff! This is one of the features i was always missing in pw. Great Job MadeMyDay.

Done

Your hook and method has a lot wrong. If this all would work, then you would hook into Inputfield::render() and not Inputfield::renderValue(); And a hook to do what you wanted would look more like this: function hookAppendClassName($event) { $className = " mygrid"; $classes_array = $event->object->getParent()->getClasses(); $classes_array = array_merge($classes_array, array('item' => $classes_array['item']." ".$className)); $event->object->getParent()->setClasses($classes_array); } But this is not possible. When a inputfield is rendered in the inputfieldwrapper, the classes and markup is already set and you can not overwrite it at that moment in time. I also was looking into this and by chance I found a line of code in latest dev, that seems to be added recently. InputfieldWrapper rendering method looks for a $inputfield->wrapClass, I didn't know was there. So you can now simply do this: $field = $modules->InputfieldText; $field->label = "Name"; $field->wrapClass = "mysuperlol-col1--wonder__toootooo"; ...

Hi Tobaco, my setup is always the same. Doesn't matter if I use PageTable or not. Here it goes (simplified): /templates - basic-page.php - home.php - /tpl - main.php - mainnav.php - subnav.php - footer.php The tpl/main.php is the overall template like: <?php include('tpl/mainnav.php'); include('tpl/subnav.php'); include('tpl/slider.php'); ?> <!DOCTYPE html> <html class="no-js"> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> <title><?= $page->title ?></title> <!--- styles and scripts --> </head> <body class='<?= $bodyclass ?>'> <header> <div class='wrap'> <a href="/"><img src='/site/templates/img/logo.png' class='logo' alt="Logo"></a> <nav class='main'> <?= $mainnav ?> </nav> </div> </header> <?= $slider ?> <?= $subnav ?> <section class="content"> <div class="wrap group"> <h1 class='v2 hide'><span><?= $page->title ?></span></h1> <?= $content ?> </div> </section> <footer> <div class="group"> <?php include ('tpl/footer.php'); ?> </div> </footer> <script src="/site/templates/dist/all.min.js"></script> </body> </html> basic-page template looks like this (every template renders the content and then includes the main template): <?php /** * basic page template * */ $bodyclass='inner'; $content = $page->body; include('tpl/main.php'); With PageTable the structure looks like this: /templates - basic-page.php - home.php - part_text.php - part_columns.php - part_gallery.php - /tpl - main.php - mainnav.php - subnav.php - footer.php The part_* templates are templates only for PageTable. part_columns.php could look like this: <?php $headline1 = ""; $headline2 = ""; if(!$page->checkbox1) $headline1 = "<h2>{$page->title}</h2>"; if(!$page->checkbox2) $headline2 = "<h2>{$page->text1}</h2>"; // Output echo " <div class='pageTableSection {$page->template->name}'> <div class='inner'> <div class='col one-half'> {$headline1} {$page->body} </div> <div class='col one-half'> {$headline2} {$page->textarea1} </div> </div> </div> "; And the basic page template gets enhanced by ("layout" being the PageTableExtend field): <?php /** * basic page template * including PageTable layout parts */ $bodyclass='inner'; $content = "{$page->body}"; if(count($page->layout)>0){ foreach($page->layout as $l){ $content .= $l->render(); } } include('tpl/main.php'); That way, the layout parts are easily renderable in the Admin with PageTableExtended. While writing this, I want to point to another feature of the module. If rendered by PageTableExtended, the template gets an option 'pageTableExtended' which you can use in your part template: // Output echo " <div class='pageTableSection {$page->template->name}'> <div class='inner'> <div class='col one-half'> {$headline1} {$page->body} </div> <div class='col one-half'> {$headline2} {$page->textarea1} </div> </div> </div> "; if(!$options['pageTableExtended']){ // we are not in the Admin, so we include our social media buttons which we only need in our frontend include('social/socialmediabuttons.php); } Hope that helps.

Well the formatting got a little weird in the code box as they are really long links but just throw em in a text editor and you should be right as rain. I managed to find some sample code that allows you to use the pinterest image chooser as is an important thing for this project. Now just to get it out of the document into my extra js. function renderSocial(){ $soc = ''; $page = wire('page'); $thisUrl = $page->httpUrl; $path = wire('config')->urls->templates.'img/'; $lnkDesc = $page-meta_description; $friendlyUrl = urlencode($thisUrl); $friendlyDesc = ereg_replace("[-]+", "-", ereg_replace("[^a-z0-9-]", "",strtolower( str_replace(" ", "-", $lnkDesc) ) ) ); $soc .= '<div class="socialHolder">'; $soc .= ' <ul class="share-buttons">'; $soc .= ' <li><a class="socialBtn" href="https://www.facebook.com/sharer/sharer.php?u='.$friendlyUrl.'&t='.$linkTitle.'" target="_blank"><img src="'.$path.'Facebook.png"></a></li>'; $soc .= ' <li><a class="socialBtn" href="https://twitter.com/intent/tweet?source='.$friendlyUrl.'&text='.$thisUrl.'Your Title Header:'.$page->title.' '.$friendlyDesc.'" target="_blank" title="Tweet"><img src="'.$path.'Twitter.png"></a></li>'; $soc .= ' <li><a class="socialBtn" href="https://plus.google.com/share?url='.$friendlyUrl.'" target="_blank" title="Share on Google+"><img src="'.$path.'Google+.png"></a></li>'; $soc .= ' <li><a class="socialBtn" href="javascript:void((function()%7Bvar%20e=document.createElement('script');e.setAttribute('type','text/javascript');e.setAttribute('charset','UTF-8');e.setAttribute('src','http://assets.pinterest.com/js/pinmarklet.js?r='+Math.random()*99999999);document.body.appendChild(e)%7D)());"><img src="'.$path.'Pinterest.png"></a>'; $soc .= ' </ul>'; $soc .= '</div>'; echo $soc; }

Though this topic is old enough, let me pick it up again. I also encourage you to move the localization to Transifex. From the view of translators, it is amazing that the translated strings are stored in translation memory, so in the case of an update a translator needn't start his job from scratch, but can leverage the already existing translations. Additionally, it supports team work, so multiple translators can apply for the translation of a project, adding reviewer privilege for the best translators, the quality assurance may be provided. In the case of multiple languages, the challenge of "who is faster" may motivate your translators to complete a job as soon as possible - a kind of international competition.

Thanks adrian, not only for this new module but also for your abundant supporting posts and contributions in this forum.

Table Use this for tabular data, like rate tables or other things that you might typically represent in a spreadsheet. Use it for situations where you don't need the full-blown flexibility of repeaters, as it's technically more efficient with far less overhead than repeaters. Something like the Events Fieldtype could be very easily re-created via a Table field, but the potential uses are far broader. But for the most part, think tabular data when it comes to the Table field. Multipliers This is good for when you need a range of values (whether text, textarea, numbers, dates, etc.). If you are using repeaters with just one field in them, you might be a lot better off with a Multiplier. Like the Table field, Multipliers are very efficient and low overhead relative to something like Repeaters. Use Multipliers when you need to repeat a single input multiple times, optionally with a min and max number of inputs. Lets say you are building an employee directory, and each employee has between 1 and 3 email addresses. Rather than using 3 separate email fields, you would use 1 multiplier field and specify min=1 and max=3. Repeaters These are infinitely flexible in terms of what they represent, but each row of values is technically a page in the system. As a result, with the flexibility comes significant overhead. This is really only an issue when the quantity of repeater items gets high, or when you have lots (thousands) of pages using repeaters. I recommend repeaters for setting up things like homepage carousels. For example, if you go to the Villas of Distinction homepage, there are 3 separate repeaters in use on that page, each holding a photo, title, description, link. The client can have as many items in each of those sections as they want. Currently it looks like the first repeater as 6 items, the 2nd has 2, and the 3rd has 6. The possibilities of what can be represented with repeaters is endless, but look for potential alternatives when dealing with large quantities (whether large quantities of repeater items, or large quantities of pages using repeaters). PageTable This is one of the ProFields that is available for free (thanks to Avoine sponsorship) on the ProcessWire dev branch. Meaning, it'll be available for everyone to use as part of the core in ProcessWire 2.5. And you can use it now if you don't mind running the dev branch. PageTable has all the flexibility of repeaters, but with lower overhead from the admin/input perspective. Rather than trying to bundle all the inputs on one screen, PageTable shows you a table of items and you click on the item to edit it in a modal window. This enables it to be a lot more efficient from the admin UI perspective. It's also more flexible than repeaters are in terms of where you store your items. PageTable lets you choose where they should live, whether as children of the page being edited, or as children of some other parent page you designate. They might be a little more work to setup than repeaters, but I think that most situations where you need the flexibility of repeaters may be better served by PageTable. PageTable still can't compete with the speed and efficiency of Table or Multiplier, but consider using PageTable anywhere that you might have used Repeaters before. Repeaters and PageTable are fundamentally different from the admin UI/input perspective, so you'd want to compare them yourself to see what suits your individual input needs better. PageTable involves more clicking to create and edit items, making Repeaters potentially faster for entering data rapidly. But PageTable will scale much further in the admin UI than Repeaters will, so I would personally favor PageTable in more situations than Repeaters.