adrian

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.

Or here: Check out the drop down at the top right which allows you to choose the template which the settings will be applied to.

Nico - one thing I did notice is that if you uninstall the module and go to reinstall you get an integrity violation. At least for me, the Delete page that is added during install is not being removed properly, so when it goes to add it again, that causes the error. If I manually delete the page, then the re-install works fine. I haven't tested thoroughly and just heading out for the day, but might be something you can look into.

What happens if you use: https://github.com/NicoKnoll/ProcessPageDelete/archive/master.zip in the new "Add Module from URL" option?

Check out this helper module from Soma: https://processwire.com/talk/topic/3159-hide-settings-tab-in-page-edition/?p=31126

Works great for me on 2.4.18 Sounds like kixe and mr-fam are actually having issues with it working on 2.4 stable. Maybe you guys could try an older version from Github. I thought it might be related to the autoload condition that was added a while back, but then the delete button wouldn't show either, so not sure. Not sure that it is worth Nico messing around too much though since 2.5 is only a week or so away

No need to remove it from the template, just make it hidden and not required in the context of that template. I don't think there is really any need to populate it all in this case, but it would be possible via a hook if you really want to. You could also remove the global flag for title so it is not in the template at all, but I think the former approach is better.

"Using $form->processInput($input->post) will prevent CSRF attacks and the form will append a hidden field automatically." https://processwire.com/talk/topic/2089-create-simple-forms-using-api/

It's on the Input tab of the PageTable field. I usually just name it contentblock or something along those lines and each new page that is created with have -n appended to it, e.g.: content block-1, contentblock-2, etc

1) a) I think the best approach is to store all the content pages under one hidden parent using the Details > Select a Parent for Items b) Not really an issue if you do a) c) Make use of Input > Automatic Page Name Format, and then go to the template context settings for the title field and make it invisible and not required. 2) This can be handled by setting the allowed parents for these content block templates. Hope that helps.

PageTable is in the core already - you just need to go to Modules > Core and scroll down to PageTable and install. Then it will appear from the list when creating a new field.

Here's a starting point: https://processwire.com/talk/topic/960-comment-spam-filtering-alternatives/?p=8097 But there are other links on how to do this in the forum as well.

Hey Zahari, In a bit of a rush, but PHP's strstr might be what you are looking for. Not sure that you really need a Hanna Code in this situation. Just parse the content of the field in your template. $introtext = strstr($page->body, '[[readmore]]', true); Then when you echo out the body on the full version, just: echo str_replace("[[readmore]]", "", $page->body); Hope that helps to get you started. I am sure there are lots of other ways to approach this. I usually go with automatic truncation because editors usually forget to add things like a [[readmore]] tag.

Exactly my point (maybe I wasn't clear) - use a commonly used CDN like google, rather than github, which is rarely used for this purpose (especially when linking to a version in the PW repo).

Ryan has been alerted to this post, so hopefully you should hear from him soon.

I think the problem with that approach is that you won't get the local caching benefit of using the Google CDN, because no other visitors to your site will have those files cached from the PW git repo. I would suggest either using a well known CDN (eg google), or use the local version from your PW install - afterall, those files are already on your server. I would however use the excellent AIOM module on them. I am no expert in this area, but hope that helps.

This works for me. This replaces all the existing buttons and adds a new one called "custom". Is that what you are looking for? public function init () { parent::init(); wire()->addHookAfter("ProcessPageListRender::getPageActions", function($event) { // anonymous function $event->replace = true; $new_action = array( 'cn' => 'custom', 'name' => 'Custom', 'url' => '/my/path' ); $event->return = $new_action; }); }