adrian

I am noticing that some editors are forgetting, or not seeing that they have to publish the items/pages in a PageTable fields. I think in many/most cases you would want all published automatically. Or perhaps it could be an option for the field - the dev can decide whether editors can choose to save unpublished if they want. Alternatively I think it would at least be helpful if there were publish and hide toggles (like the new main page tree action buttons) so it is easy to quickly publish all subpages rather than opening each one up. I would prefer the first option though. Anyone else think this would be useful?

What a great comment!! I sometimes find myself apologizing for my PHP work also, but until someone can show me a system in a trendy/better language that is better than PW, it will always be my goto tool for web development. That doesn't mean I don't like playing with the new JS toys (node, meteor, angular, react) when the need arises, but PW makes everything so easy that I'd rather be here

Thanks Kongondo - the new custom PHP code option is awesome - I just swapped out my old hacked version for this and it's working brilliantly!

Most likely the image field is an array, not a single image - check that Details > Max Files Allowed is set to 1.

Can you give me a hint as to why it doesn't work with some of your websites? I know we had a PM thread in Jan of this year, but I never heard back from you. I would still like to help you figure out the problems you are having.

Thanks Bernhard - your module looks great. I also put together something for this task myself. I just added it to my gists: https://gist.github.com/adrianbj/5dc1c00f1617b2639319 It allows you to do something like this in a field's description or notes text: [Click Here]({page.parent.url}) This will give you a "Click Here" link to the parent page. Of course you can also use "name", "title", and any other field from the current page, or it's parent, or parent above that. I haven't needed it yet, but I was thinking it might be nice to be able to do {page[xxxx].parent.title} so you can specify the ID of the page you want to reference. Maybe at some point I'll add that, or if anyone out there would make use of it, let me know and I'll add it sooner. While not as flexible as your module, it requires no setup so it really depends on what you need.

Can the user with the uploader role that created the page edit it? By default PW doesn't distinguish permissions based on whether the user created the page or not - you actually need to add the new page-edit-created permission: https://processwire.com/api/user-access/permissions/#page-edit-created

Hi @matjazp - thanks for the request. Please try the latest version which should do what you need. If no templates are selected, then the module will still search all templates as before so the changes won't affect existing users.

You can set the id like this: $p = new Page(); $p->template = "basic-page"; $p->parent = 1; $p->title = "Page Title"; $p->id = 4254; $p->of(false); $p->save();

Hi Steve, I am sorry, I haven't had time to work on Migrator for a while now. It is definitely not abandoned - I just need to find a good chunk of time to revisit a few things regarding Page fields and sort out remaining bugs. I will try to take a look at this sometime soonish. Regarding the last part of your question - Migrator currently creates new users/roles if the creator/modifier of the imported content was created by a user that doesn't exist on the new site. The problem of course is migrating the user's password - is this a requirement in your scenario? All the template settings etc are all handled completely by Migrator. I also have some aspirations to take Migrator a step further and allow it to connect directly to another site and sync changes, but if this happens it will be some time away and will likely be a commercial version of Migrator. I am not sure if that really helps you at the moment. I am away for the next few days and busy for the week or so after that, but might see if I can get a new version out before the end of the month - but no promises

New update to support random images within RTE textarea fields. You can specify whether to include images, and the positions that they might be placed in. You can reload the page several times and the images will change positions/alignment randomly. I would very much like to hear suggestions from anyone using this if they have any ideas for improvements - do you want more configuration options - eg size of the embedded images, captions, etc?

Sounds like it might be a problem with your host. Have you used them on other non-Processwire projects before and not had any issues? Not sure if it is an automated thing, or a permissions problem with the owner and access setup and someone is maliciously modifying it. Have a read of this to learn what the settings should be: https://processwire.com/docs/security/file-permissions/

Hi @laufi and welcome to PW. I think you'll be able to fix the problem by modifying the sessionFingerprint setting: This will show you the options, but remember that you shouldn't modify anything in the wire folder, so adding the option to your site/config.php file. https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/config.php#L184 0 or false will definitely work, but you may want to try another option if suitable.

One small thing: http://jump-inc.uk/book-now/ See the small height difference in the purple bar - Chrome OSX

I haven't read this thoroughly, so likely missing the point, but what about using the alternate template filename option from the Files tab for each template?

I was confused with this in my early days of PW too Have a read through this thread and the pages that are linked to throughout it: https://processwire.com/talk/topic/4094-publishunpublish-a-page-setting-required-to-edit-published-pages/

Thanks for clarifying that. I just committed an updated that adds a new "Excluded Pages" option to the module's config section, so you can add as many pages to this as you want. Interestingly while testing, I noticed that for non-multilanguage sites you actually have to have the settings tab disabled to even get the name of the homepage to change with this module at all because in most cases it uses JS to change the name and the name field isn't available unless Settings is disabled. Anyway, please let me know if this new option takes care of things at your end.

If it wasn't for mobile app development I probably never would have made the switch to Mac, but now that I have, I probably won't go back, just because of the UNIX base and also because I am now comfortable with the toolset I am working with. That doesn't mean I am thrilled by Macs - in my mind they are just a different set of problems

Hi @gebeer - I can certainly add an option like that, but I am curious about the behavior you are seeing - is it a multi-language issue? When I change the title of the homepage, the path to it and all child pages does not change because the name of the home page is never used in the URL. Maybe I should add a checkbox to the Settings tab of all pages to disable name changes when checked?

Ryan has been notified of this thread, so hopefully he will be able to give you an answer shortly. Although I see that you mention "ImageExtra" - is the problem only related to sites with this module?

This seems to work on all inputfields for me: $this->addHookBefore('Inputfield::render', function($event) { $field = $event->object; $field->setAttribute('ng-model', $field->name); }); EDIT: Oops - well and truly beaten Can't afford to sidetracked in the middle of replying with when @LostKobrakai is online!

From your post it sounds to me like you are talking about migrating content from one PW site to another - is that correct? If so, it should simply be a matter of migrating template files and the DB. If however, you are talking about migrating a WP site to PW, we do have a migration tool: https://github.com/NicoKnoll/MigratorWordpress

Hi @mr-fan, I think those notices were just a side effect of upgrading from an older version of BCE, but regardless I just committed some changes that should fix them - thanks! Please let me know if you come across any others. PS - thanks for all your support for this module - both testing and promoting it in other threads!

I haven't used them, but is pwired maybe referring to CSS image filters: https://css-tricks.com/almanac/properties/f/filter/

Absolutely no apology necessary - I am honored that you featured it and completely agree that early attention and testing is a great benefit to myself and any potential users, so thank you for including it and for PW weekly and everything else you do for PW!