adrian

@Soma - just wanted to let you know that I have made more changes to @owzim's script. The new version adds this functionality adds dynamically added hooks like Page::viewable which were not previously detected cleans up code within a function when it's on the same line as the function definition, eg. https://github.com/processwire/processwire/blob/35df716082b779de0e53a3fcf7996403c49c9f8a/wire/core/NullPage.php#L112 removes any comments from the returned info - previously if a comment was on the same line as the function definition it would be returned also. You can see my changes here: https://github.com/adrianbj/TracyDebugger/blob/master/panels/CaptainHook/CaptainHookSearch.php Let me know if you have any questions.

Hi all! Major overhaul / refactor just committed. To quote Github: Showing 54 changed files with 1,705 additions and 1,295 deletions. Yes, I haven't slept much lately I have tried to test everything very thoroughly, but with so many changes, there might be new bugs introduced. Please let me know if you find any issues. You'll also noticed that I have bumped the version number to 4.0.0 and am using a string now so that I can start being more semantic with the version numbers. Here's a rough highlight of the changes. New skin - a huge thanks to @tpr for all his efforts on this, not to mention lots of other feedback / bug reports while developing this new version! Captain Hook Improvements - it now shows dynamically added hooks, like Page::viewable in both the core and your site module. Also some general cleanup. More SessionHandlerDB fixes - there were still some outstanding issues with some of the lesser used panels. Hopefully we're closer to this being a non-issue. Improved CSS loading - in particular when opening panels in a popup window. General code updates - various things, including updating wire() and $this calls to $this->wire() where appropriate. Lots of bug fixes - mostly issues with the lesser used panels that had gone unnoticed, but still it's amazing what you find when you do a major refactor. Better code documentation - not my strong point in the past - hopefully this is now on the way to being much better. File / folder restructuring - not really of concern to you guys, but will make life a little easier for me going forward with future enhancements. Captain Hook panel showing new dynamic hookable methods and @tpr's fantastic new skin!

But what file were those line in?

How exactly did you solve it? I'd like to know why those other lines were there in the first place.

If you are trying to get to 3.0.42, then there should be no need to bother with 2.8 (it's a legacy version). I would go straight from 2.7 to 3.0.42.

Hi @DZuz14 - welcome to the wonderful world of PW, the anti WP CkEditor is built in to PW - you just need to choose CkEditor here from the Inputfield Type on the Details tab of your textarea field. Hope that helps!

@blynx - FYI that is because of the way you have declared the version number: 033 Either use: 33 or '0.3.3'

Isn't this a good use of @kongondo's Matrix fieldtype ?

Yeah, I am not surprised those links don't work in the version of the module I posted for you - it is looking for url segments that don't exist. This is why I need to make looking for segments optional. As for the actual Shortlinks tab - I think it's probably time I got rid of that - I don't really think it serves a purpose - any thoughts?

No problem - don't forget to watch out for upgrades to the module Btw, another approach to I think what you are looking for: Currently it only works when the children and direct child pages, but it would be easy to customize to a different branch parent. Maybe you prefer the approach you have and I think I agree with you for your use case, but this is just another option, maybe for a different project.

That shouldn't be hard, but what about just hiding the Children tab altogether using this module: http://modules.processwire.com/modules/restrict-tab-view/

@Tyssen - I definitely agree with @fbg13 here - it looks like @flydev is doing an awesome job with his upcoming module. I would hold out for that, rather than fixing an old module with much less functionality.

Maybe you should do a full mysqldump and do a search/replace in your code editor and import everything back in - should be much quicker given all those variations.

Nice work Or you could try out the new version of the module which adds support in the config settings for restricting by template(s)

Yeah, I think that should work. The default language should be stored in the main "data" field.

Can't really help without knowing exactly how you did the hiding

Currently no, the module is designed for site-wide use, but you could extend it to have a template selector in the module config, or just steal the relevant code from the module and add it as a hook in your /site/ready.php file.

Sorry, I meant "new" whenever I wrote "edit". I spaced for a minute there This starts getting a little more complicated. Have a read here: You can probably cobble something together from that thread and some of my linked gists.

Just be aware that this doesn't prevent someone from editing it if they manually enter the edit url. To prevent that you would need to hook into: Page::editable, but keep in mind that this will cause problems with the PageTable field being able to edit this pages (unless you also account for that), so I think what you have is likely the best compromise.

No problem - just wanted to see if there was a reason not to use it. Ok, I guess there must be instances outside of the link where example.com exists and you don't want to replace - sorry I wasn't aware of that.

Yeah it doesn't sound like a repeater would be a good fit at all. So yes, you will need 7 input fields to make this work.

What's wrong my that SQL statement above - it will replace the contents of the field for all pages on the site, but isn't that what you want? Again, you shouldn't need a regex for the AdminActions module - I tested with "example.com" and "example.ch" and it worked fine (obviously for normal fields, not repeater sub fields).

This may be what you are looking for: https://processwire.com/api/modules/profields/textareas/ Ignore the name of the fieldtype - it's not very descriptive of what it actually does.

Yes - if you need to limit by pages, then you'll need a WHERE addition to the statement to check the pages_id - this could start getting complicated. You may need to build up an array of IDs of pages that match. I guess the question is how many pages do you need to make this change on? Would manually doing it be easier at this point?

You'll either need a separate field, or make use of a repeater field