Leaderboard

I've been quite busy last few months (and still am), but I managed to squeeze new admin theme called Futura Remixed (successor to my Futura theme). So let's get started: complete rewrite of the theme complete new graphics, includin PageList tree icons etc. full multi-language support (except "You are logged in as", "Latest updates" and "Newest added" title (could be done by implementing those in language packs I suppose) complete new TinyMCE theme with Fugue icons (that was pain in the ass) integrated CodeMagic TinyMCE plugin that uses CodeMirror to highlight the code and HTML beautifier to beautify the code (unlike plain TinyMCE HTML editor) AdminBar theme How to install: Unpack FuturaRemixed.zip to your /site/ directory Replace /wire/modules/Inputfield/InputfieldTinyMCE directory with InputfieldTinyMCE directory contained in the attached InputfieldTinyMCE.zip file Extract AdminBar.zip to your /site/modules/AdminBar directory (if you use it) I've tested the theme thourougly but errors may still show up. So if you find them, please let me know, so I can fix them. When I get time, I'll update this theme with colors from original Futura theme so you could choose between them. Let's look at the screenshots: Enjoy the theme as much I've enjoyed making it. AdminBar.zip FuturaRemixed.zip InputfieldTinyMCE.zip

Hi, http://www.sylvantypeworks.com.au/ This would have to be the smallest site I've done in PW. It's for a local artisan print shop that's branching out into recreating complete (or incomplete) wooden type sets. The end products are suitable for use on a letterpress. My client (who prefers the hands-on approach to type) made a point of telling me how easy he found ProcessWire to use. Regards Marty

It sounds like it really is only the column width that varies, and not the actual data. As a result, I think you can accomplish this just by adding an integer field to your repeater and asking the user to enter a number between 1 and 12, indicating the number of grid columns they want the item to fill. It sounds like you are using an HTML/CSS framework that uses "grid_[n]" classes to carry the width, so I would just map that directly to a field. Once you've got it working, you might prefer to map it to a select with predefined values like 1/4th (3), 1/2th (6) and full (12). It'll be easier for the non-developer to understand that 1/4th means "quarter width" as opposed to "3 columns of 12". But I'd get it working the simplest possible way first (integer field), and then optimize it with pre-defined selections once you know it all works. I'm guessing those columns naturally wrap on their own when at the end of a row, so you dont' really have to worry about clearing floats. foreach($page->segments as $segment) { $width = (int) $segment->segment_width; if($width < 3 || $width > 12) $width = 12; echo "<div class='grid_$width'>"; // output your content echo "</div>"; }

Thanks Netcarver, I didn't realize you were involved with Textile. That's good to hear. I'm a fan of Textile, and lately have really preferred it to Markdown and thinking we should add the Textile modules to PW's core modules. The only reason it wasn't in before is because I couldn't get it to work with UTF-8 text a few years ago when I initially included Textile in PW 1.0. I think I must have been working off Dean Allen's original version back then or something. I have upgraded the Textile module to the version from your repo and will track that one from now on.

I committed some updates to PHP textile today. Added since post #28 above were... Support for HTML5 output. Support for symbols as backref link characters for note lists. Support for raw urlencoding of unicode characters in URLs. Simpler forms of "$" style links. More robust support for n-dash characters. If I can, I'd like to add better support for Japanese-wikipedia style links (info here) and close a problem with line breaks in table cells; and that should get PHP Textile to version 2.4.

A pre-made module for this on the admin wouldn't know what field(s) might be referencing the $page, so it would need to locate all the Page fieldtypes, and perform a check on all of them: "field1|field2|field3=$page". I prefer to view these kind of relations on the front-end of my site (where I can give them a known field context), so my template for the pages in the relation will usually have something like this: echo $pages->find("field1=$page")->render(); If the page isn't part of the front-end site, then I'll remove view access from its template. Or if it is part of the front-end, but I don't want to show the relations, then this: if($page->editable()) echo $pages->find("field1=$page")->render(); Though I almost always integrate these relation-revealing pages into the site structure, as it's rare that this information doesn't have some value to the site's users too. This is an example of one that locates all pages referencing it in a field called 'country': http://www.tripsite.com/countries/croatia/

Rob, how about this? # block everything except actual files/dirs that exist # for instance, JS/CSS files used by admin and modules, etc. RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule !^processwire - [F] # block access to root and /index.php file # if running site from subdir, replace '/' with '/subdir/' RewriteCond %{REQUEST_URI} ^(/?$|index.php) RewriteRule !^processwire - [F] Place right after your "RewriteEngine On" line.