adrian

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.

PS I would recommend also installing: http://modules.processwire.com/modules/password-force-change/ This way the user will be required to change their automatically generated temp password when they first sign in. Make sure the role that you assign to each new user has edit-profile permission otherwise they won't be able to change their password!

Great! I thought I did exactly the same - oh well so long as you have it working I'd say install my module, run a test import of a few dummy users, all with your email address to make sure it works as expected, and then you should be good to go. I am heading out now for a bit but will get back to you later if you report any problems.

Well I just did some quick testing and things seem to work perfectly with all the emails being sent as soon as the CSV import is completed. The only problem I noticed is getting the password into the email. If you don't populate the password via the CSV, and use the automatic password generation feature of my module, then it all works, but if you populate the email from the CSV, then my module doesn't have access to the password. Do the users already know their passwords? Could you use the automatic generation instead? Let me know if you do need to import the passwords and I'll see what I can do about getting my module to grab these a different way - apparently the InputfieldPassword::processInput hook doesn't work in this situation. The only other problem I noticed with the actual import was that I couldn't get the oles field to populate even though I added FieldtypePage to the array. Did the roles import work for you?

Hey Nico, Just wondering about the module version check component of this - firstly I love it, but two questions: How can you refresh the status on command? From a quick glance at the code, I think it is a timed cache? Why are all the core modules included? Surely they are not really relevant since they are relative to the version of PW you are running and would all have the same status? Maybe I am missing something? Thanks again all those involved in this!

Sorry - I didn't your original post completely and so missed the multilanguage issues. Ignoring the option for an external address for the moment, using the Pagefield approach would allow this: echo "<a href='{$page->linked_page->url}' class='button'>{$page->linked_page->title}</a>"; I don't know much about multilanguage things, but wouldn't that use the title for the currently selected language on the front-end? Back to the custom external address option - given the multilanguage needs, perhaps the new PageTable field (in the dev version of PW which will be released as stable 2.5 in the next week) could help you out - could you make use of a multilanguage title field and a url field. Maybe a simpler approach since I think you only want one button per page would be to use a Pagefield with the PageListSelect+ option, but if that is left blank, provide a text url field so they can enter an external link. Then for the button labels you could use a textarea field like this: english: Link spanish: Viniculo etc Then you could parse the textarea for the appropriate language and display that on the button. Another possibility might be the Multiplier field (also linked from the PageTable field link above) and use that to add a label for each language. Lots of options - maybe see if one of them sounds good to you and we can help you implement it.

Hi John - thanks for your input here. Sorry, but I have removed the link you included for the moment as the OP was not looking for logo design services. Indeed you could just copy the PNG from the site's banner, but it is definitely nice to have an SVG/EPS or other vector version of the logo so that it can be resized.

Hey Nico - Awesome you have those available there, but the download link for the plain mark is missing.

There are a few reasons why the sql files might be different, for example some can be very verbose with comments etc. Your simplest option might be to open them in a text editor and do a CTRL+F for CREATE TABLE and see how many matches there are. You could try again for INSERT INTO etc. I think in the end testing them might be the only way to be sure if they both work the same. If you are just looking to backup the database from a PW site, Ryan has a new DB backup feature in PW 2.5, so you could just use that

If you want your editors to be able to insert the button in a textarea field, your simplest option might be a Hanna code so your editors could do something like: [[button label="Click Here" link="http://www.mysite.com/mypage"]] Otherwise you could have a button created to an internal page by providing them with a Pagefield called "linked_page" and set the input field type to PageListSelect+ Then in your template file use the following code: echo "<a href='{$page->linked_page->url}' class='button'>Default Button</a>";

Just wanted to let everyone know that I finally got around to implementing netcarver's suggestions! You can now choose to override the parent and child template names from two collapsed fields. If left blank, behavior is as previously - they will be named based on the field name and the suffix supplied in the module config settings. You can now optionally define the field type when using Option 2, eg: Title, Number of Beds>Integer, Number of People>Integer, Kitchen Facilities>Text Single, 1, 1, Fridge Only Double, 2, 2, Fridge Only Suite, 3, 6, Full Kitchen Please let me know how this new functionality works out for you - I am hoping that now there will be no reasons to ever create a Page field setup manually, but let me know if I have missed something that anyone still needs.

Hi David, There is definitely the possibility to do this, but depending on how you are doing the import I might need to tweak some things for you because the module is currently restricted to the admin template only. I did a test with creating a user via the API and the everything works as expected, so we should be good there. How are you planning on importing? I tried Ryan's CSV importer, but it doesn't look like it will work for creating users because it doesn't have access to the name field of a page. Instead it uses the title, but user pages don't have a title field, so not sure how you could make it work. Also the issue of assigning roles to the imported users - again another strike for the CSV importer. So I think you'll need to write your own CSV import / user creation script - which should be fairly easy to do. So anyway, once you have that up and running, let me know the exact mechanism and I'll do whatever might be needed to make this module play nicely for you. It should also work well with the automatic password generation and combined with Force Password Change (http://modules.processwire.com/modules/password-force-change/) you should have a pretty easy method of setting up a large number of new users. Anyway, let me know what you need.

Hi gim and welcome to PW - first things first - anything is possible in PW No seriously - with some basic PHP skills, and maybe a little help from the forum, you really can achieve whatever you need. Just to clarify - do you want the site editors to be able to define the URL to an image that is on the third party site, or is this a one of hardcoded image? Let me know and I'll give you some appropriate solutions.

Hey Soma - this is definitely one of my standard modules for any new site, but was wondering if you'd consider one small enhancement that allows superusers to still see all the fields when using the hard lock option. Perhaps by disabling all form elements and removing the submit buttons? The one thing to consider is making sure that the superuser's access to the page doesn't prevent the normal user from continuing their editing of the page. As it is at the moment it is hard to help someone with an editing question when you can't see what they are editing

Just another alternative - you could embed the font using base64: http://sosweetcreative.com/2613/font-face-and-base64-data-uri I haven't tried this method yet, but have heard great things about it, so is on my list to try out.

I was seeing the same thing. I went in to the two .module files and changed the version numbers from "010" to "10" and refreshed the modules list and voila. Not sure if that really was the issue, but it worked for me. Ryan mentions this: "The module version number shouldn't have preceding zeros, as this starts PHP thinking it's an octal number or something else (I don't recall). So version number should be 10 rather than 010." PS The module files were actually already the correct version - just the reporting that was off.

No need to wait - just start using 2.5 now - lots of us are using it in production: https://github.com/ryancramerdesign/ProcessWire/tree/dev

Just tried again without VPN and it downloaded in 12 seconds and no problem unzipping this time!

Hey Ryan - looks great. A couple of comments so far - I think there really needs to be some kind of progress indicator (real or fake) because that download takes quite a while on slow connections - I was on a work VPN when I tested and it was several minutes. Also when I when to install (http://pwtest.dev/admin/setup/core-upgrade/prepare), I got a: Unable to open ZIP file, error code: 19 The dev.zip (15.4MB) exists in ProcessWireUpgrade, but it is corrupt. I feel like I have had this issue with something else PW recently too - can't remember what the issue is off the top of my head though.

Yep - I obviously didn't worry about that issue at the moment - just wanted to get you going with changing the actions. Hopefully you can figure it out from here, but if not, post all your code so we can take a proper look.

Just wanted to note that I had this same error again, this time with a PageTableExtended field. Restarting APC fixed things again. I'll keep a eye on things and see if I can find something reproducible.

Try the attached module - works here. Let me know if that works at your end. CustomPageListButtons.module

I haven't looked to see if it's possible or not, but I wouldn't want to hide it for admin users, just for front-end users using your profile edit approach, so not sure that option would be much help anyway. Just thinking through scenarios here - not meaning to pull apart your ideas

Hi kixe, Seems like a cool approach to things, but I just did a little testing and am having some issues - maybe you made some changes to your code just before posting. Firstly, you need wire('config') because it's inside a function. It can't get the root url the way you have it. $event->return = wire('config')->urls->root; Also, the redirect still happens with the code you have. If I change it to a "before" hook it doesn't redirect, but you are stuck with the "Continue" link on the page. Looking at the edit Profile option - not sure I'd want any front-end only users to have the options to change the admin theme, which will show up in that form if you have more than one installed. It won't be relevant to them and just confusing. It might seem like more work, but there are simple ways to create your own custom login and profile edit form with not too much code. I have based most of mine off this post by Ryan: https://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/?p=15919

Hey Nico - I just submitted a PR to fix the uninstall problem: https://github.com/NicoKnoll/ProcessPageDelete/pull/11 Just a matter of adding an "include=hidden" when looking for the page. I guess this is a fairly new issue from when you added the hidden status to the page when Ryan added the new "Tree/Find" submenus to the admin.