Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by dragan

  1. Can you elaborate on this? Is the quantity derived from a page / selector count? And that's all you really need with all those queries? There are faster ways to get counts than to always return the full page arrays. (I probably miss the "big picture", sorry if it's a dumb question)
  2. Variables like $page are reserved by PW, so you shouldn't try to redefine them. PW tries to find a field 'autores', which is not available in the current $page, but in the page array you're looping through. Try: foreach($pages as $p) { if(count($p->autores)) { If you install Tracy Debugger (which every PW developer should, imho), you can include debug output for variables, which is a big help when developing.
  3. The concept is actually quite simple: A PW field (integer), which you create and use in all templates that you need for the Drupal import. That field can just as well be hidden in the PW admin. In your export CSV you have to make sure that the unique node ID is present, and then you can match those two fields. If you don't export/import the published date in your initial migration step already, you can just as well update it later: $drupalNodes = array(1 => 1601804655, 2 => 1601804674, 5 => 1601804676); foreach($drupalNodes as $k=>$v) { $p = $pages->findOne("drupal_id=$k"); $p->of(false); $p->setAndSave('published', $v); }
  4. Hi @bilioso and welcome to the PW forum. You can edit the publish date programmatically or via module. Given your situation, it would be far more efficient to do it via the PW API. If you've imported your Drupal pages to PW already, I hope you also defined and populated a relational ID that relates from PW to the old Drupal site. If you did that, it's just a couple of lines to update the publish date with the PW API in one go. Let us know if you need instructions (but I guess the first link I posted should give you enough clues) Disclaimer: I haven't used the module I linked. Although compatibility with PW v. 3.x is not claimed, chances are it will still be working fine with the latest PW version. If not, maybe all that's needed is to add PW namespace in the very 1st line of the module.
  5. Is there a reason that PW's core internal search (ProcessPageSearch) doesn't support the newly added "advanced search" method? i.e. the one described at the bottom here #= / with the ability to use * - +. Did @ryan simply forgot to add it in the module config screen, or maybe because of potential performance bottlenecks? Just discovered this in the module code: /** * Get operators used for searches, where key is operator and value is description * * @return array * */ static public function getOperators() { $operators = Selectors::getOperators(array( 'getIndexType' => 'operator', 'getValueType' => 'label', )); unset($operators['#=']); // maybe later return $operators; }
  6. Well, you can still create a page in your source PW installation that outputs either a JSON of your n latest articles, or complete with markup. On the other PW installation, just fetch that page in some way and include it in your template file, which can be as easy as file_get_contents('http://pw-site-with-articles.com.test/latest-articles.php'); No need to install and configure a full-fledged REST API module for that.
  7. @Roych fwiw - I've got this little test setup running fine on my local dev machine (Windows with Laragon and dummy .tld .test enabled) <?php namespace ProcessWire; // this runs in a folder "etc", which can be accessed locally @ http://etc.test/fetcharticles.php (no PW in this folder) // I guess it could just as well be in the PW root of the instance from where you fetch the articles require_once 'D:/laragon/www/pwbig/index.php'; // source PW installation root index.php $out = ''; $site_1 = new ProcessWire('D:/laragon/www/pwbig/', 'http://pwbig.test/'); // source path / URL $site_1_articles = $site_1->pages->get('/articles')->children; $out .= "<div class='articles'>"; foreach($site_1_articles as $article) { $title = $article->title; $out .= "<a href='{$article->httpUrl}' title='$title'>"; // httpUrl instead of url $out .= "<div class='article'>"; $out .= "<h2>$title</h2>"; if($article->images->count) { $thumb = $article->images->first; $myImg = $thumb->size(200, 200); $out .= "<figure><img src='{$myImg->httpUrl}' alt='{$myImg->description}'></figure>"; // httpUrl instead of url } $out .= "</div></a>"; } $out .= "</div>"; echo $out;
  8. @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)
  9. 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/).
  10. 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"
  11. 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.
  12. 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).
  13. 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.
  14. 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.
  15. @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).
  16. @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/
  17. 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.
  18. 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.
  19. 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 🙂
  20. 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 🐈
  21. 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");
  22. 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>
  • Create New...