Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by dragan

  1. 1 hour ago, fruid said:

    if ($page->linguafranca->title != _x('en', 'HTML language code')) :

    I'm not sure I understand completely, but the above line looks strange to me. In plain english, what are you asking PW here? And why the _() and not just a plain string?

    Maybe you should query the current user's language first, and then go from there

    $currLangName = $user->language->name; // "en" -> will be "default" if it's the default language
    $currLangTitle = $user->language->title; // "English"


  2. Check if the sessions table is really innoDB (it should be). Also, maybe try to decrease this value:

    $this->set('lockSeconds', 50); // max number of seconds to wait to obtain DB row lock

    But most likely, the DB engine doesn't have enough horse-power to handle the load. Are you on a shared hosting environment?

    You might also try to install SessionLoginThrottle module (core), to prevent too many DB-hits from users who are trying to login without success (repeatedly).

    • Like 1
  3. If you don't need the entire page arrays of $shipments, then only querying the counts will always be way faster. Also, try to use findMany() instead of find().

    I just ran three queries on a dataset of ~1100 pages in Tracy, and got an average of ~34ms:

    $sel_2 = $pages->findMany("parent=1041, template=project, created>$month, include=all")->count;
    $sel_3 = $pages->findMany("parent=1041, template=project, created<$last2Years, include=all")->count;
    $sel_4 = $pages->findMany("parent=1041, template=project, images.count>0, include=all")->count;

    Using just find(), it was about 10x slower.

    Or you can even replace find() with findIDs:

    $sel_2 = $pages->findIDs("parent=1041, template=project, created>$month, include=all");
    $sel_3 = $pages->findIDs("parent=1041, template=project, created<$last2Years, include=all");
    $sel_4 = $pages->findIDs("parent=1041, template=project, images.count>0, include=all");

    This takes it down to ~20ms, i.e. approx. 33% faster than findMany()->count

    Of course, if you have a really huge amount of pages, then a real direct DB-query (avoiding PW's API) will always be the fastest option. Or try @bernhard's RockFinder module.

    • Like 1
  4. You should be able to translate these strings in the language section: setup/language-translator/edit/?language_id=1010&textdomain=wire--core--wiredatetime-php

    Just replace the language_id with your alternative language id. Or go to setup > languages > German and click on "find files to translate" under "core translation files", then select WireDateTime.php.

    • Thanks 1
  5. @fruid I guess the only way to circumvent this behaviour is to delete with the backspace key, instead of "select block and use delete-key".

    Searching for this issue brought up this PR, which apparently has just been merged yesterday (though I'm not 100% sure if it really fixes the exact same issue).

    • Like 1
  6. I guess inside a module you have to use wire('languages')->setLanguage("foo") instead of $languages (not sure, no time to counter-check). 

    1 hour ago, virtualgadjo said:

    $p->title->setLanguageValue('default', $titre);

    Nice one... didn't know that method existed like that. Well, that's certainly even better. The wonders of the PW API never ceases to amaze me 🙂

  7. If you don't need the PW API to process the form, you can place your script in root.

    action="<?=$config->paths->root . 'myscript.php'?>"

    Although, as already mentioned, I'd suggest to create a PW page + dedicated template for such stuff. Together with URL segments, you can place all your form processing logic in one single file (or even include() each sep. form processing logic, in case there's many of them). Well, actually URL segments aren't really needed, you can just as well include a hidden field in your form, or add a ?form=support to your action URL. Many ways to skin a cat 🐈

    • Like 1
  8. I'm having a Case of the Mondays™ today...

    I've been using PW now for some 7 years or so, and most sites were multilanguage setups.

    Today I was trying to "upgrade" a PW site and add a 2nd language, and everything works as expected, except one strange thing:

    The default pagetitle field (id 1) only shows up in the page editor with default input language field. If I switch from german (default) to english in the admin, I see the english titles just fine in the page tree. However, when I open a page (any page, any template), I only see the german field, without the UI folder icon, or tabs). The API correctly gives me the language values I'm expecting.

    I thought maybe I wrote a hook a long time ago which causes this behavior, but I disabled my site/ready.php altogether, and things are still the same.

    Does anyone have a clue where to look, and how to debug? The UI elements are not there when I inspect the field in the browser (i.e. they are not just hidden by CSS, they're not there). What module or config could possibly cause this? And it's ONLY the pagetitle field that is screwed, all other text- and textareafields work fine.

    I had a "pseudo multilang" field title_en, which caused havoc. Once I renamed (and finally deleted) this field, everything wente back to normal.

  9. This may seem like a hackish workflow proposal, but you could just as well clone the production page, unpublish that copy, and work on that. If the clone is ready to be published, publish that one and hide / unpublish the other. Just bear in mind to adjust the page names and -names to avoid ugly looking URLs like /section/my-page-name-copy and 404s.

    • Like 1
  10. Sorry to flood the module dev forum lately with questions, but I thought I'd better create separate threads for each question (they're somewhat related, though not quite the same issues).

    I built a simple module that allows users to create new pages. That all works all quite nicely, but I noticed some differences how PW handles validation.

    I created a public function ___executeAddNewFooPage() in my module, which takes the form values from the main ___execute() function. What I would like to do though, is the same behavior like in a module configuration screen: Stay on the same page if there are errors (form not valid). I can detect invalid fields just fine in  ___executeAddNewFooPage() and link back, display red errors at the top, but then each field, which is not a text-based field, loses the user's values, i.e. selects are reset, text + textarea field values are intact. I tried setting the form action to itself, i.e. "./" instead of "./addnewfoopage", but that doesn't change anything.

    What I would like to achieve is that the user stays on the page, and sees field errors like e.g. in the WireMail module config screen:


    I've searched the forums far and wide, but didn't find any related infos. If someone can enlighten me, I'd appreciate it very much.

  11. I have built a simple process module that allows users to create new pages; so far, so easy.

    Now I noticed something strange, and I'm not sure if I miss something, but it seems inconsistent to me: Text-based input fields get the HTML5 attribute required="required" and it works as expected.

    However, for selects (InputfieldPage, InputfieldAsmSelect) PW only injects a CSS class "required", but doesn't set required="required".

    Example code:

            $field                 = $this->modules->get('InputfieldPage');
            $field->inputfield     = 'InputfieldAsmSelect';
            $field->parent_id      = 1221;
            $field->labelFieldName = 'title';
            $field->name           = 'service';
            $field->label          = 'Dienstleistungen';
            $field->required       = true;
            $field->setAttribute('required', 'required');
            $field->columnWidth = 33;
            $field->collapsed   = 9;

    I know I could create a hook and inject that attribute (maybe something like this?), but it seems like overkill, when we can already configure the fields. Am I missing something obvious here?

  12. Perhaps this is a stupid question to seasoned PW module developers, but here it goes:

    I'm trying to put together a module with various fieldsets, where users can enter form values and save to PW-pages (or elsewhere). I see that the entire module content is wrapped in one single form.

    I know I can split a module into several pages, but I'd like to have collapsible fieldsets instead.

    Can I create multiple forms, with each one having its own form action? Or is there another workaround / method to accomplish this? I know I could do some JS/AJAX stuff (e.g. a button with a click handler sending data to another PHP script inside InputfieldMarkup), but I'd prefer to stick to "the PW way" as much as possible.

  • Create New...