adrian
-
Posts
10,912 -
Joined
-
Last visited
-
Days Won
349
Everything posted by adrian
-
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
-
Yeah, it won't work with repeater fields because it won't target the repeater first and then it's subfield. I will need to make some changed to make it work with repeaters. You're best bet for the moment will be to go with raw SQL, eg: UPDATE field_body SET data = REPLACE(data, 'example.com','example.ch'); You may need to do this for each multilanguage version of "data", eg "data1812" etc. PS, this assumes that the name of the field is "body", which is stored in the "field_body" db table. PPS - be sure you backup your db before running this
-
Something like this in your /site/init.php $this->addHookAfter('ProcessPageListActions::getActions', null, function(HookEvent $event) { $p = $event->arguments[0]; $actions = $event->return; if($p->template->name == 'aaa') { unset($actions['edit']); } $event->return = $actions; }); Just replace the $p->template->name with your condition - whether it's a real template name, or change to $p->parent->id to get the parent of the page table items - whatever works best for you.
-
Another quick update. Both the new "Copy Repeater Items To Other Page" and "Copy Table Field Rows To Other Page" actions now include an optional selector so you can define what repeater items / table rows will be copied.
-
Problem: saving repeater item from one page to another
adrian replied to theoretic's topic in General Support
@theoretic - I just posted an update to the new action - it now allows you to define a selector to limit to the matching repeater items, so you could theoretically now use the action via the API, but probably no point now that you have your code working. -
Yes - so it's only an option if you don't want the pages accessible directly, which is usually (although not always) the case with PageTable child pages.
