-
Posts
2,007 -
Joined
-
Last visited
-
Days Won
21
Posts posted by dragan
-
-
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
-
Funny how small this planet is... I grew up in Regensdorf
Gretag doesn't exist anymore, it was liquidated in 2004 (now the buildings are rented to various new companies).
-
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"]);
-
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...
-
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...)
-
Excellent! Thanks so much.
-
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.
-
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.
-
-
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
-
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...
-
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 .___
-
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)
-
-
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.
-
links on the "our work" page result in 404 errors... o_O
-
ahem, nothing to see here... I'm an idiot (post removed)
-
There is lots of reading material:
-
we'll just rent a nice chalet and have Fondue + Kirsch, then...
-
too cold for beer!
- 1
-
I'd be very interested as well!
-
not sure i understand... try modifying your HOSTS file (locally).
-
-
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).
Image tags
in API & Templates
Posted
Turns out the hoster actually IS using mod_sec and blocks certain URLs; got whitelisted now after talking to support.
The internet isn't what it used to be...