Leaderboard

Today the second site out of a series of 4 went online. This project is a bit different than the usual websites I do. The client had 4 websites, 3 of them running on a very old school proprietary CMS and one on MODX Evolution. I developed a layout which gets adapted by all three of them with minor differences and functions. I am running these on one installation of PW with the multi site module "Soma edition", originally by Apeisa. No problems so far with that. I imported around 1500 documents for both of the sites by fitting the CSV importer module to my needs. I could also manage to import images/PDFs which were hard coded in the shitty CMS by extracting the src from the markup. The PW-API surprised me a lot while doing this, just try&success ;-) The sites share a lot of templates, I tried to build it as modular as possible. As always, the CropImage module is loved by the clients and it also serves different image sizes for the sliders, while the picture polyfill loads the correct one dependent on the visitors screen size. The only thing I am struggling at the moment is the performace of the backend. Sometimes no problems, sometimes significant loading times. I am not quite sure if this is a server performance issue or is something related to PW. I also customized the backend a bit for quick create/edit pages: Ryan, if you read this: Do you think it is possible to get ProCache up and running for multi site environments? I think it would be a good benchmark, because the last site which gets converted will be the biggest one. And I am a bit concerned about perfomance (will be 10000+ pages). So, here are the two (warning: german and pretty boring, something with public vehicles and something with pests & ugly banners): http://kommunaltechnik.net http://schaedlings.net

Interesting discussion, happy to chime in here. I am a bit ambivalent here. For one, I would welcome any PW-related approach as a new InputField or alike. But in my experience all of the approaches - client or server side - were trying to fill a gap which had no standardized solution yet. But since W3C filed the specification for srcset attributes and picture elements my way is to go with exact that (even not implemented) syntax. Chrome implemented those lately (in Canary, behind dev flag), others will follow. I used the picture polyfill a lot in version 1, where it was more of a likely implementation of the proposed picture syntax. In version 2 we can use it right away with the correct syntax and from my observation it works great. So I would suggest not to build a custom (hacky) solution and reinvent the wheel but use that polyfill for not supported browsers (all at the moment, but less in the future). What I usually do is use the CropImage plugin for handling those different sizes. That works great. For example a slide show I am building the markup for each image looks like this (picturefill v1, so no picture syntax here yet, but works the same): <span class ='image' data-picture data-alt='{$slide->title}'> <span data-src='{$slide->sliderimage->eq(0)->getThumb('fullpagesmartphone')}'></span> <span data-src='{$slide->sliderimage->eq(0)->getThumb('fullpagetablet')}' data-media='{$tablet}'></span> <span data-src='{$slide->sliderimage->eq(0)->getThumb('fullpage')}' data-media='{$desktop}'></span> <!--[if (lt IE 9) & (!IEMobile)]> <span data-src='{$slide->sliderimage->eq(0)->getThumb('fullpage')}'></span> <![endif]--> <noscript><img src='{$slide->sliderimage->eq(0)->getThumb('fullpagesmartphone')}' alt='{$slide->title}'></noscript> </span> So it supports JS-disabled browsers as well as older IEs. You have total control over the images which those browsers get served. BTW: My media queries get imported by a global JSON file, I use that in CSS as well as in JS, but that ist another topic. Just consider for example $desktop be something like "screen and (min-width:1024px)". Advantages: I have full control and only have to configure CropImage for serving the different image sizes. Even art direction is possible (for example 2:1 on desktop, 1:1 on mobile). In that example I have no 2x configuration but that is also possible with srcset in picturefill v2 or with a media query like "screen and (min-width:1024px) and (-webkit-min-device-pixel-ratio: 2)". What I think regarding PW and responsive images: Try to keep the markup out of the solution or just provide a standard markup which everyone can change. Like PW always does. I would also rather extend the great CropImage module than trying to build something new. For example put a configuration in CropImage for 2X images. Could be done easily I think like: smartphone,200,200,template,2x so both, the 200x200 and a 400x400 version is generated from the same crop. The advantage of CropImage definitely is the art direction possibility. I wouldn't like to lose that ;-)

Hi folks, I read some posts where people seem to struggle with setting up config values for their modules. Since I am currently working on some boilerplate code for modules I created a helper class that makes handling of config values a peace of cake. on Github: https://github.com/owzim/PWModuleConfigHelper from the README.md Define a default array in your module: protected static $defaultConfig = array( // example with just one option 'prettySetting' => array( // the label for the form 'label' => 'Pretty Setting', // the default value 'value' => 'I am pretty', // optional, defaults to 'InputfieldText' 'inputfieldType' => 'InputfieldText' ), // example with multiple options 'awesomeSetting' => array( // the label for the form 'label' => 'Awesome Setting', // the default value 'value' => 2, // optional, defaults to 'InputfieldRadios' 'inputfieldType' => 'InputfieldRadios', // each key is for the input label, each value will be saved if selected 'options' => array( 'Option 1' => 1, 'Option 2' => 2, 'Option 3' => 3 ), // set any additional attribute to the input field 'attributes' => array( 'optionColumns' => 1 ) ) ); Apply the defaults to your module: public function __construct() { PWModuleConfigHelper::apply($this, self::$defaultConfig); } Render out the form: public static function getPWModuleConfigInputfields(array $data) { return PWModuleConfigHelper::renderForm($data, self::$defaultConfig); } Result: Access any of the config settings from your module: $this->awesomeSetting; Stuff to be aware of If you're using this in your module and you don't want it to clash with other modules using this, you have the following options to include it: use spl_autoload_register to autoload it, so it only gets loaded once only include the class if it has not been loaded yet, via class_exists('PWModuleConfigHelper') Option 1 and 2 require the class not to change (updates etc.) so the following options are more stable: Namespace to class via renaming it, prefixing it with you module's name Namespace it with PHP namespaces I could make a module out of this but this might be overkill Cheers!

You have some problems with your html, you should clean all the useless classes and ids. the #sub id is even repeated, and ids should be unique in a page. Is this what you want to do? http://jsfiddle.net/dXxtD/1/ I kept the html as clean as it could be, but you don't have to go to that extreme

Update: Blog version 1.2 Read below before updating. For new installs, proceed as normal ------------------------------------- Changelog TL:DR: Comments visibility settings + Posts' Bulk Actions + Update Script Comments Comments visibility can be controlled 'globally' as well as on a 'per post' basis Default is that comments and comment form are visible. You do not need to specify this setting; it just applies A post's comments SPECIFIED visibility overrides the global setting except for one case (see below). Post Comments Settings are set via a page select on a Post's page (also in 'Settings' tab in Blog Dashboard - see below) No selection: Default [comments and comments form will be shown] Always Show Comments: This will enforce overriding of global setting (e.g. Disable Comments) Disable New Comments: Will show old comments but not the comments form; visitors will not be able to submit new comments & message 'Comments closed for this post' will be shown. Disable Comments: Will neither show old comments nor the comments form; visitors will not be able to submit new comments & will see message 'Comments not allowed for this post'. Old comments WILL NOT be deleted . Global Comments Settings are set via a page select on the Comments page (in Dashboard as well). Settings here DO NOT override a Post's Comments settings WHERE A SELECTION has been made (i.e. if NOT empty). No selection: Default [comments and comments form will be shown] Disable New Comments: Similar to above Post setting except will affect all Posts' comments where no comments visibility selection has been made. Disable Comments: Similar to above Post setting except will affect all Posts' comments where no comments visibility selection has been made. Global Maximum comments allowed per post. If any number > 0 is specified in this new setting, IRRESPECTIVE of a Post's comments settings, if a post's comments is greater than the maximum set here, then 'Disable New Comments' will kick in. So, this takes precedence. Note: If you are logged in as superuser, even PENDING and SPAM comments are counted; so, the Global Maximum may be 'temporarily reached', if that makes sense Recap of comments visibility, in order of descending priority: 1. Global Maximum comments allowed for posts (/blog/comments/) 2. Any comment visibility SPECIFIED on a post (i.e. not empty) (/blog/posts/your-post/) 3. Any Global comment visibility SPECIFIED on comments page (/blog/comments/) 4. Default. 'Settings' Tab You can also set both the Global comments visibility and the Global Maximum comments allowed per post on this tab. The current setting will always be selected in the input field. Note: A blank Global comments visibility means no setting specified . So, if you want to change to 'no global setting specified', just select a blank and save [equivalent to deselecting a page select] (hope this makes sense). Note: Where no Global Maximum comments is set (i.e. blank), saving in the 'Settings' Tab's General Settings will subsequently show a '0' [zero]. This is equivalent to a blank, so not to worry Bulk Actions Introducing Bulk Actions for the Posts Tab! Make bulk changes to posts: Unpublish/Publish Comments visibility (as specified above for Posts' Comments visibility). In this case, also a 'Default Comments View' selection available. This is the equivalent of the 'no selection' specified in page selection field above. Trash Delete (note: no warning given before delete; careful with this one!) New column in Posts' Table also shows currently specified Comments visibility for each post. 'Default' means no selection made. Other - Some code clean-up. - See blog-side-bar.inc issue below. UPDATING I have written an update script (attached) that will add the new features in Blog 1.2 (2 fields, 1 template, 3 pages, 2 page updates, etc.). I have thoroughly tested the script. However, try this first on a test/non-essential install! If everything works, you can use it on your live environment Note: This assumes you haven't changed the native Blog paths and page names. Otherwise, it won't work properly. It won't corrupt any data but may just not install some stuff Note: You will still need to update the module as normal in your PW admin! Above is just to save you manually creating the extra fields, etc. To update: # Copy and paste the contents of blog-upgrade-version1-2.txt at the very top of one of your template files. Save the template file. # The script will only run if you are logged in as a superuser so other users won't know what's happening. # View a page using the template file you've just amended. The new fields, template and pages will be created. # Reverse the changes to your template file and save. # Update Blog via PW Admin as usual (to version 1.2) # Copy blog.css to /site/templates/css/. blog-upgrade-version1-2.txt If you are using the blog-side-bar.inc you might want to make/note the following changes. This only affects existing Blog installs! (not new ones) There was a missing <br> tag + $item->date instead of $item->blog_date. This will ensure Recent Comments widget also show the Post's date. If you are using the code from this file, you can make the following changes: OLD: $date = $blogOut->formatDate($item->date); $out .= "<li><span class='date'>$date</span> <a href='{$item->url}'>{$item->title}</a></li>"; NEW: $date = $blogOut->formatDate($item->blog_date); $out .= "<li><span class='date'>" . $date. "</span><br> <a href='{$item->url}'>{$item->title}</a></li>"; In addition, the code has now been changed not to show 'recent posts widget' on the blog home page. @Adrian idea, thanks! Screens Happy blogging!

Hello, I created this website just for fun. It's a collection (very small right now) of free high resolution photos, free to download and free to use also for commercial purpose. I hope this website will grow with a contribution of other photographers. http://lymeta.com

Hi Bacelo, Welcome to the community and don't be worried about your current lack of skills. We all have to start somewhere. You're in a good place. That said, it seems what you are asking is more of a CSS/JS question than anything to do with PW. To start with I think you need to determine your structure in HTML. Eg: Link -Sublink --Subsublink --Subsublink Link Link Link -Sublink Then figure out how to output that in PW. This part is relatively easy. It will be a combination of loops, referencing a links children. Eg: $link_pages = $pages->get("/")->children(); // These are your top level pages foreach ($link_pages as $lp) { echo "<li>" . $lp->title; if (count($lp->children()) { // does this page have children? echo "<ul>"; foreach ($lp->children() as $lpc) { echo "<li>" . $lpc->title . "</li>"; } echo "</ul>"; } echo "</li>"; } This is only intended as pseudo-code. Let us know if you get the basic idea.

Hi digitex, Dependencies within repeaters are now working in the latest dev. I think support is limited to (field=value), but that accomplishes a lot. I would also recommend taking a look at the new PageTable fieldType. Apparently it now has support for multiple templates, so you might be able to accomplish what you need without the overhead of repeaters.

I'm finally continuing this module - thanks to Ole who's sponsoring it. Please post all open bugs here or directly at GitHub so I get an overview on what to do (you don't need to repost them if they are already posted here of course). Thanks, nico

The Module Blog for ProcessWire replicates and extends the popular Blog Profile. Blog is now in version 2. Please read the README in the Github link below in its entirety before using this module As of 20 December 2017 ProcessWire versions earlier than 3.x are not supported Blog Documentation is here (Work in Progress!) See this post for new features in version 2 or the readme in GitHub. To upgrade from version 1, see these instructions. ################################################## Most of the text below refers to Blog version 1 (left here for posterity). Blog version 1 consists of two modules: ProcessBlog: Manage Blog in the backend/Admin. MarkupBlog: Display Blog in the frontend. Being a module, Blog can be installed in both fresh and existing sites. Note, however, that presently, ProcessBlog is not compatible with existing installs of the Blog Profile. This is because of various structural and naming differences in respect of Fields, Templates, Template Files and Pages. If there is demand for such compatibility, I will code a separate version for managing Blog Profile installs. In order to use the 'Recent Tweets Widget', you will need to separately install and setup the module 'MarkupTwitterFeed'. Please read the README in the Github link below in its entirety before using this module (especially the bit about the Pages, etc. created by the module). I'll appreciate Beta testers, thanks! Stable release works fine. Download Modules Directory: http://modules.processwire.com/modules/process-blog/ Github: https://github.com/kongondo/Blog You can also install from right within your ProcessWire install. Screenshots (Blog version 1) Video Demos ProcessBlog MarkupBlog Credits Ryan Cramer The Alpha Testers and 'Critics' License GPL2

Hello, My name is Jordan Lev, and I've primarily been using Concrete5 for the past 5 years to build websites for clients. I just came across ProcessWire the other day (not sure how I missed it for so long), and it is very impressive and really jibes with the way I think about building sites. I actually have created several Concrete5 plugins that offer functionality similar in spirit to the way one constructs fields and templates in PW, so it was pretty incredible to discover an entire CMS that embodies those principles! I have been playing around with ProcessWire a little bit, and reading through some forum threads. I'm hoping a project comes my way soon that PW would be a good fit for, so I can actually use it for a real-world website. For those of you who have never built a site with Concrete5 before, I encourage you to check it out (if for no other reason than to get some ideas on a slightly different model of how a site can be put together). I think what C5 is most well-known for is its front-end editing, but I would say that there is a deeper reason C5 is so well-loved by people like me: it really allows you to "design the editing experience". I think PW is somewhat similar in this regard, although it seems that PW is more about "designing the content structure" (which often overlaps, but not entirely). I've read some posts by Ryan that indicate he is concerned with separating the definition of the data from the display of it (for example, https://processwire.com/talk/topic/4189-flexibility-in-page-design/#entry41205 ), and that is a fantastic way to think about things (and very refreshing if you've every worked with less modern systems like Wordpress)! But I also think that philosophy is more well-suited to larger sites that have a lot of structured content. The places where I think PW could be made even better than it already is are for the smaller-scale marketing/informational sites, where tying the content and the display more closely together actually makes sense (especially for the non-technical users who have to manage the content as time goes on). For example, I think the much-discussed "file manager"/"media manager" feature is pretty critical to an easy-to-use workflow, and I feel like there are ways it could be done that honor the underlying spirit and simplicity of PW. Also, I think front-end editing is a HUGE win in terms of ease-of-use, and the "Fredi" module seems to offer that functionality (and there are a few minor tweaks I'd love to make that would allow the site editing experience to be even more "designable"). I have seen comments in the forums that are both "pro" and "con" on the things like file manager and front-end editing, and I think the difference in opinion stems from the difference in the kinds of sites people are building (larger, more structured sites that are served better by PW's existing dashboard versus smaller, less-structured sites I think are better-served by a tighter integration with the pages themselves). What I would love to know is how interested the ProcessWire community is in even attempting to make PW a better fit for these smaller-scale websites. Are people interested in discussing these ideas, and possibly even working towards making them happen? Or is the community primarily concerned with the larger / more structured sites and not interested in rehashing this line of discussion? Or perhaps I'm making some assumptions and generalizations here that aren't true? I just want to share with you all that some of the things Concrete5 has are incredible (pretty much every client has been blown away at how easy and intuitive things are with Concrete5 when I first show them the sites I've built), and I am interested in understanding more about how to make this happen with ProcessWire, and also sharing my experiences and insights with you all in the hopes that ProcessWire can be more appealing to a wider set of users without sacrificing its underlying simplicity and design philosophy. So I'll leave it at that, and am looking forward to hearing what people have to say! Thanks, Jordan

I think you probably know this already, but you can create a linux VM using one of these: vmware fusion parallels bootcamp I have only used fusion and only for a windows VM, but it should be straight forward to install debian or similar through one of these too.

ASAP i will provide german language files... Great Work!

Care to share your final code - I bet it will help someone else here at some point in the future

It looks like you're importing your db after a new installation of processwire, which has just set some primary keys (ids) and so it gaves you an error when you're trying to overwrite them (at least I'm guessing so). Try to import your db before installing pw, skip it and then try to go to yoururl/processwire (or any admin url you've set). Just my two cents.

https://github.com/adrianbj/ProcessMigrator and since you are coming from Wordpress, you might enjoy this plugin module for taking WP XML exports and importing them into PW: https://github.com/NicoKnoll/MigratorWordpress They are still possibly not quite release worthy yet, but with a little more testing, hint hint we might be ready to add them to the modules directory.

Textarea Markup inputfield Loosely based on core module InputfieldMarkup, InputfieldTextareaMarkup works with textareas (FieldtypeTextarea) and outputs plain text, markup and optionally values from other fields in Page Edit (backend). That output can be configured via field settings (Input tab) and then modified on a per-page basis, though only by superusers. For an example this: Hello World, I'm a {{template}}, my ID is {{id}} and my name is {{name}}! Would result in a non-editable (except by superusers) "markup field" with content along these lines: Hello World, I'm a basic-page, my ID is 1001 and my name is About! Content pulled from other fields is sanitised using $sanitizer->text() with default options, so no markup should get through, max length for individual field value is 255 etc. The module is available from GitHub. For more details check out README and/or modules directory page.

It occurs to me that a module that records all alterations to DB schema would be useful for the migration of DBs from a staging/development environment to live or vice-versa. I was thinking that, at present, if I work on my site locally (LAMP stack on my laptop etc) and then need to push changes live that it is no problem from a code point of view (I use git for source control, comfortable with that process) but that DB schema changes may be a bit more of a pain. I can, of course, just recreate the fields and templates manually on the live site but it's not exactly convenient or intuitive!! I have not checked, but if there are hooks into the DB parts of the core that make changes to the schema for new fields, template structure etc then it shouldn't be too hard to record those changes into a log that will therefore be a series of SQL commands that can be run to update the DB schema on another installation. I'm slightly lacking the time to do this myself, but I suspect that there are talented module devs here who could do this in no time, assuming the hooks are in place. An ex-colleague wrote a plugin for another CMS which did the same thing and it was very helpful indeed.

Welcome! You are right, PW is more aimed at complex content structures but by no means limited to that. AFAIK most of Ryan's client sites are huge data behemoths (not meant in a negative way), so the core will never ship with built-in features you're talking about, and nor should they (keeps the core lean and fast), but that's not a disadvantage in any way. PW provides an amazingly flexible and powerful foundation, and that's where modules come in (in fact many of the core features are packed into modules themselves, core modules). Many of the PW users/devs here also use it for small sites, so I think there will always be an interest to serve those well too. There are couple of modules, that focus on small sites. Some that come to mind are those which provide dashboard like UIs, the Blog Profile, or the Blog Module and as you mentioned, Fredi. Also there is a very new InputfieldType, called InputfieldPageTable which essentially gives you huge amount of flexibility when constructing sites with content blocks, like for campaign sites or landing pages. Of course you are welcome to dig into Module development and enhance ProcessWire with those or contribute to existing modules. The API is incredible and you can hook into almost any functionality or process. Cheers!

It's supposed to be fast, up to 7 times faster than Markdown PHP 1.3, see http://parsedown.org/speed https://github.com/owzim/TextformatterParsedown

I'm pretty sure that I've mentioned this somewhere around here earlier, but I tend to refer to usage statistics when discussing supported browsers. Define a minimum usage percentage ("at least 4%" for an example) and if a browser is below that limit, it shouldn't be too hard to convince the client that it's simply not worth it spending a lot of your time and their money fixing things for browser barely anyone uses anymore.. or, if you prefer to be sure, discuss that with the client beforehand and make sure that it's mentioned in your contract. StatCounter is my current favourite when it comes to things like browser usage statistics; their data seems relatively trustworthy and they offer very good tools for filtering and displaying it (and even allow saving it as an image, exporting a CSV etc. for archiving or whatever other reasons). That's what the statistics from last 3 months look around here. Based on that alone I'd say that it's really not worth it to support IE8 (or 10, which people seem to have pretty much skipped). IE9 is a borderline case, so I'd only offer support for it if it's very important to the client (they're a large organisation using IE9 or have such organisations as clients etc.) .. oh, and did I mention that I just love statistics?

Check kongondo's new blog module: http://modules.processwire.com/modules/process-blog/ This can be installed at any time.

hello everyone. I was trying Ace Text Editor module on my localhost and its amazing (combined with Images Tags module). it make me want to start a blog again, so I made one (using some domain name generator ). here's the url: http://pixlbendr.com/ Any feedback, comments and critics are highly appreciated. thanks.

Happy you

Regarding the below, you can also $spex->setLayout(false) to disable the layout.

Yes; this is now (or soon will be) resolved in the core https://github.com/ryancramerdesign/ProcessWire/issues/432 Not sure if it has been committed yet...

@MadMyDay, tnx for you well thought insights. I think you hit the nail on top with your post. Love the CropImage approach. Love to see a template-able adaptiveRender() methode or something.

Love the look. Two small things: "ABOYT THE BLOG" spelling error. There is a one pixel space between the lion and the basil pics.

I consider that a small price to pay! Thanks again, kongondo.

@kongondo. Thank you for this very useful module. It will find a home in a couple of installs I have in the queue right now. I owe you one!

Hi onjegolders, many thanks for your warm welcome and your help! Really very nice from you as I had no idea how to start... That's what I was guessing to have it realized with JS & CSS. I changed your code a bit and it works great so far : $link_pages = $pages->get("/")->children(); // These are your top level pages foreach ($link_pages as $lp) { if ($lp->name != 'ueber' && $lp->name != 'info' && $lp->name != 'pdf') { echo "<li class='{$lp}'>" . $lp->title . "</li>"; } if (count($lp->children())) { // does this page have children? echo "<ul id='sub'>"; foreach ($lp->children() as $lpc) { echo "<li class='{$lpc}'>" . $lpc->title . "</li>"; } echo "</ul>"; } } The CSS looks like: ul #sub { display: none; } #sub li { display: inline; padding: 0 5px; } So, I can now toggle via CSS the state of the parent and the child. Now I need to control that via JS - I tried the following code: $(".1086").hover( function() { $(this).css("display","none"); }, function() { $('#sub').css("display","inline"); } ); How do I control the list class? I Have no clue how to enter the relevant PW-code in the JS ... .1086 is the list class of a parent link (for test) - it should be the class of the parent link ($lp). I works with the manual entered list class (.1086), but it is not changing the state back on mouse out ... Regards, Bacelo

Thanks joer80 for your relentless replies. i contacted my host and i discover it has been fixed,the default page is now working, which is the home page.The other linked pages are not working like the home page. i don't really know why, can someone help? the site url still remain. http://mcalleluyashow.mil.nf/ Thanks, when i am true, i will definitely add the url on this link (forum)

Mr-fan, I am now a fan because you are the man! It seemed too easy and too good to be true, but that totally worked!!! Thank you!! How come I have never seen this method mentioned in the books I am reading is beyond me Maybe reading the wrong books? lol. Is there a name for this?

You can do it in one with findRandom(2) and then you won't need to worry about duplicate images: $randogals =$pages->find("images.tags=fav"); $randogal = $randogals->getRandom(); $randomimgarray = $randogal->images->findTag('fav'); foreach($randomimgarray->findRandom(2) as $randomimage){ echo $randomimage->size($thumbWidth, $thumbHeight); }

I've figured out a way to have this work in both scenarios, though still a bit hackish.. https://gist.github.com/outflux3/0a013ea20b46e706a6f9 say you have pages being managed by PageTable, and they all live somewhere other than children of the page managing the pageTable items, and you want to be able to have a visible page reference field on the PageTable items; when editing the item from somewhere other than the PageTable, the module first checks to see if it is already in the PageTable array and if not, it adds it (using the page reference).. when you add it from the page managing the items, i have the users leave out the page reference and then when saving the page, it sets all of the items that don't have the page reference, to the page where they are now associated with.. hope i'm making sense...

@Martijn: Agreed. As with most things in life, everything is specific when it comes to determining which browsers to support. Over time, and looking into the future, most developers will be moving to Owzim's 'rule' (as you put it). People are moving into an era of auto-updates, which helps us developers - especially those just starting out. I remember when I started, and it was such a nightmare to make IE6 behave. Everything is clearer now, knowing that nobody cares for it. Personally, I don't believe in patches. If something doesn't work in IE8: tough. If a site needs a feature, and a browser doesn't support it, then we drop the browser. Unless, of course, the feature is really specific, and doesn't make a big difference to the end-user. So glad I will never see ie-fix.css in any of my code ever again.

@vxda: I think you cannot do on the template. You need to do it with a module. Please refer to the API of that and to the "Hello World" module. If you have any questions than, maybe what hook to use, please ask here, (for any further help). Also you need not to include an external mailer. You can use the new wiremail() function and one of the new wireMail-extension modules: teppos SwiftMailer or my WireMailSmtp.

It's a pitty but web-development is not always about the best route. Time is limiting factor in the most development processes. And supporting unsupported browser features can have a negative effect on the behaviour on the up-to-date browsers. You've to weight your markup/design decisions carefully. The rule, stated by Owzim is logical & easy to understand for both the customer & development organisation. This is a handhold for de 'average' website you build. And if the customer needs a bigger backward compatibility, the boundary is clear. So they know it's more work and they know the bill will be bigger. To make a rule for backwards compatibility is a pretty good thing. Where you put boundary it's up to you, but it should be clear for both customer and developer.

I have simply decided not to care about IE6-7 since two years ago. Living much happier life now

What i would do is have a custom management page with a table showing all the tracks and then i would output the page ID in it's own column so they could double click it and copy it into foxycart. but short of that, yes you would need to grab the page id from the URL... funny though - most labels i work with already have catalog #s for their albums; a good sku setup would be the page for the album - page for the track (like 2034-9812) then you could at least see which tracks are part of the same album...

Fantastic work, kongondo. Your module is much needed for those of us who don't want to spend a lot of time stripping out the markup on Ryan's (equally awesome) blog module. One question: I notice that blog posts have this url: www.domain/blog/posts/my-post-here Have you considered any approach which might remove "/posts/" from that URL? My existing blog doesn't have the extra segment and I'd love to keep it that way, if possible. I've also been thinking I could remove it via htaccess.

Continuing from my previous post in this thread about some selector enhancements available on the dev branch, we've got a couple more advanced options for use in selectors in case anyone is interested: OR-groups These let you specify multiple expressions and only one of them has to match in order for the selector to match. It's a way of saying "either this has to match OR that has to match". This is useful because selectors always assumed AND – meaning everything has to match. While you have always been able to use the pipe "|" to specify ORs for fields or values or both, the scope of it was just that field=value statement only. Now we have something new called OR-groups. These let you create multiple selector groups and only one of them has to match. You can specify OR-groups by surrounding selectors in parenthesis. An example demonstrates it best. Lets say that we wanted to find all "product" pages that were in stock, and either in a featured date range, or had a highlighted checkbox checked. Previously we would do like this with two separate find operations: $items = $pages->find("template=product, stock>0, featured_from<=today, featured_to>=today"); $items->add($pages->find("template=product, stock>0, highlighted=1")); Now we can do it in one find operation: $items = $pages->find("template=product, stock>0, (featured_from<=today, featured_to>=today), (highlighted=1)"); Above are two selectors surrounded in parenthesis. Only one of them has to match. You can specify as many of them as you want. This type of OR expression is something you couldn't previously do with selectors. Think of the parenthesis as a way of saying "this is optional". But of course, at least one of your parenthesized selectors has to match in order for the full selector to match. I'm guessing the above usage probably covers 99% of the situations where you might need it. But lets say that you want to have different combinations of OR expressions. You can create named groups that OR with each-other by specifying: foo=(selector1), bar=(selector2), foo=(selector3), bar=(selector4) In the above you'd replace "foo" and "bar" with names of your choice. And you'd replace the "selector" with any selector strings. Those foo/bar names aren't referring to fields, instead they are just named groups that you can name however you want. In that selector, at least one of the "foo" named selectors would have to match, and at least one of the "bar" named selectors would have to match. If you didn't use the foo/bar named groups here (but still used the parenthesis), then only one of the 4 selectors would be required to match. Sub-selectors Some of you are already familiar with these because it was committed to the dev branch a couple weeks ago (and I think may have been outlined elsewhere in the forums). Sub-selectors let you put a selector within a selector, enabling you to perform more complex matches that used to require you to use separate API calls. These can be used on the 'id' property of any field that maps to a page. The 'id' property is assumed when referring to a page reference or a parent, so it's not necessary to specify it unless you want to, i.e. "field" and "field.id" mean the same thing in this case. Sub-selectors are specified between [square brackets]. For example, lets say we are matching products and our product template has a "company" page field. Each company also has it's own page field where all the company locations are identified. Lets say we want to find all products that are made by a company that has more than 5 locations and at least one of those locations has "Finland" in the title. Previously we would have had to do it like this: $companies = $pages->find("template=company, locations>5, locations.title%=Finland"); $items = $pages->find("template=product, company=$companies"); That's easy enough. But now it's even simpler, as you can do it in one operation: $items = $pages->find("template=product, company=[locations>5, locations.title%=Finland]"); When you've got a "field=[value]" selector, any properties you refer to in "[value]" assume the "field", so "locations" above is referring to a property of the "company" field.

But the Goods don't even have a TV, let alone a computer and Ryan was probably still in diapers at the time, so no PW

Or you could use this undocumented feature: Edit your /site/config.php and set $config->advanced = true; In your admin, go to Setup > Templates > your-post-template Click to the "System" tab. See the last field: "Allow the created user to be changed on pages?" Check that box and Save. Restore your config.php back to normal: Edit your /site/config.php again and set $config->advanced = false. Now you should be able to change the "Created User" on the Settings tab of any pages using that template.

@MikeB: no worries, this is just about as good as any other place to ask questions Great timing here, too. Just today I wrote in another thread that integers (such as 32 for version 0.3.2 or 132 for version 1.3.2) feel wrong to me because they can only handle a subset of version numbers. Integers are the default you'll see used a lot, but you can (and, when it's useful, should) use strings like '1.3.12' instead. It should work everywhere just as well as integers (and if it doesn't, that's most likely a bug).

One other immediate solution is to use Ryan's Hanna Code. I adapted the module to Hanna code, and it seems to be working pretty well, although the tags are a bit different: {fieldname:2} and [[images f="fieldname" n=2]] It looks a bit more complicated at first, but it's not really. Here is a resumed explanation: defaults: [[images p="0" f="0" n="0"]] where p is the page number, f is the field name and n is the image position on that field. The above is equivalent to simply: [[images]] And it will get all the images from the first field of the "image" type on the same page of this Hanna Code field. Because: if $p="0"; // $p will hold the $page object if $f="0"; // $f will hold the first images field found on $p if $n="0"; // $n will echo all the images from $f From here you can have any combination: [[images n="4"]] // echoes the image on the forth position of the first image field of this page [[images p="1" f="myimages"]] // echoes all the images of the field "myimages" in the homepage That's it. Here is the string to import this Hanna Code: !HannaCode:images:eyJuYW1lIjoiaW1hZ2VzIiwidHlwZSI6IjIiLCJjb2RlIjoiXC8qaGNfYXR0clxucD1cIjBcIlxuZj1cIjBcIlxubj1cIjBcIlxuaGNfYXR0cipcL1xuJG15UGFnZSA9ICRwID8gJHBhZ2VzLT5nZXQoJHApIDogJHBhZ2U7XHJcbiRmaWVsZE5hbWUgPSAkbXlQYWdlLT5maWVsZHMtPmdldCgndHlwZT1GaWVsZHR5cGVJbWFnZScpO1xyXG4kbXlGaWVsZCA9ICRmID8gJG15UGFnZS0+JGYgOiAkbXlQYWdlLT4kZmllbGROYW1lO1xyXG5cclxuJGluZGV4ID0gJG4tMTtcclxuXHJcbmlmKCRteUZpZWxkIGluc3RhbmNlb2YgUGFnZWltYWdlcyl7XHJcbiAgICBpZigkbil7XHJcbiAgICAgICAgJGltYWdlID0gJG15RmllbGQtPmVxKCRpbmRleCk7XHJcbiAgICAgICAgJGltYWdlID0gXCI8aW1nIGNsYXNzPSdJbWFnZVRhZ3MnIHNyYz0nJGltYWdlLT51cmwnIGFsdD0nJGltYWdlLT5kZXNjcmlwdGlvbic+XCI7XHJcbiAgICB9IGVsc2Uge1xyXG4gICAgICAgICRpbWFnZSA9IFwiXCI7XHJcbiAgICAgICAgZm9yZWFjaCgkbXlGaWVsZCBhcyAkaW1nKXtcclxuICAgICAgICAgICAgJGltYWdlIC49IFwiPGltZyBjbGFzcz0nSW1hZ2VUYWdzJyBzcmM9JyRpbWctPnVybCcgYWx0PSckaW1nLT5kZXNjcmlwdGlvbic+XCI7XHJcbiAgICAgICAgfVxyXG4gICAgfVxyXG4gICAgXHJcbn0gZWxzZSBpZigkbXlGaWVsZCBpbnN0YW5jZW9mIFBhZ2VpbWFnZSl7XHJcbiAgICAkaW1hZ2UgPSBcIjxpbWcgY2xhc3M9J0ltYWdlVGFncycgc3JjPSckZmllbGQtPnVybCcgYWx0PSckZmllbGQtPmRlc2NyaXB0aW9uJz5cIjtcclxufSBlbHNlIHtcclxuICAgICRpbWFnZSA9IFwiXCI7XHJcbn1cclxuXHJcbmVjaG8gJGltYWdlOyJ9/!HannaCode

Ryan, haven't you previously mentioned that you made something like versioning before? I would really love to have something like this: You have local/live version; you make a snapshot of a live version, and push the changes to local version. You work on the local, disregarding the live version. When you're finished, you'll take new snapshot of the live and merge it into local version. Now you can push your new local dump live and you're in sync. I think this comes into play not only with external editors (who can't work with your local version, obviously), but also to other automated things out of your control: I for instance have visit tracking code on section of website, because I later recalculate lists with this data. Also, when you have new comments and such on the website, you'll like to merge this with your local (possibly outdated version). Only other way to do this (as far as I know) is to do all the dev on your local version, do live->local db dump, freeze live, do local changes and push local->live. And while it might sound simple when written, it really feels cumbersome...

I think that I can add the necessary hooks to support this. Overhead with high traffic functions is always a concern with hooks, but did recently figure out a way to do it in a way that avoids any overhead unless/until a hook is actually active. So it should be possible to make something like $db->query() hookable. I will take a closer look at this.

Hey Rob, that would be awesome - I strongly feel that there really is a hole, when it comes to database syncing. While I probably won't pick this up (I'm not one of those talented developers), is there any possibility of linking us (or the one that will pick this up) to that ex-colleagues code? (in case it's open source, or he is willing to share it with PW community, if you're in contact).

You do this on template: $session->error("error error"); or this on class: $this->session->error("error error"); End then on next page load you can have this: foreach($notices as $notice) { if($notice instanceof NoticeError) { echo "<p>$notice->text</p>"; } } And that error notice is gone, no need to clear it yourself.