Soma

Such great news! Thanks Ryan this is awesome. For the moment I have to test a little more and think about what could be added. But it' seems its all there that makes a great help to making multilanguage sites.

Edit: Wanted to add something I forgot. You can also enable davanced mode (config.php) and you'll have a select underneath the fieldgroup on the template edit screen to select a Fieldgroup from another Template. It will reference the fieldgroup of that template and and stay connected that if you change the original it will reflect on the template that share the same fieldgroup. This could also be used (instead of cloning) to have different templates having same data type but have a different name thus a different template file. BTW the whole admin backend is done using one template 'admin' using processes you define on a admin page to tell what functionality or controller it has.

"Template" inPW is like a db table with all its fields. If you change the structure of the table you loose data... Except for fields that are the same in the template you change to. Changing a template of a page is not something you do all the time and only to give this page a different content or meaning. It's all about data here and not presentation. "Template File" is more of what you think of in MODX I think, and it's linked to the Template by it's filename. But you don't have to create a file for a template unless you want or need to have it renderable or viewable. The Template name also can be changed, thus mapping it to a different template file. As WillyC pointed out you can also leave the name (which often is used in template code as indentifier and you don't want to change that, unless developing) and define a alternative name that will be used to map to a template file. You can even have all your template share the same template file simply by setting this. A page using a template to build it's data model also isn't locked in to a certain presentation. You can change your presentation template on runtime or have some MVC like approach even. You could even build a simple system to be able to select from different "presentation modes" on a page using page field to build a selection. You make it up. There's many possibilities with how Template and Template Files work together and it allows for some great flexibility in a simple manner. I even after some time working with PW I found ways I didn't see or knew it was possible before, so enjoy the ride. Not sure this is of any help. Always struggle a little explaining this stuff.

You screenshot is gone... I think you have to use $modules->get("InputfieldFile") to load an instance and not new InputfieldFile() See example form here https://gist.github.com/somatonic/5236008 There's also various threads about form and API.

Yeah this should work. I figured out how you could add a image and get resized with the InputfieldImage you have. Having this as setting $field->maxWidth = 100; $field->maxHeight = 100; Then when adding the image to page field: // create new page image first $img = new PageImage($uploadpage->images, $upload_path . $file); // add it to page as usual $uploadpage->images->add($img); // trigger the image max size sizing $form->get("images")->fileAdded($img);

I think if you set the max with and height on the image field you have on the page you won't have to resize it. Larger images will get resized when attached to it. Of course you can resize the image via API using ImageSizer.

What field type are they? X and Y? I don't see any problems doing so what you're saying. Add the fields to the repeater, loop the repeater and assign values from one to the other field and save them.

Ahh, if you use the InputfieldImage/-File to upload it won't be like a field you have on a page, you only have the Inputfield and use it to "upload" files. In this case it's not doing anything because those particular actions are triggered when an image is added to a page. So since you add the image to a page at the end, you'd have to set the max size there of course. Once you add it to the page it will resize. Or you could do it using API after submit and before you attach the image to a page image.

InputfieldFile isnt neccessarely an image. Youd have to take InputfieldImage.

Create your own profile and use that as a start?

Arent they the ready to edit repeaters?

Maybe remove the code in the first post and link to a working code at least.

I posted 3 or was it 4 examples codes that work already, so what is the deal ? Spent lots of hours btw...

Why? You could add those, but they're not gonna do anything as you can't and don't search with <> anyway. Adding the words works just fine. BTW when I search with "<keyword" you land in nowhere land, throwing a selector error. Ryan bug? Even tho using $sanitizer->selectorValue("<keyword") the < get's through and throws a fatal error. Edit: Hm happend in 2.2.9 installs, it seems to work correct in later versions.

Thanks diogo, I know something like this is possible, just not a solution I like and think it the way to go especially on big sites. Also just stripping tags would leave you with connected words where usually a white space should be etc. After testing a little I found %= operator has very strange results, it returns pages that don't contain the word at all. While when doing a search in mysql admin with %word% on body it returns only 2 pages, while using pages find it returns 4. No idea what is going on but definately something wrong there. Now looking a PW db query the ~= operator would be the one to choose anyway, as it searches multiple words and actually uses the stopwords compared to all other operators. So adding stopwords is also easy and I have now added some additional words for certain html tags. $stopwords = array("table","tbody","thead","tfoot","height","strong","align","href","style","left"); foreach($stopwords as $w) DatabaseStopwords::add($w);

No I'm not building anything, just thought you could (). Yeah I agree it would be nice to have some custom module, but building a search index myself in the past I know how hard it is also regarding multilang. So using some third party tools does make sense as for not reinventing the wheel.

I unliked your post.

Wanted to add: Maybe the best way is to install Language Support (not installed by default) and use translation feature of PW to change the label of the name field. Even if you don't need language support it would allow you to do it with few clicks and have it localized even. If you only need one language you could use the default language and create a new translation. Enter the file name you want to translate/modify The file that makes the page name field is /wire/modules/Inputfield/InputfieldPageName/InputfieldPageName.module Once created you can see some fields to enter, look for "name", enter your text and save. Done.

You can't do this just out of the box but with a autoload module you could easily accomplish this. Also there's useful needed features in there for an editor. Why is this a problem? It may not necessary in most cases... In PW, almost all of these things can be changed modified using hooks on what builds them in the admin. So if you really want to do it, the best way would be through a module like the /site/modules/HelloWorld.module It shows some example of hooks and is worth a look and have a play anyway. This following module hides the InputfieldWrapper "Who can access this page"? in the settings tab for user having a role "editor". <?php class AdminHelperHooks extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'My Admin Helper Hooks', 'version' => 1, 'singular' => true, 'autoload' => true ); } public function init() { // add hook to the page edit module and the method that creates the wanted fieldset $this->addHookAfter('ProcessPageEdit::buildFormRoles', $this, "removeSettings"); } function removeSettings(HookEvent $event){ // check what role the user has, if not has editor role do nothing if(!wire("user")->hasRole("editor")) return; // $event->return being the inputfield wrapper $wrapper = $event->return; // set the inputfield wrapper to hidden $wrapper->collapsed = Inputfield::collapsedHidden; // we're done } } Create a new file AdminHelperHooks.module with this code in a new folder /site/modules/AdminHelperHooks/ Install and test with editor user.

Edit: Just wanted to add that hardcoding the paths isn't exactly a good solution. Better use the config vars.

Thanks Matthew, well I like all good beers Have you tried my suggestion to output the upload path to debug? However, to make it short, Ryan made an small error in that he uses "$config" in a function scope. That would leave you with a upload path "temp". It would have to be "wire("config")->paths->assets" to get it to work, as wire() is global and can be used everywhere even in functions.

Confirming means you tested it? Echo it out in your code and add line "exit;" after it.

And what do you think it is? What have you done to debug the upload path, now that you know it's something wrong there? The answer is even in the error itself.

If you create a new child page, which can have multiple templates, the creating page process can't know which template you gonna choose. So it doesn't work the way you doing. Also in this case it wouldn't make sense as you don't know which template context should be displayed. BUT if you have a setup where the parent page template only allows for 1 particular child template (under Family settings of parent template) it does take that template for the page creation step and you'll see the title in context. The "name" field is built-in and a special field you can't change within fields setup. But you can have a simple autoload module that renames the label to what you like. Although I think it's not an issue to have it "name", I understand people want to name it different. A module like the HelloWorld.module, can be used as a starting point, with as hook and a function // in init() method add a hook $this->addHookAfter("InputfieldPageName::render", $this, "hookPageName"); and add a function below with this: public function hookPageName(HookEvent $event){ $field = $event->object; $field->label = "URL segment"; }

Just wanted to share that, when using pages find to search title|headline|body, since the body usually is text which contains html the search also finds html elements within text. http://processwire.com/search/?q=strong The pages found do not contain the word strong. I know searching pages using a pages->find(selector) does not account for this, but maybe one should clean all those tags out, or add it to stop words? Stripping tags before a search on texarea? Searching site with PW in genreal How do you guys also feel about using pages->find() to use as a site search? In cases where data pages are is pulled into other pages, it's getting hard to work around those cases and keep track of it. Also sometimes it seems the search doesn't return pages in correct relevance, depending on a lot of factors what fields you search and if they're full text etc. What is you're experience with PW search? If you use multilanguage, the stopwords are still only the english once used that come with core. So not ideal still. What you guys think about having a search tool to index pages using a parser and write index tables? Or would you use another tool or google custom search?