Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by dragan

  1. @gebeer Are there plans to allow for multiple images to be used with this module / field-type? Or is there something I've been missing? I don't see anything in the module or field configs. (not that I would need it right now for a real-live project, I'm just curious)
  2. A long shot, but... if you open Adminer or phpMyAdmin, what does it show in the table "templates" for id 2? afaik, useRoles should be set to 1, and noGlobal set to 1 too (the rest shouldn't matter). Replacing the wire folder won't help, cause the changes you made are stored in the DB (and even if it would be stored to the file-system, it would under site/).
  3. 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"
  4. I guess it would be easier if you'd use PageReference instead of FieldtypeOptions. Then you could create your own "servizi" template with an image field that hold the icon (limit to one single image), and then it would be a breeze to just output $item->icon->url etc.
  5. 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).
  6. 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: <?php $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; d($sel_2); d($sel_3); d($sel_4); Using just find(), it was about 10x slower. Or you can even replace find() with findIDs: <?php $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"); d(count($sel_2)); d(count($sel_3)); d(count($sel_4)); 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.
  7. 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.
  8. @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).
  9. @DanielKit Did you also check the JS console? Maybe you'll find some useful hints in one of these old forum threads: https://processwire.com/talk/topic/11627-pw-admin-logon-problem-on-php-7-platform/?do=findComment&comment=108209 https://processwire.com/talk/topic/4211-unable-to-log-into-admin-session-write-issues-using-vagrant/ https://processwire.com/talk/topic/5183-cant-get-processwire-working-in-vagrant/
  10. As @kongondo already mentioned, you can get the unformatted value, and then simply do all the desired calculations you need. $ts = $pages->get(12222)->getUnformatted("proj_timespan_to"); $diffHours = (int) round(abs(time() - $ts) / (60*60)); $diffDays = (int) round(abs(time() - $ts) / (60*60*24)); You'll find plenty of documentation about PHP functions, e.g. here or here.
  11. That's something that for whatever reason stopped working for me as well, since a few weeks / months. Don't know if that has been reported as a bug though.
  12. I guess inside a module you have to use wire('languages')->setLanguage("foo") instead of $languages (not sure, no time to counter-check). 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 🙂
  13. 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 🐈
  14. The easiest way to make sure you always populate the default language, is a one-liner before all your regular page-creation functions: $languages->setLanguage("default"); and of course, if you always explicitly want to edit the french value: $languages->setLanguage("fr");
  15. You don't need a hook for that. Just render the page title in your frontend template dynamically. Maybe something like this: $pageTitle = $page->title; if($page->template === 'product' && isset($page->design)) { $pageTitle = $page->design->title; } ?> <title><?=$pageTitle?></title>
  16. @MSP01 I'm no expert on PW's auto join, but re: 2.) I think PW will definitely fire SQL behind the scenes each time you use such a helper function. What you could do instead, is maybe create your own $config vars. That's a perfect use for global settings, e.g. image resize options, or define your own custom paths/URLs etc.
  17. 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. Update: I had a "pseudo multilang" field title_en, which caused havoc. Once I renamed (and finally deleted) this field, everything wente back to normal.
  18. 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.
  19. Another good reading material: https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/
  20. 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.
  21. 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; $fieldset->add($field); 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?
  22. 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...