Soma

This was in the "header" Title of the template edit screen, but since it is gone now in the new admin theme version...

What I did in the past is to hook on InputfieldForm::render and check for if the form is the add page form. Works fine.

LanguageLocalizedURL module isn't in active development anymore because we now have this functionality in core with LanguageSupportNames which is the way to go now. LanguageLocalizedURL was created because the lack of names per languages and created by mcmorry and me. What I meant is using a page field that uses checkboxes as input to make languages active or not for a page. The input for the page field comes directly from the language pages found in admin (each language is a page). This enables you to turn off also the default language and at a small price. This page field then can be used to not find or show pages which aren't active even the default language. It's just a matter of a few lines of code to show the 404 when a page is accessed that isn't active. I get what you're saying but thelanguage system doesn't work like this and you always have to enter default title and name when creating a page. The way it is built I think it made the most sense for most use cases and it wasn't in from the start. It's a module that came to it and the default language is required because you can install and uninstall it. So there's so many things to consider and pros and cons, no language system is perfect and may not suits your requirements. But PW is enough flexible and customizable to work around it and give waht you need even when you have to enter the default lanugage title and name I think it's a small issue considering that PW gives you in term of multilanguage features. I and my client can live with it as it's not something of a problem that big. I don't now what Ryan thinks and if it makes sense or is even easy possible to implement a "not have default" language require. Maybe it is easy and I'm not seeing it or there's a better workaround, but so far I have to use whats there and try to use it as best as possible. If the project requirements fit, still the most flexible and best way to create multilanguage sites that can differ in structure and not are based on a default language should be built using separate branches for each language and connect them using page references. There was a module in development (Oliver) that would help managing sites like this but I don't know what happend to it as it doesn't seem to be active anymore since a long time. Building it this way enables you to have each language as it's own page and can be much more flexible and practical the way you can build your site and be free from restrictions coming from a language system that assumes things you might don't want.

I bet if you open those images in photoshop the larger image would use more RAM than the smaller. With jpg's the file size can foul you.

You need more memory.

Just be nice with PW and it will be nice to you ;

Hi ioio

Funny they have a captcha on their own contact form...

I use additional checkboxes for each language with a page field coming from the language pages. Then check for those in my code for navigation and init.php. works fine but agree that it would be nice feature. Although I don't know if even possible as default title and name are required when creating a page. This is by design of how language support works as its primary build for admin and not frontend where needs can vary allot and there will always be drawbacks and workarounds.

Here is the pullrequest https://github.com/ryancramerdesign/ProcessWire/pull/241

I implemented this about a month ag oas I need it too but Ryan hasn't yet taken it into core. Busy times I guess.

This module can't be installed with ModulesManager as it says it's already installed due to the class name being the one in the core "ProcessLanguageTranslator".

$new_page->getInputfields(); will get the inputfields in context of a page already and thinks there's images or tries to access them, but there isn't. This has come up a a few times but can't find it. FormTemplateProcessor module by Ryan does the same and suffers from the same problem when using file fields (it's not meant to work with it anyway) https://github.com/ryancramerdesign/FormTemplateProcessor/blob/master/FormTemplateProcessor.module One way around this would be to create the form not using $page->getInputfields() but $page->template->fields and use it to get the inputfield foreach($page->template->fields as $field) { $inputfield = $fields->get($field->name)->getInputfield(null); }

This is on a 13" MacBook Pro on Chrome FF Safari The problem seems * box-sizing: border-box and the 100% width height of image. When I turn off the box-sizing the image stretches itself back to normal size. I don't think it's a good idea to use * for stuff.

Delete them with $pages->delete($c, true) Look on cheat sheet...

I don't think there will be one very soon, it requires also to update the inputfield, link and image plugin to work with new TinyMCE API. I haven't looked into in closer but would be quite a long task including inline editing etc. Ryan and others including me are very busy ATM so don't expect to happen very soon, unless someone else takes a stab at it.

Nothing works even setting the span to have the padding and make the full area of the button, so it's like a bug of the button and span text inside. When clicking with the pointer right at the top of the button text it still doesn't work. It's only like 1px range, but I so often hit that spot that it drives me crazy when working and clicking those buttons a lot building a big site.

It's the jquery ui buttons, it's usually generated by js.

I've just put to static and still same. I remember I stumbled over this 1-2 years back and gave up on it after trying to fix it. I think only thing would be to make the buttons different markup and use link or input but not sure what would be best. Edit: The only thing I think works would be to put padding on the span of the button and not on the <button>

Nothing of that works for me here in Chrome. Position relative or not. I tried everything possible. Clicking at the top of the span inside the button doesn't trigger the button, but visually click it down.

I found that at a very specific point on the button the click doesn't work/submit the form. I can click as much as I want and the button gets active state but nothing happens. Very annoying. The span text element inside the button maybe I have no idea. But I'm sure it can be solved.