Pete

It's one of those things that keeps cropping up, definitely, as I mentioned it too somewhere. That post didn't have a reply until just now I thought someone had replied to all the topics with no reply.

Great minds think alike: http://processwire.com/talk/topic/2524-install-processwire-pre-select-a-profile/

Thanks - merged it The main reason I created it was because it gets a new site listed faster - plain and simple. That was my experience from sitemaps a few years ago at least so I hope it still happens, but it does seem to work from my experience. I've never bothered with weighting or anything like that. Not bothered about URL segments either as for a start the crawler will find a link to that from a normal page on the site presumably, but my main goal was to get Google to crawl the page sooner than it normally would - and I think it will do this every time it looks at the sitemap and sees a new page (assuming it doesn't find it in the crawl already on its own by following links in the content). Think of it this way - if you release a brand new site without telling Google, it will take until someone links to your site before Google is aware of its existence. On a small, personal site with no blog or comments that could be a loooong time, but the first thing I usually do is launch a site and submit it so I know it's done. The argument against this is there are other ways of doing that as search engine companies often have pages where you can just type your domain in and they will search it sometime later, but I like to keep Google informed when I add new pages etc just in case it has a lapse in concentration and misses something

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*

So far the biggest hurdle has to be GitHub as it creates awkward filenames when you download the zip files from there. I've mentioned this somewhere a long time ago, but I think the way this actually needs to work is two-fold. Every time someone adds/updates a module in the Modules directory, this needs to flag a module on the main PW site at processwire.com to then fetch and download that module. I'm sure there's code in the ModulesManager module that makes sense of the filename and the contents so that's fine. Older versions of the module that have been downloaded this way are deleted from the PW server The contents of the zip file are then extracted to a folder on the PW server From the choices the user makes, a special packaging script can then scan these folders for the relevant parts and add them to a zip file on the fly. The zip side of things is pretty easy so long as we know where the files are. For example, not a lot of people know that you can do something like this in such a small amount of code (although I know a few here do, but it's fun to share): $zip = new ZipArchive; if ($zip->open($config->paths->root . '/site/files/ryancramerdesign-ProcessWire-2.2.9-9-gd453a76.zip') === TRUE) { $zip->extractTo($config->paths->root . '/site/files/processwire/ryancramerdesign-ProcessWire-2.2.9-9-gd453a76/'); $zip->close(); echo 'pw229 ok'; } else { echo 'pw229 failed'; } if ($zip->open($config->paths->root . '/site/files/ryancramerdesign-BlogProfile-cca31eb.zip') === TRUE) { $zip->extractTo($config->paths->root . '/site/files/site-profiles/ryancramerdesign-BlogProfile-cca31eb/'); $zip->close(); echo 'blog ok'; } else { echo 'blog failed'; } Well that's the core and the blog unpacked easily into separate folders (yes those filenames are the horrible GitHub ones). Then, assuming you can get past the fact that GitHub puts in a folder with a similar stupid name you can then just copy the various elements to a temporary folder and zip them up (if you selected a site profile for example, you would want to delete the site-default folder first, put the profile's folders in the right place in the PW installation structure and then zip it). I'm not saying any of it would be simple, but I can see how it's doable. Some of it may be a bit beyond me though!

Soma just submitted a pull request and I merged it. The 1.0.4 version should allow you to use this with the LanguageLocalizedURL module - let us know how you get on and thanks to Soma

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

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.

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've got a custom built PC with Windows 8 and a 24" monitor. The only reason it's custom built is that I like building PCs and get to build half a dozen or so a year or more (not for me!). It's nice when you can pick quality parts and put them in a slick, quiet case. I also carry a DELL XPS 17" but it's a bit big for my needs nowadays and I want to move to a Windows Surface at some point when the Intel versions are out so I can have my entire web dev environment on a tablet that I can then plug a monitor and keyboard into when I want or use as a tablet again when showing off work. I can see that really working well for me and it would totally remove the need for a laptop. It would also cause me less backache versus carrying that beast of a laptop around

It doesn't accommodate it at the moment, no, but I may need this myself soon so if you can wait a week or two I may have an update (it's not at the top of my list at the moment but I might surprise myself and do it sooner ). Thinking out loud, it needs: Check if LanguageLocalizedURL is installed Find the root page for each language Generate a sitemap.xml page under each root page (it doesn't really generate a page in the database, it just outputs the sitemap if you request that URL) I think that's it, but I need to get to grips with the LanguageLocalizedURL first.

To my mind they can be the same thing in PW. What I have on one site is what a lot of others here do - have a hidden Tools page and under it I created a page called Tags and then put the tags under that. Then, using a Page field I can tag my articles. Articles are stored under /articles/article-name/ . When viewing an article, you see the things it's tagged against. The next bit is where cateegories and tags become interchangeable, because if it's a small list of tags I would then have a category list down the left based off those tags, so when you click it it returns all articles tagged in that category. This way of doing it provides endless options - people can browse by "category", or land on a specific article on your site and click a tag in the list against that article to view others in that "category". The lines are now totally blurred, but you get the best of both worlds. Of course the other option if you think you want a limited number of categories but maybe hundreds of tags over time is keep them totally separate, which is also fine. Not sure whether that was much help, but I think if you have a think about how many categories and tags you might have for your current content and whether there is a lot or just a little crossover between them then this will help you make a decision on what to do in terms of structure.

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

It doesn't, but that's not a problem. You can build any structure you like - everything is based around custom fields and it only takes a short space of time, so the beauty of it is that you end up with exactly what you want rather than what a module (assuming you mean like modules with other CMS's) might force you to have. This means you can add any addtional fields you might like and so on. Can you describe what you want to achieve or point us to an example elsewhere and we can give you a few pointers.

The aims seem to be: One site folder One templates folder (which is where it gets messy) One admin interface Potential to share information across sites by calling something like $pages->context('sitename')->find('selector'); - This is the best way I can think of making it work anyway I'm trying to do this without the time to draw a diagram, but the way I would see a new module working would be something like this: Have a single wire folder Have a /site/contexts/ folder, each site has its own folder within containing templates for that context (that way you could ignore the original templates folder) Write some API code to do something like $pages->context('sitename')->find('selector'); DON'T show all the sites in one tree in the admin - no need, just have a drop-down at the top-right somewhere to switch between contexts Give them the option NOT to share the same database if desired. This then caters for marketing mini-sites to share the same DB but larger sites to be separate, as well as allowing for complete separation of templates and fields if desired (useful for creative studios with many sites) This addresses all the requirements I think. There are a few compromises, but this ticks off the main aims I listed and doesn't over-complicate matters. What do you guys think? MODx contexts made my brain hurt so I'm throwing this idea out as something that's hopefully simpler to setup, understand and manage Other considerations are: You need some way of having single sign-on to switch between contexts (let's just call them sites hey? I'm getting confused every time I type that ) if you use the separate databases approach Someone needs to add some functions into the API to make this work the way I described above, but I think that's possible Also the selectors could just be like $site->get('sitename')->pages->find('selector') but I like my first idea better Maybe $pages->site('sitename')->find('selector') though since I've totally gone off the term "contexts" now. Of course if you don't specify the site() part then it will default to the site that the template file is in.# And anything else you can think of...

Amazing, I'll have a look at this later today

A lot of us do this and have a Tools template with just the title field that are used to populate Page fields for selects, autocompletes and ASMselects etc. It's perfectly normal to do this in ProcessWire bit yes it does feel strange to begin with. One advantage is that using ASMseldct (or others) is that you cam tick the option to add more values on the fly when adding pages. Give it a try

I'm saying noooooooooothing

Done, and tagged as a module request

I'm up for this.

Just building on what Luis said, the thing about ProcessWire is that it doesn't make any assumptions about your templates on the front-end, so you couldn't package it as a working part of the core anyway as the first thing most people do is implement their own templates which would strip out the necessary tags to make this work. I think it could certainly be a module (just so it gets bundled with one or more of those editors) that can be downloaded and installed with simple instructions for the developer to implement the necessary tags into their template though, so that's certainly worthwhile someone pursuing. There are some considerations though, such as the way images are handled in ProcessWire, that require further thought as well (hence why I'm thinking a module again). As with most things in PW though, it's certainly possible to implement

ALT+TAB breaks it

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.

Willy needs this hat: http://www.loveitsomuch.com/stores/yoda-hat-crochet-pattern-newborn-toddler,260842.html

Luis - can you refresh again? I think there's a caching issue but I might have solved it this end (the JS cache now has a different hash in it). Oddly though I didn't see the problem in same version of Opera on Windows 8 here. Nico - yep - that's on my list. My local copy was a bit older than the current theme so I'll match that at some point.