adrian

I agree, but I use grey to indicate a hidden page (and strikethrough for unpublished). I know they aren't essential because of the hidden and unpublished checkbox columns, but it's still a nice familiar visual indicator. Any thoughts? I don't know how given that the modal edit icon has no link, but rather a data-url attribute. Are you sure this works for you? Seems like a great idea - thanks!

Hey @tpr - I have made an initial (although took much longer than I thought) start on support multi-language in Edit mode. Keep in mind that this is not designed to make it possible to edit all languages at once, but rather add proper support for editing the title and name for the user's current language. Here you can see the same set of child pages in Portuguese and then the default English. The keys things are: When viewing a non-default language the Title and Name columns have the current language in parentheses. Title is left blank for the current language if no language-specific version is available (uses "Placeholder" to show default language title). Name is left blank for the current language if no language-specific version is available. If you have the BCE "Overwrite Names" setting checked, the name for the current language will be created/updated to match the entered title. If you edit the page in a modal and save, the title and name for the current language will populate the edit mode interface instantly when modal is closed. Unrelated to multi-language, but there is now a new "edit in normal mode" icon - sometimes I prefer this to modal and think a link from here is nice. I am going to attach the new version here for the moment - please let me know if everything works as expected for you. Portuguese Default: English BatchChildEditor.zip

If you want an easier approach than creating a full process module (not that it's that hard), but you could create a custom AdminAction using this module: https://processwire.com/talk/topic/14921-admin-actions/ Note that it's very easy to hide all the other actions from the required role and add your new action to the flyout menu so they have quick access.

Yeah, that would be the problem. If you use repeaters a lot, then I would highly recommend updating to the latest dev version of ProcessWire. There were a lot of great new repeater features introduced in 3.0.44 (http://processwire.com/blog/posts/pw-3.0.44-repeaters/) - we are now at 3.0.52. I do think the automated header from title was available before this, but would need to track down exactly when. 2.6.5 is REALLY old now

What about the "Repeater Item Labels" section on the Details tab of the field settings - what does that look like?

@kathep - sorry, I think I must not be understanding properly. Would you mind posting some screenshots showing your repeater settings and an example screenshot of a completed "Introductory Exercise" title and what the repeater header bar looks like after saving?

Well it's easy enough to not have them save to other languages even if the default is populated, but I think populating them is a little confusing still. What about setting the html5 placeholder as the default language title. Do you think that would be a reasonable UX?

Very true, but I assumed he needed/wanted them to have the same name.

Hey @tpr - good catch. I am looking into this now and actually thinking about revisiting the fairly recent change we discussed that shows the default language title when there is no title for the current user language. I am thinking about leaving the title field empty and maybe putting the default language in the tooltip of the warning icon that shows up. I also need to revisit how page names are handled - at the moment it's a mess if you change the title because it changes the name for all languages. Anyway, let me know what you think about my idea for making the title blank if it's blank for the user's language - just want to make sure I am not making it worse for anyone.

It won't be possible to store the image with the same name twice because they are bot stored in the same folder in the filesystem. Why can't you download it from the images field?

Hi @hacsor and welcome! Sounds to me like you either don't have the path to the RevSliderEmbedder correct, or it's a namespace issue. If the basic-page.php template file includes the ProcessWire namespace at the top, then you would need to change your call to RevSliderEmbedder to \RevSliderEmbedder so you are calling it from the global namespace.

Glad BCE worked for you I am curious though what happened for you with Ryan's module. My local dev setup is definitely nothing special. A 2011 MacBook Pro with 8GB RAM and PHP 7.1 all setup via HomeBrew. I feel like something else must be amiss. I have never used MariaDB - I know it is supposed to be faster if anything and completely compatible with MySQL, but who knows?

Thanks Steve - yes please let me know if it shows up again, but I hopefully it was an old issue that isn't present in the current version.

I am getting the feeling that not everything in the wire folder was copied across correctly. I would suggest deleting it entirely and copying across the new one again.

Yep - it will work on all servers - it will always be the full disk path to the image, which is what file_get_contents wants. Of course with the right PHP settings it can also use a full URL, but disk path is easier and more universally supported.

Is this live somewhere so I could take a look?

Could be as simple as a page load, but clearing the PW cache couldn't hurt. Might also be worth clearing the file compiler cache to make sure everything is regenerated.

Did you upgrade from PW 2 to 3? Maybe reload again - that new error sounds like a file compiler issue - I have noticed that occasionally you need an extra reload to trigger everything the first time to upgrade to 3.

I just did a quick test with BCE using your test file and by the time it hit my 120 timeout, it had created 4898 pages, so 2449 pages per minute isn't too bad. Curious what you find at your end though.

Hi Steve, Are you talking about PHP's session folder, or PW's /site/assets/sessions/ ? For the former, should PHP's garbage collection take care of that? For the latter, I see I have a few (5) old "tracy.0e3b49e668" files from Apr and May 2016, but none more recent. I wonder if this is an old issue that has been fixed. It sounds like you are still seeing new additions though? Could you provide more details on the age of these files, and also your OS, PHP version, etc? Thanks!

Might be as simple as file permissions - do a recursive 755 / 644 (or whatever is appropriate) and make sure the owner is correct, eg www-data:www-data

Less fields is better for you - less to manage, but it won't matter to PW either way because all the field db tables (eg field_slider) are indexed by the pages_id so PW finds the relevant entries very quickly. Having a separate field won't improve this.

As I mentioned - I think this may have been due to a change in the default settings of MySQL in more recent versions. Surely you can understand that 2.7 was working at the time when most of us were on older versions of MySQL? Out of curiosity, I googled Drupal and Wordpress along with the "column not found" error and found many results. Not trying to make excuses - just saying that this is sometimes the reality of software development - things break due to changes in dependencies - there are a lot of combinations/permutations to keep up with!

I haven't used this module, so not sure about those red fields, but I think the likely correct fix for the operator not supported issue is to to define $allfields in the additional fields at around line 65. protected $allFields = array();

I completely understand your concerns regarding giving a client a product that you don't have faith in, but there should be no way a client can make this happen - they should not be given superuser access and therefore should not be able to install modules. I made exactly the same argument as you some time ago I just forced the same error in PW 3 (by deleting a language field in the pages table) and it now looks like this, with everything still accessible. I would definitely urge you to try PW 3 - there has been well over a year of development that's gone into this new major version. I think it is only fair that you judge PW based on this version - I hope you agree!