Jump to content

dragan

Members
  • Posts

    2,007
  • Joined

  • Last visited

  • Days Won

    21

Posts posted by dragan

  1. You can go to site/assets/files/1234/ and send these JSON files to the translators. 1234 being the id of the alternative language.

    You'll see the language id @ setup/languages/ when you hover over the language edit link (1010 seems to be the default language).

    Before that, you'll want to make sure all those JSONs are there, so you'll need to click the "find files to translate" button @ setup/languages/edit/?id=10189 under "Site Translation Files". There's also two buttons there in the bottom-right for downloading all files as CSV or ZIP. When you get the translated JSON files back, you can upload them here as well, and replace the old ones.

    • Like 1
  2. 8 hours ago, psy said:

    retrieves qty of items

    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)

  3. 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.

    • Like 1
  4. 8 hours ago, bilioso said:
    15 hours ago, dragan said:

    a relational ID that relates from PW to the old Drupal site

     

    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);
    }

     

  5. 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.

  6. 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;
    	}

     

  7. 3 hours ago, Roych said:

    Thank you dragan but still not working, same error again.

    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.

    • Like 5
  8. @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;

     

  9. 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"

     

  10. 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
  11. 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.

    • Like 1
  12. 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
  13. @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
  14. 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 ?

×
×
  • Create New...