Leaderboard

I have just published my new module Page Draft Creator to the modules section of the site: http://modules.processwire.com/modules/process-page-draft/ The basic principle is that you can, with a single click, create draft copies of pages that are hidden (from search, API searches/listing etc) and have a unique, almost-impossible-to-guess URL and can therefore be sent to clients so they can sign-off on changes before you make them to the live, published page. It does this by cloning the page and adding an MD5 hash to the URL. The draft page is technically live and publically available, but in reality only those who you share the gibberish URL with will ever see it. It's a small, simple bit of code but hopefully it goes some way towards the draft->preview->publish workflow that is often required by site builders, editors etc. Consider it beta although it is, I believe, incapable of doing any harm. It could do with testing on various versions of ProcessWire so if anyone has feedback it is welcome. In the future the intention is to be able to "publish" these draft pages by copying the content back over the live page, but at present there are issues with repeaters that mean that it is a work-in-progress. Enjoy!

Hello guys We reached some over 100 modules on http://modules.processwire.com It was like 5 when I joined 1.5 yeah ago? Keep it up but remember quality > quantity I'm a PW addict, when I've not created a module for so long I get nervous.

AdminSaveActions (Was: After Save Actions - guess why the rename?) Admin Save Actions adds the possibility to choose where the browser gets redirected after saving a page, template or field. Admin save actions are displayed just before the save button in a collapsed container. Chosen action can be saved in a cookie for current user by checking "Remember this setting". By leaving this option unchecked upon save, the chosen action will not become the default. Why? Some of you wanted something like this to exists in ProcessWire - and so did I. I've read discussions here, here, here and here carefully trying to cover at least most of the options discussed. I know this implementation wont satisfy all the needs, but I'm looking into adding some things afterwards to cover even more of them. I called the first version of this module PageEditRedirects but decided to to change the name in to a more descriptive one. So that module got deprecated as of now (and does not exists at GitHub anymore). This new version also does not require PW 2.3 but works just fine on PW 2.2 as well. Special thanks A module by Adam Kiss (ListAfterSave) implemented some of these actions a long time ago. Thanks to Adam for letting me use the ideas introduced by his module. There are actually some things there my module isn't going to cover even in future versions. Links AdminSaveActions can be found from the modules section. AdminSaveAction is downloadable from GitHub. (Edit: added link to the modules section. Edit 2: Implemented config option + version bump. Edit 3: Removed feature list - see GitHub.)

Josh's post encouraged me to tell what I have Laptop is a Dell Inspiron with 15'' display, and when at home I dual screen it with a 21'' Samsung monitor. The OS is the very new Fedora 18 Beta (I'm living on the edge ) with Gnome graphical user interface. When people know I'm a designer and I show up with something that is not a Mac, they say "YOU DON'T HAVE A MAC???"

After sleeping on it, I've decided to use Pages, as suggested. I'm going to create a template called Taxonomy - this template will allow children of it's own type. I will create one root Taxonomy page ("/taxonomy"), and each taxonomy-type will just be a Taxonomy page under it ("/taxonomy/article-type") - the individual classifications will be child-pages under those: "/taxonomy/article-type/sports", etc. After thinking about it, compared to the idea of having simple enumerations/sets as a Field-type, I like this idea better, as it can grow - it will have only a title-field, but who knows, maybe somebody will want a summary and/or body-field on those one day, so that category overview pages can be displayed. Or some other need I haven't foreseen. Another thing I like better about this, is the fact that Taxonomies can be trees, not just flat lists - again, I don't need that right now, but requirements can change, and this way I'm not locked in, or risk having to write more code to extend a Field-type to support that. Perhaps an article about building Taxonomies should go into the Wiki? I will try to take notes and draft something while I build this. This is definitely a case where it would be very easy to over-engineer the solution in ProcessWire - for example, I was thinking at first that I would need multiple templates for different Taxonomies - then I thought, I need two templates, one for the taxonomy-type, and one for the taxonomy-classifications. But the absolute simplest solution is to have just a single template, so that the whole taxonomy data-structure is homogeneous. It's another great example of how the ProcessWire data-model really excels - the more I use it, the more convinced I become that there really isn't much you can't do with this data-model, and plus, it scales very nicely, both in terms of performance and complexity

Just a wild thought, It's maybe convenient when the ProcessWire gives you the opportunity to select a profile before installing PW. After the install is finished, ProcessWire & the profile are ready to use.

It's not a bad idea (the first idea, not the second one ). The easier you make it to install a particular profile the better, but my idea (which I remember posting ages ago) was to have the PW download page a bit like the jQuery download page where you build a package. Think of it - the core and default profile are ticked for download. You can select a different profile and that's your basic options. On top of that though, there could be a list of useful modules - by this I mean the most often used/searched for (there must be some stats from the modules directory - I'm looking for them now on Google Analytics). The downloader would then fetch the relevant packages from GitHub and merge them together into one zip file on the fly. I seem to recall the biggest issue for this being how to fetch stuff from GitHub, but someone's already solved that with the ModulesManager EDIT: There is obviously some overhead to this, but this is a dedicated server after all, plus this idea makes us look quite slick, gives users what they want and puts it all together so all they need to do is install it. Version 2 is a single file they upload to their server and they do the same thing but it fetches all the files to their server and installs it based on the settings in the single file installer

I'm pushing this a little bit... Just searched on a "designer community" for processwire and found , that the original draft of the new PW homepage was posted a year before the soft launch. In my opionion, that show how solid and good this design is - that you find it modern and nice after one year.

Some modules are so valuable that I think they could go to the core tho shrink your 100 modules list. I hope eventually that your Modules Manager would merge in the Modules section in PW. Selector Test, would be a great one to be delivered with the core (uninstalled by default) Admin Hot Keys ( only realy works if you use it all the time ) Page Delete ( un-installed by default ) That would be 4 modules less

Two likes for this. Would be three if a "t" wouldn't be missing

If you need one-time toggles, individual checkboxes are a fine way to go. But for multiple related items like categories, the Page reference field is the way to go. You can create a structure of pages representing any amount of flat or nested categories. If you use nested categories, choose the "Page List Select Multiple" as your input type, and set the root level of your categories structure as the "Parent".

That is how I usually have my tags organized. And having things this way came super helpful in one project: Client wanted to automate most of the content rotating on the frontpage and main sections. Rotation needed be based on time - some articles were about winter, some about christmas, some about summer, some about some holidays in between etc. They had already tagged all their articles (200+) with tags (about 20) and even the thought about choosing "active months" or "startdate - enddate" for each article felt taunting. What we did was to extend those tags to have "active months" selections. This needed only little additional logic, but was a breeze for client to setup (editing 20 tags instead of 200 pages). And if someone decides to move Christmas from December to July... well - we are ready for it! And no - I didn't have a clue about that kind of "autorotation" idea when I build the site.

I was thinking of a way of creating custom admin pages without having to create a process module or having to use the $wire object. I came up with a process that is actually very simple (although I think it would be better to create a module for having this functionality). Here is how: (This will work with the default admin theme, but should also work with other themes) Go to your /site/templates-admin/default.php (if you don't have it, copy the /wire/templates-admin/ directory to /site/) and change this line <?php echo $content?> to this <?php if($page->template===$templates->admin){echo $content;}else{include($config->paths->templates.$page->template->name.".inc");}?> Then, go to the /site/templates/ folder and create a file named "custom.php" with this content <?php include($config->paths->adminTemplates."default.php"); Our setup is ready Now, to create a custom page in the admin: First, create the new page as child of /Admin/ and point to custom.php as the template file. To do this, when creating the template for the page, go to "ADVANCED" and write "custom" as the "Alternate Template Filename". Then, instead of creating a TEMPLATE.php file, as you normaly would, create a TEMPLATE.inc file. You can use all the API variables as you would in a normal template. Disclaimer: This is a proof of concept, and has still lot's of place for improvement. edit: changed from this if($page->process) to this if($page->template === $templates->admin)

You can hook before Fieldgroups::save or Templates::save. public function init() { $fieldgroups->addHookBefore('Fieldgroups::save', $this, 'addProcessField'); } public function addProcessField(HookEvent $event) { $fieldgroup = $event->arguments[0]; if(!$fieldgroup->hasField('process')) $fieldgroup->add('process'); }

Okay, haven't read the entire thread so I may have this completely upside down, but isn't it easier to have multiple Site folders with the first one as a default? So, in each subsequent site it will use the templates in its own folder if they exists, if not it uses the templates from the default folder. Same for modules and admin template. There would have to be some exceptions, probably, so you didn't end up with the head from your own site1 folder and the footer from the default site folder, for instance. But it might make deleting sites easier if it is just removing their entire site folder. Also means that they could be transferred to another installation, I would think ... somehow.

Phew, sleeping is overrated. Coding is much more fun. @Antti: I just pushed a new version to GitHub and the bug you reported should be fixed now. @Pete: As an added bonus I added the option to choose between radios in a container and a dropdown near the save button. This latter behaviour is somewhat experimental as I could use half a year trying to style the dropdown (+checkbox) and still get it awfully wrong. So there it is, plain and simple. Feel free to suggest (anyone?) suitable markup for the dropdown version. I just might give it a try myself someday, but I doubt it will become anything suitable for anyone not wanting to damage their eyes. @Soma: And I even managed to do it at such a time I was going away from the computer for some time. Plain stupid of me. But hey, didn't I say some time ago I'd try to publish stuff sooner than later: "if you’re not embarrassed when you ship your first version you waited too long". Check. And it wasn't even first version I messed up with .

It's really easy to do the path stuff - you can split out that information by running a PHP explode() function on the path name and then picking out the year, month and day and then have whatever structure you like in PW. The main thing I keep asking though is more important and harder work - do you have an example of one of the articles so I can see the contents and suggest how you would parse all that? Basically if I could see that, I can pretty much give you the code to do it as I've got a converter script on my PC here Another question I asked earlier was how images are stored for each article (when they have images)? Are images just in the folder with the file that contains the text? The paths can stay the same as the text versions if you like - /issues/2013/Jan/08/ for example, but then have a more meaningful title on the end, like "news-story-title" if you like. You could also do away with the date in the path altogether and just have /issues/news-story-title and people can use an archive page to go through the days/months/years. But I'll rewind a bit as the harder part will be importing the articles. Iterating through your current directories, assuming the path you have for the files is consistent back through the months and years is easy, but I'm itching to see the content of one of the text files to see how hard that side of things might be

We have many users that have come over from EE, just like we have many users that have come over from WordPress, Drupal, MODx and Joomla, among other platforms. These users are enthusiastic about ProcessWire and like to share their enthusiasm with friends. Please don't confuse the title of this thread as being something the project is trying to pursue, because it's not. I'm assuming the OP is a current/former EE user that is enthusiastic about PW and wants to share that. We are not actively trying to benefit from changes at EllisLab or trying to pursue EE users. If I were an EE user, I would want what's best for the company behind it and would stick with it. When those changes were announced, I went to the #eecms hashtag to see what all the fuss was about. There were other projects being opportunistic about it (the Perch one was actually kind of cute). We were silent on it. Just because there were current/former EE users talking about ProcessWire does not mean that ProcessWire is trying to pursue EE. EE has nothing to do with any "cause" here. I changed the theme shown on the homepage because users here thought it would be better if it showed exactly what you see when you install, until we get the rotation up. We have several sets that are going to go in there (rotating) and the one that was there previously is one of them. Now that the default admin theme is in there, there have still been folks that say "that looks like EE". I designed that admin theme and can say for certain it takes no inspiration from EE. I really don't know if the other admin theme that was in there takes inspiration from EE or not. But looking through screenshots, it seems like there are similarities and differences. I'm not convinced anyone was trying to copy the look of EE. Design trends and interfaces for similar tasks are bound to bear some resemblances to each other. People need to step out their front door. There is one thing I can be certain of though, and that's that I'm glad people might say "that looks like EE" and not "that looks like Joomla". I was glad to see this. It came along at the right time. If I was an EE user, this would make me a lot less concerned about the changes in support plans. Glad to hear PW and others are being looked at. We are thrilled to welcome any EE users. Still, if folks are happy with everything about EE from the software side (even if a little angry about EllisLab changes in the short term), they shouldn't abandon it. CMSs aren't religions, and it's okay to use more than one. It is curious to me that Blocks gets mentioned despite not even being out. Blocks appears to be built as a platform specifically targeted towards EE users, and that's probably why. The model behind that one is ultimately a paid model. EE itself is inexpensive in the grand scheme of things. Blocks apparently takes that further by just making the core free instead (a little bit of a trap). But the end result is the same: you'll be spending significant amounts of money on either, because both are built around a paid model. They are there for the money. And that's perfectly fine so long as the user understands that. But with EE, at least you are getting an experienced platform, history and track record. My opinion is that EE users looking for a change should look outward (beyond the money model) not inward. One you have your "a ha" moment with ProcessWire, you'd lose all interest in EE or anything like it. But EE users have to be willing to let go of learned complexity, baggage and preconceptions about CMSs in their mind. And not everyone is ready for that. If an EE user either isn't ready or doesn't find what they are looking for by looking outward, then they should instead look beyond the short term angry EE chatter. EllisLab is making long term decisions for the benefit of the company and the software, and it's actually a good reason for those folks that really like it, to stick with it. Individual developers are not going to be the ones paying these $20k yearly support fees, so it shouldn't be an issue. It's the big enterprise clients that will pay those fees, and they'll think it's a great deal relative to their old CMS monsters. What's good for EllisLab will ultimately be good for the people that want to implement and use their software. This is confusing quantity with quality. If quantity is the measurement, then EE isn't there yet either. If it was, I don't think EllisLab would be changing their business model. For better or worse, the EE ecosystem is also built around a money model. That ecosystem rises and falls with a business rather than the product. PW has always been about quality and has never been about quantity. I started this project as the only user for many years. When I put it out there, I intended to keep it going for the long term regardless of how many users we had. We don't get paid here. We do the work because we love it. They may be huge now, but Drupal and Joomla will really have to fight hard to be relevant in the future. They carry a lot of legacy ideas and methodology, and they kind of have to. They can only lose market share from here, so it seems like they are pursuing defensive growth strategies. When a Drupal, Joomla or WordPress developer gets a taste of ProcessWire--and really gets it--they are changed. I think that ProcessWire and systems like it will make it difficult for the likes of Drupal and Joomla to stay relevant in the long term. I'm sure EllisLab sees this too. But EE users should at least feel good that EllisLab is pursuing a growth strategy that seems geared towards growth rather than maintenance. WordPress is not great software either, but we can all learn something from the way they've grown and likely will continue to. I wouldn't trade our ecosystem or software with any of theirs. And for those that measure by quantity, we'll get there too, but we won't be counting. People from EE are totally welcome here. I'm glad you've joined the discussion. But want to be clear we are not hoping to achieve anything in that regard. If our strategy were to pursue users from other CMSs, we wouldn't be pursuing EE -- it only represents a tiny sliver of the CMS pie. We only want to gain users based purely on the quality of our software and community, and the good reputation that accompanies it. This is an open community and we don't control what gets posted. The only reason you see EE mentioned here is because of EE users that are now using ProcessWire. I appreciate their enthusiasm. While I have positive feelings for EllisLab and EE, it is not on the radar here as having anything to do with our project, goals or strategy.

I missed the XML sitemap generator that I used in a previous CMS so I built my own module to achieve the same functionality. This module outputs an XML sitemap of your site that is readable by Google Webmaster Tools etc. I've generally found that it reduces the time it takes for new sites and pages to be listed in search engines using one in combination with Webmaster Tools etc (since you're specifically telling the service that a new site/new pages exist) so thought I may as well create a module for it. The module ignores any hidden pages and their children, assuming that since you don't want these to be visible on the site then you don't want them to be found via search engines either. It also adds a field called sitemap_ignore that you can add to your templates and exclude specific pages on a per-page basis. Again, this assumes that you wish to ignore that page's children as well. The sitemap is accessible at yoursite.com/sitemap.xml - the module checks to see whether this URL has been called and outputs the sitemap, then does a hard exit before PW gets a chance to output a 404 page. If there's a more elegant way of doing this I'll happily change the code to suit. Feedback and suggestions welcome On a slightly different note, I wanted to call the file XMLSitemap originally so as to be clearer about what it does in the filename, but if you have a module that begins with more than one uppercase letter then a warning containing only the module name is displayed on the Modules page, so I changed it to Sitemap instead which is fine as the description still says what it does. File can be downloaded via GitHub here: https://github.com/N.../zipball/master

Morning Folk! Just sitting here pondering the world as I am just starting to rebuild my sadly neglected portfolio site (http://www.sanglier.co.uk). Currently in Joomla with the Seblod CCK extension, it has always been buggy and I lost interest in putting much content in it - stupid really. Any way to cut a boring story down to size, I was thinking about categories. I know how to create the idea of categories with pages and using the pages field to associate them together in various way, but I haven't the foggiest how I can do nested categories or relate the categories to URLs. So, for instance, if I have a category called "tech" I would want any article in that category to have the url sanglier.co.uk/tech/myarticle But if it were in a sub category called pw then I would want the URL to be sanglier.co.uk/tech/pw/myarticle I know this can happen with just using children, but the advantage of using categories is that I can have a separation between the menu layout and the article layout and the possibility of an article belonging to more than one category (if I can work out how that would work!) Any hints and tips from the great and the good? Joss (PS: Sorry for the "granny sucking eggs" explanation of the problem, but I am always aware now that it might not just be experienced users who read these questions and so I feel I have a responsibility to be very clear ... now I am really sounding like the old bear - damn!)

Would anyone be interested in a ProcessWire-themed meetup/social gathering in the UK?

Hey, I can make it worse - the slowest most plodding machine I have is ......... LINUX!!!!! *runs and hides behind sofa*

I dont need you to edit mine to achieve that....

I don't see an attachment either and I checked the post content in the editor (yes, I can edit your posts to make you all look silly).

Hi, it would be awesome if you would have kind of an generator on the download page where you could include for example some languages and the blog profile with ticking a checkbox. Like this: http://mootools.net/core/ / Nico

Like I mentioned here: http://processwire.com/talk/topic/2105-custom-installation-generator/

It's Windows 8 - much faster boot times, which makes you wonder what they'd done wrong before for so many years. *waits for the jokes from the Mac crowd*

Pete, thanks, but I already pulled another request, forgot to up the cache time. Also to fully work it would also have to add the "language_published" check to see if language version of the page is really published. Will try to add that later. Also wanted to add that I never use sitemaps for google and never will again (used to try long time ago, but it doesn't really help at all if you build the site carefully. It just eating time doing it and making sure everthing works still). It's not as easy as it first seems and can even be contra productive if not done carefully. Problem with this module as it is now, it will not find and list pages that may are added through urlSegments and I don't see a way to do it easy. Also it doesn't have weighting etc.

Yeah, probably just best to try the first idea for now with the choices on a download screen on this server rather than get a headache supporting everyone else's servers too

Pete, I like the idea of how you say it could work on the browser screen. All that advanced stuff heavily depends on how the server is configured etc. Gonna be brain shaking to make it work for most installs. (if even possible I don't know)

In fact, I've got a little time tonight and I also have experience with manipulating zip files in PHP so I might have a little test of some of this - certainly the merging for profiles etc.

Maybe a WordPress style themeswitcher? Note: sarcastic.

CTRL + F5 a few times - fixed it earlier today.

Heh! It is like going back in time to the very first website I made which was with the then, brand new Corel Webmaster Suite! (actually, second - the first was on WBS - Web Broadcasting Service) Coming from the world of film and radio where content is, by its very nature, linear, I had to start thinking about a hierachy. Though, having said that, one thing I forgot back then is that even working linear, you have to prioritise, not vertically, but temporally; each section or chapter must have its headline, its important facts and then its justification. A vertical Hierarchy should have the same thing somewhere along the line. It almost needs three sorting systems: Categorisation - your standard filing cabinet where a major headline reference is strictly limited to one folder (the old paper variety) Tagging - not a random "I think I want this keyword" system, but a strict, horizontal associative system that creates links between different parts of the hierarchical tree Order of importance, or perhaps Reading Order - where information that is associated either within a category or within a tag linked list is prioritised on the basis of what sort of information it is. That last one is really "out there" and is how a few of my relations like to work - they are heady, scientists (mostly ageing profs, these days) and like to sort information in several ways for research purposes. They all hate WikiPedia, in consequence, because they say there is no subjective or objective prioritisation and without that, you cannot truly judge the importance or context of any particular piece of information. Bloody fussy lot, basically!

@ryan, coming from mindplay this should be taken as a big compliment

Thanks for sharing that, apeisa - really useful and reassuring. This kind of thing really should be in the Wiki too - I wonder if the Wiki should have a dedicated area with descriptions of how to build and customize such features? I wonder what such a section would be called. (the word "Recipes" comes to mind - or perhaps "Patterns", or "Information Patterns" if you want to get really technical.) It's really important to collect and encourage new users to learn how common features can be built without (or with very little) code - many new users are going to be coming from CMS where such things require a plug-in, and a lot of people are going to assume that's necessary. Most CMS have a tagging/taxonomy module, for example, and it's features are set in stone. This kind of information needs to be readily available (even promoted) to developers. Of course, you can learn from the forums, so perhaps that's all that's needed - the trouble is finding the solutions in all the talk and long threads. Perhaps this could be solved by having some way to tag posts, so that they appear on a list somewhere. Stack Overflow does something similar - where you can post a reply to question in the "community wiki", making your post editable by others... Thoughts?

I'm happy to add this to the default admin theme too.

Creating categories using checkboxes isn't recommended. Create a nested page structure that represent you categories. Then use a page field to select from them (multiple if needed) Now the category tree can be used to output a nested navigation for example. In the category template you would enable urlSegments and you can use that simply to list pages that are linked to this category through page field. The template code for the category pages would look like this: if($input->urlSegment1){ // if url segment is a product we get the product to render details page if($pages->get("name=$input->urlSegment1")->template == "product"){ $prod = $pages->get("name=$input->urlSegment1"); } else { // else we get the normal page } } else { // in case we are on a "normal" category page, do different stuff $cat = $page; } Then proceed outputing stuff as usual. And the navigation using my MarkupSimpleNavigation module would be extremly simple. $root = $page->rootParent(); // the root page of the categories $navcol = $nav->render( array('collapsed' => true), null, $root); This will give you urls like /categories/cat1/cat1c/ where you can list all product that belong to cat1c. And have product links like: /categories/cat1/cat1c/product1 Which can then constructed like this: <a href='$page->url$prod->name/'>$prod->title</a> Hope that helps and is understandable. Not finished but working on a shop that uses this approach here: http://sultan.urlich.ch/shop/ Same is done with ingredients for products. A page of a incredient then lists all products that have the ingredient like here: http://sultan.urlich.ch/zutaten/gewuerze/

I think we should consider a new module which covers some more functions. The concept of contexts in MODX for example is pretty straight forward (in theory). So I think something like this would be nice to have: - define any desired rootParent as own context - every context can have its own context settings (for example domain or even own alias with the same domain as the root, language, id of own 404 etc.) - In your templates you could just refer to these settings via $context->my_setting - the url creation has to be implemented with a hook (path::after?) so it works everywhere - cross context linking should work (so TinyMCE has to tweaked I guess) - fields, templates etc. can be shared between contexts (organisation via the new tag function) - [...] I think it is a very common use case to have several websites (domains) in one environment, so this would be awesome if we would have a module which considers all these "problems" and would work out of the box. So we could claim PW as "multi language, multi domain" without tweaking Unfortunately this is beyond my PHP skills :-

@Matthew What I had in mind here was really to encourage more regional meetups first, a bit like Linux User Groups (not just Linux, I'm sure there are other groups that are similar) and if there are enough people using PW near one place then even "local" user groups might be possible. That said, if we do manage to arrange some meet-ups here in the UK, I can't imagine that we'd turn away any PW user who can make it. @Joss Sounds interesting but the date's a little further out than I was initially thinking. Perhaps that would be suitable for a "national" level PW meet-up? But there's certainly room for flexibility here. Going by what people have declared in their forum profiles there are a number of PWers in the London area (such as Panictree, ffub, selfthinker, Lars282, antknight & potentially others) and there is another "cluster" around the Manchester area (Gazley, Pete, DaveP, Onjegolders, myself & maybe some others.) For traveling convenience this sparked the regional meetup idea but if that spreads us too thinly then opening it up wider might well be better.

I have pretty mixed feelings about this module myself. It does work (well, there is one user where it doesn't and I don't have a clue why), but all should be aware that there are many things to consider: Complexity grows exponentially with each subsite you add. More templates, more fields, more pages Your coding needs to be different if the site is subsite: $page->rootParent isn't actually rootParent, but the home. www.campaign-site.com/processwire/ admin isn't there, it is only at www.main-site.com/processwire/ Maybe not compatible with all the modules. Ie. form builder works, but you need to create new /form-builder/ page under each of your subsites. Cross linking doesn't work yet. Ie. if you use get or find to find pages from other subsites, then echo $p->url() won't give the right url (this is should be actually easy fix, but not yet fixed) If your subsite is big, I don't think using this module is good idea. For simple marketing campaign sites I think this is fine way to go, but for larger sites I would consider other approaches.

That would make sense if there was any information associated with them - but this approach would require you to create two templates, one for the value list, and one for the values, and neither template would have any fields. And then creating pages just for those values. It seems wrong.

I know it seems a long way off, but outside my house in June we have the Stony Stratford "Folk on the Green" - sort of a mini Glastonbury with only a thousand or so people (maybe more, it gets packed) https://www.facebook.com/groups/230311870317688/photos/ And it is free - sort of the music version of Open Source. Various places to stay round the town - could have a meet up on the Saturday and then the Folk on the Green on the Sunday (it is only one day) Depending on how many people - if only a few, we can do the meet in my small garden. If lots, a couple of the pubs have function rooms we can hire. All a bit vague I know, but I throw it into the mix as an idea. Edit - the date this year will be Sunday June 9th

Fixed another issue with not being able to see quotes or code blocks when editing - now you can see them which makes it easier to edit them. Note for all: Use the quote or code buttons in the editor as they're the best way of adding either reliably. They've improved them in this version. Heck, even code indents work with them EDIT: Nico - I fixed the nav colour to match the site too.

Nik: this seems to be great! although I am having little problem on my localhost when testing. I get this error msg after page save: Unknown page And url on address bar is this: /processwire/page/edit/ I have just installed the module, not touched anything. This happen always when saving. Tried uninstall / install, saving multiple times etc, but same thing. PS: I read the name After Shave Actions (whatever that means ) "After" actually feels little strange as module "headline" - how about AdminSaveActions? Admin would be general enough to keep more modules of this kind.

It was a long time ago! It is easy to forget how old that film is. However, the same comapny did get the gig for recording the voices for the feature film years later (after I left, I should add). It was a tiny little studio held together with string, more or less. But the voice sound was okay. At the same studio we got the job of going through EVERYTHING that Gerry Anderson had every made, finding the best prints and re-syncing the audio from all the language versions. So, that is Thunderbirds, Supercar, Fireball XL5, Captain Scarlet and the rest .... By the end of it I hated puppets! I should add that I also did all the voice recordings for Postman Pat - the original two series. Those were made by Ivor Wood who was the animator behind Paddington and the Magic Roundabout. http://en.wikipedia.org/wiki/Ivor_Wood When Nick Park heard that I did work for Ivor, he just thought it was amazing - to people like Park, Ivor Wood was king. Ivor was also an absolute gentleman and a pleasure to work for. We did 34 episodes (I think) over 20 years. It takes a long time to do stop animation! When he retired and we ran out of stories I got given a Postman Pat tie. Strangely that was a really nice gift and I still have it.

We're planning to have JSON export/import for fields. Templates are a little different in that they have a file on the disk too. But we can still make the data structures templates portable in the same way as fields.

I get mixed feelings replying to this topic to be honest though, let's do it: The title says "...and how ProcessWire could benefit" but, nobody goes into any detail about how or why PW would benefit from having EE devs come to PW. Or for that matter why EE devs would benefit from PW minus it being free (there are other CMS that are free I might add.) Posting in the EL forums wouldn't be cool by the way. Thankfully that idea looks like it was shot down! Seems like you are having fun with the Alternative.to which, is find, whatever. Having admin themes which look like EE isn't helping your "cause" if you want to call it that. I know these are user submitted though, putting them on the homepage gives off the wrong impression especially to EE devs I've talked with. Most of which do not like "plagiarism" even if only closely resembling the EE CP. Glad you changed them out for the default ones. You guys know why you like PW though, someone who has been using another CMS everyday for the past 5 years, for example, might just see PW as noise along with all the other CMS out there. I've talked about it before though, there are plenty of people who prefer a template engine over strait PHP or PW API however much you might think the API is just as easy. Is PW like theming for Drupal or Wordpress? Not even close and I commend you on your work with the API though, like I said, it may not be everyone's cup of tea. To be honest there is currently quite a bit of CMS "research" taking place within the EE community though, I'd say most people are just testing the waters and probably a bit less now that the initial shock of the EL changes have settled down a bit. Plus, folks are getting help via the new ExpressionEngine StackExchange site so free support is better than ever and there are more options for support then ever as well. Some people have abandoned EE altogether though, that's common with any CMS or Framework when there are major changes. With that said, PW is being looked at yes though, so is PyroCMS, Statamic, Perch and very importantly Blockscms which probably is most likely to put a dent in EE if any significant dent are to be made. Others are being looked at as well (maybe even some RoR and Node stuff.) PyroCMS is moving over the Laravel 4 (away from CI) which might just propel it's future use. Hard to say. I'm sure there will be other Larvel CMS popping up (other than pongo that is.)Statamic is different in that it's a static CMS similar to say Jekyll though PHP based (and commercial I might add which believe it or not allot of people do like.) In it's current state it could definitely compete with Perch in the "Lite" CMS arena which by the way isn't so small any longer (the Lite CMS arena that is.)Perch is another one people have been looking at though, of course that's for smaller sites too. I need to give v2 a try.Now Blockscms is a whole different story altogether and is the most anticipated to compete directly with EE once it's out of private beta. I'm not going to go into all the details though, yeah, it's coming. We'll have to see what this new year brings for that. This is really a topic in itself so I won't extend this already long post out any more on that. WIth the recent changes I think allot of people might consider using some of the other options I listed especially for personal sites or smaller client sites where as in the past they would have just used EE for everything. Allot of this stuff wasn't even there two years ago so, sometimes it's all about timing. Currently there really isn't anything that is on the same level as EE especially in regards eco system. No offense but you're not there yet. You have Drupal, WP and even Joomla of course (all are "free") which have huge eco systems but, yeah, let's not talk about those any more than I hear Drupal 8 is suppose to go Symfony 2 so I'm curious to see how that turns out. Anyway, I guess I'm not quite sure what you guys are hoping to achieve by having people come over from EE especially since there isn't anything for you to gain other than more hands on deck (which I guess I understand.) Trying to reach any users via a forum post is just senseless if you ask me and you're going to have to step up your game in many areas to compete with what's coming down the pipe. I look forward to seeing the future as things unravel for PW and all those involved.

Selfsupport! Brillant!

Here's a list of services you can submit your sitemap to: Google Webmaster Tools Bing Webmaster Tools There used to be a service for Yahoo called Site Explorer that was similar in functionality to the above two services, but it appears that this has now been replaced with Bing's offering. On the bright side it's one less service to sign up to You can also submit to Ask using the following URL (replacing the relevant part with the full URL to your sitemap): http://submissions.ask.com/ping?sitemap=http://www.the URL of your sitemap here.xml Generally I find Google and Bing to be sufficient though, as the other search services seem to trawl their content reasonably quickly and find out about new sites that way sometimes I think.