Jump to content

DaveP

Members
  • Posts

    868
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by DaveP

  1. The 'photo' field is all set up with a 'field-photo' template. Everything works in PW back end but setting values programmatically isn't having any.

    The code is like this.

    $page->of(false);
    $page->photo = 'https://example.com/img.jpg';
    
    $page->save();
    
    $page->photo->textfield = 'Some text';
    
    $page->save();
    $page->of(true);

    That's an abbreviated version.

  2. Few random thoughts...

    • Log all searches (you probably already do). This works 
      $log->save('search',"Query = '$q' Results = ($results_count) $pages_found");

      gives something like 

      2018-03-12 16:19:08	guest	https://example.com/search/?q=taxi	Query = 'taxi' Results = (3) 1170|1073|1693
      2018-03-13 11:22:27	guest	https://example.com/search/?q=9001	Query = '9001' Results = (1) 1021

      This is valuable because it shows you what you are up against!

    • Consider incorporating stemming (if you are working in English, at least). The best-known algo is the Porter stemming algorithm. There are PHP implementations on GitHub etc. What you could look at is for each product, hook on product save and have a back-end field programmatically populated with stemmed versions of Product Title etc., then stem search words and build that into your selectors.

    • Also consider a back-end 'search keywords' type field, and if there's a glaring regular user mis-spelling just add that manually. This doesn't scale all that well, but can help with a quick fix. (I built a search for a fishing tackle shop site many years ago - pre-PW - and nearly as many searchers spelt 'Daiwa' as 'Diawa' as those who got it right. Easy quick fix.)

    • Like 8
  3. 17 minutes ago, dubiousa said:

    Do you think it would help just delete and reinstall?

    Not yet. Let's try some stuff first.

    There's something going on in .htaccess, because it redirects to www.vivid.black under some circumstances.

    You might try renaming .htaccess to htaccess.old or some such and replace it with a new copy of the default one in the PW download, see if that changes anything.

  4. Welcome, dubiosa!

    Well, whatever you've got going on, it's very strange.

    1. If I visit the http URL you posted (with a full stop at the end (?)), I get the default Apache page.
    2. If I remove the full stop, it redirects to https and I get a certificate error.
    3. If I replace the full stop with a slash, I get an actual web page over https.

    Is the server a VPS? Is it managed or unmanaged? Is it shared hosting?

    As far as I can see, it's likely to be either a server misconfiguration (Apache etc.) or your .htaccess, or a bit of both.

    Tell us a bit more and we'll try to help.

    • Like 1
  5. Very occasionally you'll come across a deprecated/removed PHP function in a very old module written for PHP 5.3 or 5.4 (what's the earliest version PW worked with years ago?) if you're now using, say, PHP 7.2. Even that kind of thing can be relatively easily Googled, or I'm sure someone on here could help with a specific problem of that kind.

  6. 13 hours ago, Jonathan Lahijani said:

    I come across this brain twister once in a while.

    Know exactly what you mean! I had something similar a couple of years ago and did find a kinda solution, but was never happy with it. Just hope I remember about this next time the need arises.

  7. 9 hours ago, Mark C said:

    I've got hours of reading to do now...

    ...and if you need a break from reading, take a look at this if you haven't seen it already. It's a very old video that Ryan did for PW 2, but very much recognisable even now. It covers some of the content management aspects of the PW backend. 

     

    • Like 2
  8. Following on from my discoveries mentioned here, I have forked the Indexer Module referred to.

    Couple of reasons for this -

    • Contrary to my thinking at the time of writing the post linked above, there was a deprecated/removed function in one of the files used. (Absolutely no idea why that wasn't apparent originally - must have been some code that isn't always called.)
    • The module was set up to use executable parsers on the server for preference and only included a PHP parser for PDFs, not .doc, .docx etc word processor files. This is probably not optimal for shared hosting use as including your own executables is rarely, if ever, an option.

    The fork's repository is at https://github.com/DBPreston/Processwire-site-indexer.

    I have fixed the error due to use of split(), which was removed from PHP 7.0, and added a .doc parser so that it will now parse word processor files as well as PDFs and updated the module config page to reflect that.

    In the small amount of testing I have done so far, it seems to be working. Neither parser is perfect and the whole mode of operation of the module (adding a 'keywords' field to every page) may not be perfect for every use case, but it is certainly very useful in some instances.

    I should be very grateful if anyone has the time to give it some further testing, forking, pull requests etc.

    • Like 11
  9. Further to this, it turns out that http://modules.processwire.com/modules/indexer/ can (and does) index PDFs, and although it was created in 2013 and only claims compatibility up to PW 2.4, it still works. (tested on PW 3.0.84)

    <edit class='bit-more-info'>

    Not only does it still work, but it works brilliantly. No errors, no warnings, and this is with PHP 7.1! All on default settings, just check 'Use built-in PHP class?'.

    </edit>

    • Like 6
×
×
  • Create New...