adrian

Just make sure you run Modules > Refresh after renaming and they will work again. The reason I think it's important is so that you can use the Upgrades module to upgrade all your modules to new versions easily. And in future if you install using the ClassName or the zip (via URL or upload), then you won't ever have to deal with the "-master".

I just committed a new version - it now ignores pages under admin and trash. Before it just excluded pages with the "admin" template. I think this should take care of the problem with WireQueue. I also fixed a bug with images being blank in RTEs when you haven't manually specified the max number of images for the images field that is used.

First question - how are you going to handle the editing? The pub/unpub/trash are easy, but if editing you need to figure out if they will get a modal popup for editing there, or if they will be redirected to the admin for this. You might want to take a look at these modules: http://modules.processwire.com/modules/front-end-edit-lightbox/ http://modules.processwire.com/modules/fredi/ As for the pub/unpub/trash - there are a few ways to tackle this - I think the first thing you need to decide on is whether you want it done via ajax, or whether a page reload is acceptable. If the latter, then you can simply have a link like: http://mysite.com/change-status/?pid=1001&change=trash The template file for the change-status page would contain something like this: if($user->hasRole("required-role")) { $p = $pages->get((int) $input->get->pid); if($p->id) { if($input->get->change == 'trash') { $p->trash(); } else { if($input->get->change == 'unpublish') { $p->addStatus(Page::statusUnpublished); } elseif($input->get->change == 'publish') { $p->removeStatus(Page::statusUnpublished); } $p->save(); } } } Then you'd want to redirect back to the main dashboard page using $session->redirect() Personally I'd prefer an AJAX approach. I would make use of jquery for this and call the above page via: $('#trash').click(function(){ $.get( '/change-status', function( data ) { //code to update status in dashboard Of course there is more to it than that, but maybe you already know your way around jquery and ajax so I'll leave you to figure that bit out.

Sorry, it just occurred to me that that was a rather useless answer You'll probably want to make use of the API and do something like this: $p = $pages->get("page to alter"); $p->addStatus(Page::statusUnpublished); $p->save(); You could put this inside a conditional that checks that the user has the correct role/permission. You may also want to do it based on the passing of a get or post variable so it can be part of your existing template file. Hopefully that will get you started but let us know if you have any specific implementation questions.

It sounds like you are assuming that the file compiler works like a cache converting the values of these variables into hard values at the time of compilation? As LK and ryan mention, this is not the case - the file compiler is really just for dealing with Namespace issues (although it can be used for other things like tags compiling). The key thing is that the resulting file is still all php with variables intact.

@shamus - sorry for the delay in getting back to you - I have made a start on investigating this and improving the importing in general - stay tuned! @Robin S - I posted about this here: https://processwire.com/talk/topic/10517-frontend-password-reset/?p=119386 - it's a bug in the Password Reset module, but I have implemented a check in BCE that will prevent the error - instructions on how to implement are also in that thread.

The unknown template error is due to a bug in the settings for the password-reset template. 67 password-reset 121 0 0 {"childTemplates":[120] There is no template with an id of 120 in my system. 120 refers to the fieldgroup for the password-reset-request template, rather than the id of that template itself. This is the culprit: https://github.com/plauclair/PasswordReset/blob/master/PasswordReset.module#L279 That said, I have added an additional check to BatchChildEditor so the error won't occur. I am currently working on some other changes to BCE so I won't commit this fix just yet, but you can do it yourself by changing: https://github.com/adrianbj/BatchChildEditor/blob/master/BatchChildEditor.module#L711 if(!$this->isAllowedTemplateAdd($templateId, $pp)) continue; to: if(!$t->id || !$this->isAllowedTemplateAdd($t, $pp)) continue;

Did you test AdminRestrictBranch with 2.4 or are you just basing it on what it says in the modules directory? If you did test and got an error, could you post for me - maybe it will be an easy fix - no promises - I don't want to spend a lot of time making it work with such an old version of PW, but if I can help, I will.

Take a look at the links for the action buttons in the admin. To unpublish for example, looks like: http://pw.dev/processwire/page/?action=unpub&id=1005 Presumably the users with access to these links will be logged in and their role will have permission to perform these actions?

The setTimeout method wasn't added to WireHttp until PW 2.5: https://github.com/ryancramerdesign/ProcessWire/commit/c06209b4e03036cf0026b57c6015192dc61c936d#diff-1972780faf7a13076c1284fbb478144a so I believe Ryan mistakenly added 2.3 and 2.4 to the list of compatible versions. But why not upgrade to 2.7 - 2.4 is very old now - so many amazing new features to make use of.

If you already have HannaCode installed, you can use that to run code in the backend easily using the Test option. If not, then you can place it into an existing template file. If it's a live site then maybe wrap it in: if($user->isSuperuser()) { so that it only happens once when you visit the page with the template. I would also recommend testing that code of mine on a dev/testing site first. I adapted it quickly from https://processwire.com/talk/topic/6654-convert-repeater-to-pagetable/ - I think it should be fine - looks good, but always worth a double check before running something like this on a live site.

$rf = "repeater_field"; //repeater field name $pt = "basic-page"; //page template name foreach($p->$rf as $r){ $np = new Page(); $np->of(false); $np->template = $pt; $np->parent = $page; foreach($r->fields as $f){ $np->$f = $r->$f; } $np->save(); }

That make sense, but here's another scenario for you. What if the dev sets the maxFiles to 3 and the Which Images to All Available. And it is attached to a textarea field where they can enter multiple videos - what images get kept, and which ones get deleted when additional video links are added? Obviously it would be a silly combination to set up, but you never know. At least the way it is now if you want just one video per page you can use a text field (not textarea) and choose First Available. That way you'll only ever get one image - the only caveat is that you need to do $page->images->first(). If you want the manual upload override you can have a separate field, or you could tell the site editors to simply order the images field so that their manually uploaded one is in first position. Or, the template logic could look for the presence of an image without the "video-" prefix and use that if it exists? I am still not convinced I am right, so I would still like to hear from other users of this module! Thanks for your continued thoughts on this!

I think you are looking for getForPage(): https://github.com/ryancramerdesign/ProcessWire/blob/7e8c7c6836282b6b64de81263f5aaa8112fd51ae/wire/modules/Fieldtype/FieldtypeRepeater/RepeaterPage.php#L46

Hey Steve - thanks for your interest in this module and thanks for figuring out the issues with WireQueue - as you mention it will probably happen with others too so I need a way to exclude as necessary, or maybe it can be automatically dealt with - I'll take a look. The one main issue still remaining with this module is the slowdown when a template includes page fields - at the moment the module generates content for all fields from the templates of these page fields - this can take some time. I need to figure out a better way to do this. Connected to this is the delay from calling the http://loripsum.net API. Even though I make use of Faker locally for most things, the RTE fields still use http://loripsum.net because of their random text/image options. I would like to recreate this functionality directly with the Faker API as it would make it much quicker. Otherwise I think it is working well, although I would still like to add support for Profields etc.

Thanks - yeah, it is certainly doable, but the problem I see is that if the dev sets the max to 1 and doesn't prevent users from manually uploading an image, and this modules works like PW in that a single image is replaced if the max is one, then manually uploaded image will be lost. So it doesn't work for the scenario where you want the user to be able to override the default image from Youtube/Vimeo. I think it's better in that scenario to have a dedicated "manual override" image field - at least that is my current thinking. Is there anyone else there with any thoughts on this? I'd like to get a consensus before I go making anymore changes.

https://github.com/ryancramerdesign/ProcessWire/issues/1803 Will see what Ryan has to say.

Try looking at the Network tab (make sure it is open before you upload the image). You should end up with a line that has an error - that will be the PHP error that will give you the info to figure out what is wrong. The error you are seeing in the console is a syntax error because the ajax call is returning the real error. My initial guess would be file/folder permissions, but if you let us know the error, we should be able to figure things out.

Take a look at this post by soma: https://processwire.com/talk/topic/4530-how-to-get-a-list-of-all-pages-recursiv-without-admin-pages/?p=44508

Just added a new "Core Classes" section to the debug panel - so now you have really quick access to the new 3.x API ref docs for all the core classes.

You might find wireSendFile with the forceDownload option useful: https://github.com/ryancramerdesign/ProcessWire/blob/7e8c7c6836282b6b64de81263f5aaa8112fd51ae/wire/core/Functions.php#L521

Just so you know - you should probably use: $config->adminRootPageID because it is possible for it not to be 2.

Hi everyone, A few commits today to improve a few things. You can now choose the branch of the Tracy core from the modules config settings. It defaults to the master (dev) version if you have PHP 5.4.4+, but now if you have having the slow rendering of the debugger bar (mentioned by @tpr above), you can easily choose to load the stable branch instead. Hopefully the Tracy folks will fix this and if they do, I'll likely remove this setting in the future. There is now better panel resizing and scrolling of internal content - this is especially handy with large panels when you have the dev console open on the bottom. Probably still not perfect, but should be much better. Actually I think the Tracy core needs some work to make this even better. Performance Panel now has internal scrolling - this was absent before. Enhancements to the Debug Mode panel, including linking of the API variables to the new PW 3.x API Reference docs.

@Robin S, Sorry for the delay on this - partly no time, and partly not sure what to do. That bug you noted at the end there is new since I added checks to prevent extra images being added to an image field with MaxFiles not set to '0'. I am actually thinking that the easiest and best solution is to simply require that the image field that is selected for this module has a maxFiles set to '0'. My reasoning is that there are three scenarios where you might end up with more than one image in the field. 1. You allow users to manually upload other images to that field 2. You are using a textarea field where they can enter multiple video links 3. You have chose "All Available" for the thumbnails to be grabbed There are also combinations of the above. I don't see a simple, logical way to make this work without the potential for losing images if I continue to allow a single image field and overwrite existing images. I have gone ahead and made these changes - hopefully it won't impact your (or anyone else's) use cases. Please let me know if you have any problems with this new version.

Sorry for the delay - got distracted by other things. Please check out the latest version - as I mentioned, you can now match a user to the homepage so they'll have access to the entire tree.