adrian

Both work here - what version of PW are you running? One thing to note though is that you shouldn't be overwriting $users as this contains all users in the system. If you redefine it, you won't have access to all users via $users further down in your code.

Or if you have the skills, perhaps you'd be interested in creating an plug-in for Migrator, like Nico's WP migrator. We have a lot of ModX refugees here, so I am sure it would get lots of use. I don't know anything about ModX, but I'd be happy to help in any way I can.

Maybe the way is a modal dialog on the templates edit screen that accesses the complete field creation and configuration options and as soon as you save and the modal closes, the field is added to the ASM of fields in the template? Otherwise you could be potentially stuck with needing to go back and edit the field settings.

Hey horst - good points about shared servers for sure! I guess I am in the unusual situation of managing my own servers so I have disabled FTP, but I do have SFTP enabled. To compare, I know that Wordpress does not support SFTP by default which would make their automatic core upgrade process useless for me - lucky I don't want to use WP I'll probably still be using git pull for all my PW upgrades, because of the write permissions I have set on my servers, but I think it would be nice to have this module support all possible options.

I think @NorbertH's motivation might be that he doesn't want standard FTP enabled on his server at all. I think it is about keeping the server in general more secure, rather than protecting the actual transfer of PW files. Is that correct?

Ok, I'll stop hassling you about an orange warning option now that I know that a revamped notifications system is on the way The upgrade module really is fantastic - thank you!

Might be nice on a small site, but would be slow and cumbersome on a larger one. PS You should upgrade your version of ProcessPageDelete - actually uninstall and reinstall the new one so it gets rid of that extra "Delete Page"

Sorry - more things: The entry in the modules directory goes to this broken link: http://modules.processwire.com/modules/-process-wire-upgrade/ The upgrade notification on login is awesome, but being in green I don't think anyone will notice them. If someone is regularly accessing their site, they might never (or at least rarely) have to login. Especially if they are using Persistent Login module. Any chance of running the checks in the background at some interval?

Works great! Only one thing - I am worried that someone running dev will see the "Older than current" on the PW Stable row - click to /setup/upgrades/check?branch=master and run the Download Now "upgrade". Maybe this is fine and should just be a case of reading things properly, but just thought perhaps there could be a warning about it being a downgrade?

I am not really sure, but PW 2.5 is just moments away from being released: https://github.com/ryancramerdesign/ProcessWire/commits/dev So I would say grab a copy of that, do a fresh install and see if that works for you. If not, then we'll figure out what is going on with your particular setup. And sorry for the rough start - this is highly unusual

Great to have module upgrade notifications in the core - thank you! Oops - not in the core, but thanks anyway

error_log won't send anything to the PW error log. They will go to the php error log. If you are using commercial hosting with cpanel there should be an error log you can view. If you are running a setup on a Mac, this command in terminal will get you the last 50 lines of your error log: tail -50 /var/log/apache2/error_log although it is possible the path may be different. If you bootstrap that file to PW you could also do one of the following (https://processwire.com/talk/topic/3768-processwire-dev-branch/#entry36787): $log->message("This saves this line to messages.txt"); $log->error("This saves this line to to errors.txt"); and those will send messages to /site/assets/logs/ Hope that helps.

This may not be an indicator - try: error_log('reponsive-images.php called'); and see if that appears in your php error log.

Does /mnt/sites/klauser-design.ch/web/pw/wire/modules/ exist on your server? If not, it looks like you didn't manage to get all files onto your server. Can you check that and get back to us?

This should get you going on the conversion if you decide to do that: https://processwire.com/talk/topic/6654-convert-repeater-to-pagetable/?p=65160 You can ignore the need for a title by making the title hidden and not required in the context of the pagetable template and setting a value for the automatic page name format when setting up the pagetable field.

Yeah, unfortunately I do know about this already - was just hoping it wouldn't come up I made an initial attempt to fix it, but couldn't figure out a solution at the time. Then the new PageTable field was developed which Ryan recommends over repeaters in almost all scenarios so I didn't worry about it too much. I'll take another look and see what I can do, but you really should try PageTables - so much nicer (and less problematic) than repeaters

Now that I am using a lot of PageTable content blocks, Changelog is becoming a little less useful in its current form. I would find it more useful if it could also show the parent page so I can tell what page the user has been editing. Thanks for considering.

I also just added another formatting option that allows you to include the current date time in the filename, eg: {$page->name}-[Y-m-d_H-i-s]-suffix Anything inside square brackets will be treated as a php date format string and will be applied to the date/time when the file is uploaded and renamed. You could instead use $page->created or $page->modified, but since these don't have a configurable output format, this seemed like a more flexible approach. I think this should be a useful addition in several scenarios.

I have just committed an update that makes this work as expected. Because in the admin panel outputformatting is off by default, it needed to be manually turned on. I don't think there should be a problems with doing this in Custom Upload Names and some quick testing shows that it seems to be working fine, but please let me know if you discover any weird side-effects.

Might be worth filing a bug on Github about this then to make sure Ryan sees it in a timely manner.

What version of PW are you running? I'd be curious to know if this is already fixed in dev.

I wouldn't blame your clients on this one - whenever I use the PageTable field I always use the "Select a parent for items" and use a hidden parent page that clients won't look in. I think using the default parent is very messy. I think PageTable is much cleaner than repeaters for lots of reasons and now with PageTableExtended, it's even better.

I say go for it - there is certainly no reason to not be running the dev version on a test/dev site right now and if you find no problems, switch the live whenever you are ready. Let me know how it goes - I think it would be nice to write up a tutorial for this when you're done to describe all the steps and any changes needed to the CSV importer to make it all work. I am actually tempted to build something specific to importing and emailing users, but maybe if we can have a clear step-by-step that will be fine too.

Completely agree with Pete - having an app that replicates the functionality of a website is sometimes what clients want, but it really makes no sense. Honestly I think a lot of apps out there would work just fine as responsive sites instead. That said, there are obviously great benefits to the app approach when appropriate and the functionality is targeted. One way to make the phonegap experience a little less daunting is to use "phonegap build" which allows you to avoid a lot of unpleasant steps, although the Apple provisioning stuff is still a PITA. You can't just convert a website with phonegap unless the site is very basic and non-interactive. Once the user has the ability to query a database of changing content, you need to provide a mechanism for that content to be pulled into the app. The css, html, and js files are installed to the device (via the phonegap process). The content can be a mix of static content as part of the html and then the dynamic stuff that is pulled from a database via ajax and usually JSON. For web developers with a strong jquery skillset, jquerymobile is an ok approach to get going, although it can quickly become a painful process and I don't think I'll do it again. There are a lot of other frameworks and tools out there that can help. One that I think is worth taking a serious look at is ionic (http://ionicframework.com/). It makes use of AngularJS which, once you get over the learning curve, gives a lot of power and the apps feel much more native than with jquerymobile. Google around for "mobile app html5 framework" to see what else is out there and looks like it will work for you. If you don't have strong javascript/ajax experience, it will be a struggle to get going as you need to rethink how things are done. Good luck!

Sorry, I built the module using the new .info.json file for describing the module info which requires PW 2.4.3+ Upgrading to PW dev will fix it - keep in mind that 2.5 stable is slated for late this week, early next week, so there will be minimal changes before official release now. If you don't want to do that, just let me know and I'll quickly put together a version that will work just fine with 2.4 stable. The modules directory needs a dev option or at least a 2.x where x is the version after the current stable so people know a modules requires the dev version.