adrian

Just to throw an additional thought into the mix. I think this is a great addition, but in some cases I will still want to add an additional "published_date" field to my page. This would most likely be for printed documents where I am hosting a collection of PDF reports etc and where the date of publication may not match the day the item is published on a PW site, which is a very common scenario. I think "published_date" is distinct from published since the latter is a datetime field and for a printed doc PDF etc all you need is the date.

Migrator allows you to specify down to a single page to export and import if you want. So as long as the pages that your client is creating/editing are not also being changed on the live version, it should work just fine. This option was designed for exactly this purpose - it will export only those pages that have changed since the selectedd date/time. CAUTION: The migrator module has the potential to overwrite large amounts of content on the destination site so I recommend testing thoroughly with a test destination site first so you are comfortable with the changes that will be made based on the settings you have chosen. And when you do use on your live site, make full DB backup just before you import the content. Most importntly, let me know how it works out for you

Hi Key and welcome to the forums. Have you tried *= or %= in your selector? http://processwire.com/api/selectors/ As for your second question. You'd really be better off using a page field instead of the select fieldtype for this type of usage. It might seem tedious to set up at first, but gives you so much more flexibility. You might find this module useful for setting it up: http://modules.processwire.com/modules/process-page-field-select-creator/ Hope that helps.

You have me thinking - I bet I could have Migrator create these automatically, so long as the Redirects module is installed I'll look into it.

Thanks for this - looks great. What do you think about the situation where a page is published, then unpublished, and then published again. I think your current behaviour is probably fine, but just wanted to see if anyone else has any thoughts on whether the initial date should be preserved or not? What about including a published_users_id as well? This actually brings me back to Nico's suggestion of calling the field "published". That way we'd have: created created_users_id modified modified_users_id published published_users_id Actually, any thoughts about whether it would be better to extend the pages database table to include these fields directly, rather than as separate custom fields? Maybe that's not a good idea for some reason I haven't thought of yet - anyone have any thoughts on this?

Here is Ryan's initial post about the feature: https://processwire.com/talk/topic/3768-processwire-dev-branch/page-9#entry58107

This sounds like a very easy thing to implement using the PW API. Do you want to log all the pages the logged in user visits, or just monitor one particular page? You could certainly make use of Profields table to create a user visit log. In fact I use it already for a similar purpose. Hopefully this will get you going. This assumes you have a page called visits and a Table field called visit_log with table sub-fields called date, user_id, and page_id $visits = wire('pages')->get("/visits/"); $visits->of(false); $visit = $visits->visit_log->makeBlankItem(); $visit->date = date("Y-m-d"); $visit->user_id = $user->id; $visit->page_id = $page->id; $visits->visit_log->add($visit); $visits->save("visit_log"); PS You might want to make this Table field not editable (locked), or maybe even hidden from the editor as it will likely become extremely long and might have issues when displayed in the PW admin. Something else to think about - you could add this field to a site-wide "visits" page like in my example, or have it attached to every page of interest on the site and then you wouldn't need the page_id subfield.

The strikethrough suggests that the page is unpublished. Is that the case, or do you think it is just due to the missing title?

@everfreecreative, This has been in the dev branch for a while now: https://processwire.com/talk/topic/3768-processwire-dev-branch/?p=58107 Does that take care of the functionality you are looking for?

Hi davo, Do you want $user->hasRole or $u->hasRole ? It looks like you are redirecting to the agent-portal page if the user is logged in already and the hasRole check is for the user you are logging in via the posted username and password, which is for $u

teppo deserves an extra like for mentioning that new functionality in the dev version. Here's a screenshot of how it looks:

Looks fine here on Mac FF 30 and 32. Might be a CSS cache issue?

Hi Yannick, I am sure others will chime in, but I don't see why this is easier than: $page->image->first(); $page->image->last(); $page->image->eq(n); Are you suggesting your approach over these options, or were you simply not aware of them? EDIT: Sorry, I see that you have been around on the forums for more than six months, so I am sure you do know about first, last, eq, and you're even using eq in your method. Sorry about that

Hi everyone, Added some major new functionality to the edit mode today (see revised screenshot for 3. in the first post). Edit mode now includes quick addition, sorting, and deleting of pages as well as full editing via a modal popup editor, similar to the new PageTable interface, making use of MarkupAdminDataTable. If you are using this, definitely worth updating, and if you're not using it, maybe it is now worth taking a look Enable this on your home template and you have a powerful editing alternative with the added ability to automatically overwrite page names based on changed page titles, which I think is very handy during the development phase of a new site. Please let me know if you find any bugs with this new version.

Sorry for the constant updates Definitely recommended to update to the latest version as it adds better handling for users without profile-edit permission. As well as the warning, it now also unchecks the force password change checkbox if the user doesn't have profile-edit permission The Set All Users role selection is now limited to only those roles with profile-edit permission Hopefully that will be all the changes for a while, unless someone has any suggestions.

Hi bryslon and welcome to PW. That is quite a detailed question but I thought I'd hopefully give you a few snippets to get started. Creating front-end forms: https://processwire.com/talk/topic/2089-create-simple-forms-using-api/ That is a great thread that should get you going. You can have your form submission create the new page and then limit the viewing of this page to users with specific roles. For the job tasks I would make use of PW's Page Fieldtype which is incredibly powerful: http://processwire.com/videos/page-fieldtype/ I would suggest your jobs parent parent page contain the form for submitting a new job, as well as the ability to search through jobs. This page might have a template: "jobs". The child pages would be created by the form submission, possibly set to unpublished until verified by an admin. The template for these pages might be: "job" I have done something quite similar before - it will be a bit of a learning curve the first time, but the PW API definitely has everything to you need to build this robustly. Not sure if that is much help, but hopefully it will get you started and you can come back to us with more specific questions as you get further into it.

Sorry, yes that setting should also be able to go in an htaccess file. I have gotten in the habit of using the config file sometimes for these sorts of things, so wasn't thinking. I adjusted the post above to reflect that.

Well allow_url_fopen can only be set in the php.ini file (or your apache conf file). Take a look at this list which can come in very handy: http://docs.php.net/manual/en/ini.list.php While there is some risk in having this enabled, I'd say that it is a pretty common requirement to have this available, so I wouldn't worry too much about it. If you're really concerned, it is possible to enable it via your apache conf / htaccess file instead and that way you can limit it to specific directories, eg: <Directory /var/www/wire> php_admin_flag allow_url_fopen on </Directory> You could even limit it to a specific file if you wanted, but I wouldn't get too carried away. I'd be curious to know whether your host also blocks curl and file_get_contents and whether Ryan could implement (if it isn't already in there) an alternative using these. Maybe others will chime in with their opinions too.

The exact required mod (eg 755) permission is not possible to determine without knowing the user/group of the owner of the directory/file and also the apache user. Usually 755 is sufficient for directories in most web server setups, but if you tested with 777 then that should rule out any owner issues. Debug mode usually gives you more verbose error messages right in line where you are running things, but the error log is found under site/assets/logs/errors.txt - let us know if anything shows up there. I don't think this is related to your Pixlr issue as they were saving, just with a new name - correct? I wonder if the module download issue is due to the server not having file_get_contents or allow_url_fopen available? I haven't investigated properly to se how well the modules downloader checks for and reports if these are missing. Have you tried with Soma's Modules Manager to see if it works? Also, what version of PW?

Another bug fix and enhancement just committed. There is now a batch "Set All Users" option which allows you to easily force existing users to change their password. Selection of users is possible via roles so you can limit the enforcement to just specific roles, or all if needed. If you mess up, there is also a simple way to clear the requirement for everyone as well. This addition was in response to teppo's comment in his ProcessWire Weekly post: "easily forcing periodic password changes for users" - now it really is easy to force periodic changes, so thanks for the suggestion The bug fix is for PW sites installed in a subdirectory - thanks also to teppo for reporting this.

Is your modules directory writeable? Try turning on debug mode and see if there is a more informative error message.

What about this: $np = $pages->clone($page); $np->of(false); $np->title = 'New Page'; $np->name = 'newpage'; $np->save();

Great - let me know how it goes for you. Thanks for the inspiration for putting it together!

The selector for counting would look like this: images.count>11

@jeve, Thanks for posting the full code. I can't see anything in there that looks like it might be causing the issues you are having, although you might want to sanitize that $_GET I am curious if it ever works if you are logged out - ie are these pages all visible to guest users? Also don't forget to less us know the PW,PHP, and MySQL versions that you are running.