Pete

Have a look in index.php and you should see what is possible. Only issue I can see is you would have to remember to make the changes every upgrade so I wouldn't bother personally as there's no security reason for doing it that I know of (changing the admin URL is upgrade-friendly though).

I'm confused by your last statement - you cant have a field in ProcessWire containing PHP code. It would just spit it out as text. Even if you put PHP into a text field the only way you could parse the PHP is with eval() and that's really not recommended. Or am I misunderstanding?

Well first off I'd say try it in ProcessWire so we can rule out MODx as the issue.

I was expecting a long to Icanhascheesburger after all those cat mentions but that picture is equally random.

Yeah, but I meant more like this because I'd forgotten about that second link : <?php // Some code to iterate through the folder structure needs to happen, but when we have a file we do something like this: $filecontents = file_get_contents('news2-sample.txt'); $filecontents = explode('<!--Head-->', $filecontents); // This splits your contents into an array containing stuff before and after the <!--Head--> delimiter $details = explode("\n", trim($contents[0])); // Now Package, Rank etc are in an array - $details[0] contains Package, Name would be $details[2] and so on // I'll ignore <!--FM--> as I have no idea what it is, so let's just imagine that wasn't in the text file $maincontent = explode('<!--Text-->', $filecontents[1]); // We're now dealing with things after the <!--Head--> tag. $maincontent[0] now stores the article title and $maincontent[1] is the body. ?> There's more you can do from there to turn the newlines in the article body into paragraphs but this gets you started with some ideas of how to parse it all. Someone will probably come up with a better way fo parsing it all using regexp though but I went with what worked inside my brain (regexp hurts my head too much).

I keep threatening to do one too but haven't found time yet... which is silly as I think it would take me less time than I spent on theming the forums!

It's possible to parse either of those easily with PHP, but I can't look at it tonight so I suspect someone else may beat me to a code sample that might do it

There are a couple of things to bear in mind with this - some of them are the reason why I've not yet released it as a module. Their API was a bit basic, so I've not gone the API route at all with the module - it actually initializes the forum software itself and calls on classes and functions where required (so it doesn't load everything, but there is obviously some overhead like if you bootstrapped ProcessWire). This isn't a downside from a functionality point of view as that's how other apps from Invision Power work to some degree so I'm not doing anything the system isn't designed to do (one of the first things in the module is that it declares IN_IPB = false; for example to tell the forum classes not to load everything unnecessarily). The potential problem for me is that if they release a version 4 of the software or even a minor version, many of the classes and functions could change, so I need to think about supporting the module. It's reasonably advanced and I'm actually doing some work on it with another site to make it easier to roll out, but just integrating things like the member bar at the very top of the forums here into a PW site has all kinds of styling and Javascript issues that I'm hoping to get around so installation is just of a case of copying and pasting some snippets of code into templates. The bottom line though is that there is going to be some work on the part of the developer working on your ProcessWire project (you in this case) in terms of implementing things in the PW templates, so I will probably release it as a paid module so I can handle support. Plus I'm being a bit selfish in that it took me a hell of a long time to build as their code didn't make it straightforward No price estimate yet, but it wouldn't be extortionate. As a quick feature list: Member bar template for inclusion in your PW templates - member bar functionality carries across seamlessly between forums and CMS "Latest topics" function can pull from a news forum or any forum you choose. Caches for X minutes so you're not overloading the server. Create Topic function can be tied to PW page creation so you can handle comments inside the forum software (alternative to PW's comments module). Delete function will be called if the page is deleted. Add/Edit/Delete reply functions as well (so you can comment on a page that has a topic linked to it) Login/Registration (planned functionality coming soon) I know it doesn't sound like a lot, but you have access to all of the member's forum information as well, so you can really tailor the experience for them without having to create a user account in PW for them - I do have some experimental code that will do that as well though

I liked this one a lot: http://www.koalastothemax.com/ You can see the koalas eventually - at the max in fact! Extra points if you get to the end of this: http://heyyeyaaeyaaaeyaeyaa.com/

Formbuilder works on 2.3 if that's what you're asking?

To be honest it's not like other systems where there are massive changes - everything from 2.2 will work in 2.3 so it's up to you. Upgrading is just overwriting the /wire folder too so no hassle.

Jing is okay for free.

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).

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.