Pete

Ah right, makes sense that it would be something that you would want to use with or without pages.

I've used MooTools before jQuery. I didn't enjoy the experience of asking a question on the forums once and getting shot down for it - especially since it was my first question, but that does sometimes come with the territory (though I had read the instructions and used Google, just probably wasn't searching for the right terms). I find jQuery to be easer to use, but that's just my personal preference and I don't get into complex classes with javascript at all, so opt for what I find to be the easier to use library for general daily use.

I've used this script, built from stuff I learned here to back up sites in the past. It will only work on Linux hosting though. To use it, create a folder above your public_html folder called "backups". In this create two folders called "site" and "db". It must be above the public_html folder else you will end up backing up your backups and you will soon run out of disk space that way Now you need to open the attached file and change the path near the top to the path to your backups folder. Next, scroll down to line 41 and enter your site's root username and password (or a database users that you have created that can read all relevant databases for your site). That's it really - upload it into public_html and call it via a web browser to test it, but it should backup the entire contents of public_html and all databases, plus as a special bonus your mail folder, which on this type of hosting means that even if the whole server bursts into flames you can just re-create the mailboxes, put that folder back and the mail is back too Since it uses system commands to run the backups it won't work on restricted hosting, but the easiest way is to follow the above instructions and if it creates files in your /home/yoursite/backups/site and /db folders that have a filesize greater than 0kb then it will work on your hosting. Because it uses system commands rather than PHP to back up, it won't mater much what size your site is and is suitable for sites in the gigabyte range (all depends on your hardware of course). The other thing to note is that it keeps 7 days of backups and cleans out anything older. You can change that by altering the $livecutoff variable to something other than 7. This could use some improvement of course, but I use SyncBack Pro to download the backups each day to a local drive, and also periodically back these up to an external drive kept elsewhere (can you tell I've had trouble with hosting and hard drive failures before? ). cronbackup.php

I think the main thing is that when you know there's an easier tool to work with it makes everything else a chore. I was a bit surprised about the SEO person's response from your post above, but I guess I shouldn't be and thinking about it I had a very similar conversation with someone earlier this year myself who was worrying about re-training to use PW. It can be a hurdle to adopting a new system when clients think there will be a massive learning curve and it's generally just because that's what they've cmoe to expect. I think the main point to get across is just how straightforward things can be when everything is laid out logically. We have the luxury (and it is a luxury compared to most other systems) of being able to have custom fields for everything, and being able to name your fields and order them how you like means it becomes very intuitive to the point where there isn't actually much training required. I'm the same with MODx now - used it for quite some years and going back to it is hard work sometimes. Most of the clients I have that still use it don't need new features though so it's just a case of occasional updates, but I do try and convert them when I can. With this current site I really shouldn't complain and should simply have done more research, but it's the case with most projects when you're taking something on that's already established that you will eventually run into something unforeseen - if you could afford to spend days checking out every aspect of a job before taking it on it would be okay, but you generally have to hit the ground running and get on with it. It helps to vent your frustrations sometimes It's another one to chalk up to experience, but I still don't want to work with anything other than ProcessWire again

I've been working on a site recently that is in WordPress, and have wasted several hours on not noticing that the previous dev had used a mad-crazy image based menu system (should have inspected the CSS more closely). Since I'm not used to WordPress, I was trying to sift through the many (and, in a lot of cases for this site, unnecessary) plugins to find the fault. So okay, it was partially my fault for not noticing that, but just the whole rest of the experience has drawn a line in the sand - everything is so difficult and time-consuming to achieve that I think even if I knew it inside out it would still be long-winded So, no more WP clients for me, thanks all the same, even if there are big bucks on the table it's not worth my sanity any more and is too draining. I'd much rather roll out/update PW sites and enjoy myself rather than tear my hair out over the many and varied caveats of working with WordPress. Call me lazy, but I think it's more about using the right tool for the right job.

WillyC - you can be cryptic at times, but I think what you're hopeful about is ryan's earlier answer to Antti's question about file fields and when they might be coming. So ryan, like WillyC I'm curious to know if you're working on files next? Presumably with save to page now an option this is a bit of an easier prospect? Obviously there are still security concerns, but if you at least assume that form-to-page submissions create unsaved pages then that might be half of the battle (the other half of it being that if you can guess the page ID and already know the filename you could access the file, so some security implications there maybe?).

Ryan's a ninja - his other hand is actually coding ProcessWire on his MacBook and he's not even looking at the screen!

I need a back-to-front baseball cap with the logo on it so I can look hip and inspire a younger generation As a more serious suggestion, since "Powered by ProcessWire" would be the logical tag line for a website, why not have "Inspired by ProcessWire" on things like mouse mats and mugs?

I was thinking the exact same thing with regards to not putting up any potential barriers too soon. In fact, I know a few web hosts who have only just recently made that switch. I don't use them of course, but just saying that while several hosts still seem to be switching 6 months sounds about right. (By the way, this is my keyboard and I love it dearly - I cannot recommend it enough and have one for work and home. It is also heavy despite being uber-slim so can be used to fend off any would-be home intruders ).

40,000+? Wow, and I was just thinking of using it with 50

Just a quick note to say that whilst I have little idea about the technicalities of the difficulties you're having, I'm following this topics closely as I was seriously considering using PW for an intranet and the type of functionality you're talking about Antti would remove one large obstacle from my way

Oddly enough I'm having a similar issue right now with a different system and I'm sure it's because of conflicts between two and I'm 100% sure it's because of this: http://php.net/manual/en/language.oop5.autoload.php Not sure what the solution is though, but any suggestions would be much appreciated.

Oh, but I'm now seeing an issue with where it's trying to pull content.css from when I look at Firebug. NetworkError: 404 Page Not Found - http://localhost/pw/wire/modules/Inputfield/InputfieldTinyMCE/tinymce-3.4.7/themes/advanced/skins/ergo/content.css Soma - can you confirm there's an error there? I'm not sure how to solve it though as it's not as simple as adding another line for the content_css variable

Soma - this was exactly what I was trying to work out the other day so thanks a million With the joys of localhost versus live site folder structures however this is now probably better if it's put back in the default.php template file just before the closing </head> tag as this: <script> if('undefined' != typeof InputfieldTinyMCEConfigDefaults){ InputfieldTinyMCEConfigDefaults.skin = "ergo"; InputfieldTinyMCEConfigDefaults.editor_css = "<?php echo $config->urls->adminTemplates; ?>themes/ergo/ui.css"; InputfieldTinyMCEConfigDefaults.popup_css = "<?php echo $config->urls->adminTemplates; ?>themes/ergo/dialog.css"; }; </script> Then it'll work in every environment. Thanks again for working most of that out - I really think this is the ultimate way now of overriding the TinyMCE template for themes and not having to worry about the TinyMCE module being updated or overridden so I'm very happy with this

Yes - just as a hint more than anything as I don't think it will do any harm. Maybe even mention the default skins you can switch between too (default, o2k7 and highcontrast from what I can see). That would be great

I'm working on a module where I use MarkupCache within the module. Normally you would use MarkupCache in a template, but I fancied putting it in the module as it needs to use some 3rd party classes and it's just a lot of code to dump into a template. What the module does is my own version of pulling and caching X tweets from Twitter. The problem I had was clearing the cache when I'd changed the number of tweets to store in the module's config and saved the config. With help from netcarver it became apparent that you can hook into saveModuleConfigData, but it then took me a while to work out how to hook it. The answer was in InputFieldPageName.module on lines 134-7: static public function getModuleConfigInputfields(array $data) { $modules = wire('modules'); $modules->addHookBefore('saveModuleConfigData', null, 'InputfieldPageName_saveModuleConfigData'); So not in the init() where I'd been trying to put it, but in the getModuleConfigInputfields function instead. Because it's here though, you have to put the function that's called outsite of the class' scope, but that's not an issue really. In that same module you can scroll to the bottom and after the last closing curly-brace is this: function InputfieldPageName_saveModuleConfigData(HookEvent $event) { $arguments = $event->arguments; if($arguments[0] != 'InputfieldPageName') return; $data = $arguments[1]; $name = 'replacements'; if(!is_array($data[$name])) $data[$name] = InputfieldPageName::replacementStringToArray($data[$name]); $arguments[1] = $data; $event->arguments = $arguments; } You can still use the wire class from in there as well, so you can still pretty much do what you like. In my case it was this simple two-liner (setting the cache to 0 seconds effectively wipes it): $cache = wire('modules')->get("MarkupCache"); $cache->get("latest_tweets", 0); Just thought that might be useful to someone else in future So thanks again to netcarver, and also to ryan for having had the need to do this before and making saveModuleConfigData hookable!

Oh now that's just perfect - had no idea it would be that simple diogo! It works just as well in the admin template's main.js file too! @ryan - any chance it could be included in the main.js by default? I know it doesn't necessarily need setting for the default theme, but having the prompt there that you can change it would be handy!

Thanks, that certainly helps it stop being reset on upgrade! It would still be ideal if there were a way of setting the value somehow within a theme package though.

Can I make a suggestion that the default skin for TinyMCE should actually be "default" and not "o2k7"? The thing is, whilst "o2k7" fits in with the default ProcessWire admin theme, the theme called "default" fits in better with almost every other theme produced so far. I can see a couple of options here - switch the theme to "default" for new downloads from now on and override the colours for the default PW theme, or else make that a configurable part of the module (though the second option doesn't help if you want to set it with your admin theme). I realise what I just suggested above for the default PW theme - overriding the CSS in the admin theme - is another possible way to do it but it's just that every other theme looks fine with the theme "default" and only the original PW admin theme looks fine with "o2k7". Another alternative would be a simple way to override the setting outside of InputFieldTinyMCE.js but I can't think of one off the top of my head. It just gets a little annoying at present to have to remember not to override the setting I change with each new PW upgrade Not a big issue of course, just one that bugs me a bit

@yellowled - it would end up being a long list of those that we don't recommend. I've had the misfortune to work with about a dozen such companies over the years

In the PW admin you can simply change the URL of the admin page itself to be something completely different. Just remember you'll need to remember what you changed it to in order to type that URL in the address bar and log in again afterwards!

I found the X-Wing... under the ground... I've only gone left from the original starting point on that one so far - this is HUGE!

Doesn't look like I will get the time for at least a few weeks, but what I had in mind for making an awesome newsletter module for ProcessWire is things like this: Building templates in PW's template system (duh) Being able to reference content from elsewhere on the site (like check out X amazin product/service) - essentially a repeater field for Service Title (if you want to override the page title you're referencing) short description (again, only if you want to override that page's summary), image from that page and then being able to drag and drop that sort of content quickly into any order. And so on It's really exciting when you think about all the possibilities of what you can do just by creating each newsletter content as a normal page and template combination, so I think that any such module should leave that completely separate and just focus on: Subscribes/unsubscribes - a default system to store subscribers as users with a guest and newsletter role (I think it should be this anyway) and make the class so it can easily be extended to add/remove/deal with subscribers any other way someone can think of Sending mail Dealing with bounces (from systems like Mandrill, although if you read the info it deals with a lot of this itself if you forget to remove bad addresses - it just won't send to them again to keep you compliant and will notify you, which is nice) These are the basics and I think it could just be a case of keeping it this basic - everything else is a case of PW pages and templates then, plus a bit of a headache in terms of making all your styles inline once again like back when you didn't know what a stylesheet was For that reason alone, perhaps it should ship with a default page, some fields and a template as an example? It could well be that this is complex enough to warrant another paid module, especially when you start thinking about shipping it with a selection of templates, or considering ways to make it easy to download new templates from within the module (probably a version 2 feature!).

Thanks Joshua - I've still experienced this on occasion on one site. Same conditions as you - reading pages into a page array then sorting by a date field. Most of the time it works fine, but I've size learned to do an additional sort of -id which is fine in most cases but not ideal for queuing posts up for future publication. Every so often I see pages display in a weird order, like the sort hasn't sorted properly on one page load, but then later on its fine. Most odd - I'll try your suggestion and see what happens. I suspect nobody else has come across this as you have to have a very specific set of circumstances for it to happen.

Yes, I'm not saying its a bad thing as You're both right that it would be a nightmare without it. I just remember a time when there was a chance of answering it correctly on the first attempt whereas as Apeisa says it can take multiple attempts nowadays so whilst the forms no longer get spammed I really worry about how many people are simply giving up. The Turing test of a simple Q&A has worked well for me elsewhere, even if they're simple things like "The Beagle probe crashed into Mars. which planet did it crash into?" you're keeping it simple and automated spammers are kept out. This forum software actually allows us to enter several such questions and loads a random one, so the more the better as if a spam program is taught only one answer there's still some level of protection. For example, it would take only a short amount of time to come up with a few dozen simple questions and I think that would solve the problem as well as reCaptcha. Sorry, I'm thinking more about the FormBuilder now than the CMSCritic form but these are purely meant as helpful suggestions