Jump to content

overoon

Members
  • Posts

    22
  • Joined

  • Last visited

Profile Information

  • Location
    Vienna, Austria

Recent Profile Visitors

7,926 profile views

overoon's Achievements

Jr. Member

Jr. Member (3/6)

14

Reputation

  1. Hi @FireWire and thanks for the blazingly fast reply! I can confirm all of your findings and also: the fix on your dev branch resolves the issue 🙂
  2. Hi, i'm running into an issue when working with repeater matrix (pro fields), which wasnt a problem using the "original" fluency. i didnt find a related issue, so i thought i might as well report as it also persists in 1.0.7 🙂 Textareas (body field) within a repeater matrix do not receive the controls for translating, whilst regular inputfields still do. The console log reads: Uncaught TypeError: this.getEditorInstanceForLanguage(...) is undefined here a screenshot of the interface; the error is thrown when the repeater matrix expand is triggered/the field initialized. textarea fields outside of a repeater matrix are fully functional as intended. i wasnt really able to dig into it yet, as i will probably resort to the old version to get the site live, but let me know if i can be of any further assistance 🙂
  3. Hi, this occured when i was running an old version of processwire. Simply deinstall the module, update processwire and then you should be good.
  4. thanks for the tip, but the error is still there ? i now found the (only) occurence of these strings is in the .phrase-index.txt in assets/files/1061 even when find+replace \ to / i still get also doing the replace + clearing the compiled files after doesnt change anything. from analyzing the file this also only really helps the live index, so perhaps not the right place to look at anyhow any further suggestions? when i click on the file in the greenbar it opens right away, also the http url is correct. just this thing below has the \ /
  5. hi, i tried finding something about the topic, but didnt manage to. i currently face (and already faced a couple of times) the issue of being unable to edit language files through the backend after i deployed the site to it's final hosting destination. i usually tended to just go through the process of manually re-inputting the phrases, but this site has a lot of translatables. i work on a 2019 xampp environment (windows) for local development and the servers that i deploy to range from shared environments to dedicated servers, so i really cant pinpoint the issue on a specific server/php/sql. in this latest deployment, i also tried setting the chmod for the site/assets/1061/ files to 666 and dir to 777, which sadly didnt do anything either. when i enter the backend and switch to languages i get a perfect list of all language files but once i hit edit ("bearbeiten") this is what i get: the problem is: those files are there, and they do work (in the frontend) -- if i manually download the file, edit it and reupload it, it also does exactly what it should. does anyone have a thought on this? my dev the site doesnt sit at the root, but it also doesnt in this specific deployment. absolute urls/roots have never been a problem in processwire before though. could it have something to do with the / and \ -- and if so, how would i find those? thanks and regards
  6. Finally, found it ? Just to finish this up: what i wanted was to use a foundation grid on my form to create custom grid solutions. this can be achieved by one pretty simple function (if you know which one ? ) $field = $modules->get("InputfieldEmail"); $field->label = "E-Mail"; $field->attr('id+name','email'); $field->wrapClass = "small-12 medium-6"; $field->required = 1; $form->append($field); // append the field in this example i add "medium-6" to my email field so THE WRAPPER is only 50% wide (using foundation). to achieve the grid stuff i put: $markup = array( 'list' => "<div {attrs}>{out}</div>", 'item' => "<div {attrs}>{out}</div>", 'item_label' => "<label class='InputfieldHeader' for='{for}'>{out}</label>", 'item_label_hidden' => "<label class='InputfieldHeader'><span>{out}</span></label>", 'item_content' => "<div class='InputfieldContent {class}'>{description}{out}{error}{notes}</div>", 'item_error' => "<div class='LoginRegisterError'><small>{out}</small></div>", 'item_description' => "<p class='description'>{out}</p>", 'item_notes' => "<p class='notes'><small>{out}</small></p>", 'success' => "<p class='LoginRegisterMessage'>{out}</p>", 'error' => "<p class='LoginRegisterError'>{out}</p>", 'item_icon' => "", 'item_toggle' => "", 'InputfieldFieldset' => array( 'item' => "<fieldset {attrs}>{out}</fieldset>", 'item_label' => "<legend>{out}</legend>", 'item_label_hidden' => "<legend style='display:none'>{out}</legend>", 'item_content' => "<div class='InputfieldContent'>{out}</div>", 'item_description' => "<p class='description'>{out}</p>", 'item_notes' => "<p class='notes'><small>{out}</small></p>", ) ); $classes = array( 'form' => '', // 'InputfieldFormNoHeights', 'list' => 'grid-x grid-padding-x', 'list_clearfix' => '', 'item' => 'Inputfield_{name} {class} cell', 'item_required' => 'InputfieldStateRequired', 'item_error' => 'InputfieldStateError', 'item_collapsed' => 'InputfieldStateCollapsed', 'item_column_width' => 'InputfieldColumnWidth', 'item_column_width_first' => 'InputfieldColumnWidthFirst', 'InputfieldFieldset' => array( 'item' => 'Inputfield_{name} {class}', ) ); InputfieldWrapper::setMarkup($markup); InputfieldWrapper::setClasses($classes); Important: "List" gets classes grid-x so foundation turns the container into a grid container. then the elements below receive their classes as defined in wrap-class
  7. Ok, so i kinda found now what was wrong: it all comes down to the default render() function and the process of building the registration form in the LoginRegister Module. My fix starting at the function at line 537 of the module foreach($registerFields as $fieldName) { if($fieldName == 'roles') continue; $field = $userTemplate->fieldgroup->getFieldContext($fieldName); if(!$field) continue; $inputfield = $field->getInputfield($nullPage); $inputfield->attr('id+name', 'register_' . $inputfield->attr('name')); $inputfield->columnWidth = 100; if($fieldName == 'email' || $fieldName == 'pass') $inputfield->required = true; if($inputfield->required && $inputfield instanceof InputfieldText) { $inputfield->attr('required', 'required'); } $form->add($inputfield); } is the added $inputfield->columnWidth = 100; this auto defaults all input fields to have no style="width: ... " attribute added. i still havent figured out, how i can add classes to the respective wrapper though -- so any help on that is still appreciated ?
  8. Hi, FIX IN POST BELOW maybe someone can help me: i dont know if this is a Login/Register only related problem, but it has taken me a long time now researching and i still cant seem to find the snippet where this is executed: when rendering the form with the Login/Register module, it automatically wraps the input field into a div with a certain width (most probably from the value set in the admin backend for displaying it there). since this is applied as element css i cant override it anyway. can i somehow hook into the wrapping of all the individual elements to deactivate that (and apply different css for better looks)? hooking into the input field only allows me to manipulate exactly that (inputfields, submits, ... ) thanks!
  9. thanks that seems to be exactly what i'm looking for -- i only found the "older" version via search!
  10. hi, i have a question, which i should be able to work out with htaccess, i just wanted to ask, if there's an easier way using processwire: i set up a new site using processwire with multilang etc. since a lot of stuff changed on the website (contents, hierachy, ...) there's now also a different domain structure. the old structure was: www.example.com/outlet-1 and now it's www.example.com/en/find-us/outlet-1 is there any way i can do a (temporary) 301 redirect, without having to remodel to the whole structure? the main reason for this is, that there are still tons of flyers and other advertising materials with this domain structure (transitionphase should end in <6months) the whole thing comes down to about 4-5 pages -- so nothing really drastic. also if there's no way in doing this with processwire, help with a proper RewriteRule for htaccess would be greatly appreciated. current workaround doesnt really do the trick. thanks so far!
  11. Thanks for your input, i changed my code and this should be working fine now: if(!$session->get('setLang')) { if(substr($_SERVER['HTTP_ACCEPT_LANGUAGE'],0,2) != 'de') { $session->set('setLang','1'); $url = $page->localUrl('en'); $session->redirect($url); } $session->set('setLang','1'); } if i'm correct, the problem was, that when my user clicks the link to /de/team/member-name and has an english browser, the domain wouldnt change, but all the contents were in the right language. now i'm using a _real_ redirect, causing even a crawler, calling upon /de/team/member-name to get to /en/team/member-name i really need the automatic redirection for non-germans, is this a proper way? Thanks
  12. I didnt try it out, but i'm quite sure, that's not the way you're supposed to use HTML for forms (i guess it always targets the first <form> tag) you might want to try this with a differnt approach, like using checkboxes <form action="<?php echo $_SEVER['PHP_SELF'] ; ?>" method="POST"> <label><input type="radio" value="nl" name="language"> NL</label> <label><input type="radio" value="de" name="language"> DE</label> <label><input type="radio" value="en" name="language"> EN</label> <input type="submit" value="Ok" /> </form> and then do the rest of your php stuff. OR what i'd rather suggest is a selection via <a> links (way easier usability) like this <ul id='languageSelection'> <?php foreach($languages as $language) { if(!$page->viewable($language)) continue; // check if page not published for this language $class = "$language" == "$user->language" ? "active" : ""; $url = $page->localUrl($language); $lang = $language->name; if(strcmp($lang,'default') == 0) { $lang = 'nl'; } // default language fix echo "<li class='$class'><a title='$language->title' href='$url'>$lang</a></li>"; } </ul> what it does is pretty simple: creating and populating an <ul> element with <li> children and clickable Language-Names (Text e.g. "Deutsch", "English" ,...). You could also insert your <img> Tags into the echo command instead of the $lang Variable. This Version also adds a "active" Class to Active-Language-<li>, so you're free to customize it with css best
  13. ok so i did some tinkering and found a way... yet i'm not sure if this is a "good" workaround. just to share: if(!$session->get('setLang')) { if(substr($_SERVER['HTTP_ACCEPT_LANGUAGE'],0,2) != 'de') { $user->language = $languages->get('en'); } $session->set('setLang','1'); } this code sits directly ontop of my header.inc file edited: the main goal is of course to "internationalize" the page... our main visitors are from german speaking countries but all the other languages shall be directed to an english version (just in case you were asking yourself about the if clause logic )
  14. hi there, this is my first post in the forums, and i got to say that up to this point working with process wire was a really easy-going experience. now i'm not quite sure if i'm just over-thinking my whole problem and i hope someone can help me. i have a setup of processwire running with german as default and english as additional language. i successfully implemented a language-switcher which works like a charm. now i want processwire to automatically check the visitors browserlanguage (basically on starting the session) and set it as default (if not german -> english) BUT keep open the possibility to do a manual switch. my first very, very simple piece of code (which terribly failed) looked like this (in my header template) if(substr($_SERVER['HTTP_ACCEPT_LANGUAGE'],0,2) != 'de') { $user->language = $languages->get('en'); } now i know what the problem is (my header.inc gets included everytime and does this request even after a switch), but cant make my mind up about a proper solution... i also didnt find something about this very specific problem by using the search, but am really grateful about any advice best, overoon
×
×
  • Create New...