Jump to content

dragan

Members
  • Posts

    2,007
  • Joined

  • Last visited

  • Days Won

    21

Posts posted by dragan

  1. Thanks. I changed it back to GET. However, when doing so, I get an absolutely puzzling 403 error for one certain tag only: No umlauts there, and it appears in two images.

    You don't have permission to access /_pw/misc/tags/ on this server.

    Using one of the other tags for the same images, it works fine. I could maybe understand an error 404, but 403?

    e.g.

    tags/?tag=poker = error 403

    these work fine:

    tags/?tag=cardgame

    tags/?tag=gambling

    tags/?tag=jassen

    tags/?tag=Jass

    Guess my hoster is paranoid and blocking certain keywords... o_O

  2. I stumbled upon a problem with URL segments. URL segment 1 is supposed to be the image tag. Works fine (= 2nd half of your example code "find all pages with the supplied tag")

    However, when I call a page like /tags/Genève I get an error 404. In other words: image tags with umlauts (àèöéç etc.) are not being recognized when called with 

    $tagvalue = $sanitizer->selectorValue($input->urlSegment1);

    Do I have to change something in the code or config to make image tags work with umlauts?

    btw: simply using page/?tag=Frühling works fine, i.e.     

    $tagvalue = trim($_GET["tag"]);

  3. That works like a charm! Thanks again.

    iirc, image tags are supposed to be separated by space, so the two lines 

            if(strpos($tags, ',') !== false) $tags = str_replace(',', ' ', $tags);
            if(strpos($tags, '|') !== false) $tags = str_replace('|', ' ', $tags);
    

    can be omitted.

    The URL segments tip is golden, I definitely have to explore that further. So far, I've only used it in a multi-language setup. Didn't even occur to me to use that here...

  4. Awesome, thank you!

    I'm on the road today but I'll tinker around this evening and tomorrow.

    (btw, the much bigger work is actually tagging thousands of pics in the first place...)

  5. Thanks, but that's not what I'm looking for.

    I need individual tags for each image. I can set them alright, finding all of them is where I'm a bit stuck.

    AFAIK, this was only introduced in PW 2.3 - the blog profile is 2.2. The tags there are per page, not per image. I'm already familar with page-selectors, the page input field etc. It's the specific image tags I'm having problems with.

  6. I decided to rebuild an old image gallery site with PW. I know there's countless image-gallery scripts out there, but for my liking, most of them are too bloated. Also, I thought this was another good opportunity to dive further into PW-world.

    I'm keeping the old basic gallery structure: 95% of the galleries are in date-folders (monthly), like a blog archive. But I'd like to add some filter / search functionality, because there's just so many pics - when you come to the site and look for a specific subject, there was no way to do that on the old site.

    Q 1:

    How can I create a simple "search by image tag"? I want the results to list all images (thumbs) with tag x, and a link to the parent page.

    Q2:

    How would I most efficiently grab all tags from all pages, all images, and present it alphabetically (not necessary a fancy tag-cloud, but making sure I list each unique tag only once)? So when the user clicks on one tag link, he sees all image thumbs that have that tag on the results page.

    $p = $pages->find("images.tags~=$tag") works fine. I can explode("|", $p) to get a page-id array, but where would I go from here?

    A tag can be any anywhere, in various galleries (pages), and most pics have multiple tags. I'd like to group the results by page, so I guess I need to add 1-2 foreach loops, no? Can somebody help with some example code? I'm a bit stuck right now.

  7. I was confused too.

    The original images were in another folder on the same server. I entered the full path to the images. The original images are regular JPGs, with .jpg suffixes. The only thing that I could think of that may have triggered this strange PW behavior is: the image suffixes are uppercase: so, foo.JPG, not foo.jpg. (the uppercase suffix was generated from an old digital camera - but that didn't cause any problem whatsoever in the past)

    I really could have used this handy API function to move / add literally thousands of images with one handy script (I'm re-building an entire photoblog site with PW).

    There's nothing special about the images. Plain-jane, regular JPGs, exported from Photoshop with "save for web" menu. o_O

  8. To be more precise, in "page edit" view, I can view the thumbnails OK, but clicking on any of these, I just see gibberish like JFIF^^gExifII* (12iCanonCanon EOS 20Dg5'g5'Adobe Photoshop CS2 Windows2006:05:06 17:58:16"'02212 FN V     ^f0100nv 2006:05:05 19:37:162006:05:05 in the lightbox. The images themselves are fine, been online since 2006 on photo-galleries...

  9. I tried the example code above - everything worked fine.

    However, when adding images, the new filenames are all without .jpg suffix. They are all named "image.___" instead of "image.jpg".

    The originals (on the same server, in another folder) have .JPG (uppercase) suffixes. Does that have anything to do with it?

    Anything I can do to keep the exact same image-names when creating pages and using $p->images->add('foo/blah.jpg') ?

    The browsers display the images OK, but I'd rather keep .jpg suffixes (upper- or lowercase) instead of .___

  10. I never installed a custom admin theme. I have 2.3.0 installed. site/templates-admin/default.php shows this:

    /**
     * ProcessWire 2.x Admin Markup Template
     *
     * Copyright 2010 by Ryan Cramer
     * Teflon Theme 2011 by Soma Philipp Urlich
     *
     * @modified 2012-08-29
     * @version  1.0.3
     */
     

    I just checked in ModulesManager: filter by Admin Themes: status: - (none installed)

  11. I ended up adding this bit of CSS at the bottom of site/templates-admin/styles/ui.css:

    #submit_save_copy {
      visibility: hidden;
      display: none;
    } 

    Bottom save button stays, the top one disappears.

    Or you could add another custom .css and include it in site/templates-admin/default.php:

    $config->styles->append($config->urls->adminTemplates . "styles/custom-ui.css");

    Perhaps another workaround would be to make the top button just an #anchor link to jump to the bottom.

  12. Thanks.

    I think I found a solution, although I'm baffled why this should interfere with a simple GET form request...

    I renamed the home page (id 1). It used to be "home-sweet-home", and I renamed it to the default "home". I tried it again, and now it all works as it should.

    Well, not quite. I changed the selector to use LIKE queries, in order to also find partial terms, e.g. a word that appears in the site, is "Zwetschgenbaum" (plum tree in german). If I searched for "Zwetschge" (plum), I didn't get any results. I changed ~= to %= et voilà. The site is quite small (maybe 3 dozen pages), so any speed disadvantage is probably only in the milliseconds range (if at all).

×
×
  • Create New...