-
Posts
2,007 -
Joined
-
Last visited
-
Days Won
21
Everything posted by dragan
-
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...
-
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. 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
-
ProcessWire conference, Switzerland (central europe)
dragan replied to Soma's topic in News & Announcements
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.
-
Sure: http://dnik.ch/050506/
-
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)
-
Somewhat related: http://37signals.com/svn/posts/1061-why-we-skip-photoshop
-
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
-
There is lots of reading material: http://processwire.com/api/ http://processwire.com/videos/ http://processwire.com/talk/forum/13-tutorials/
-
ProcessWire conference, Switzerland (central europe)
dragan replied to Soma's topic in News & Announcements
we'll just rent a nice chalet and have Fondue + Kirsch, then... -
ProcessWire conference, Switzerland (central europe)
dragan replied to Soma's topic in News & Announcements
too cold for beer! -
ProcessWire conference, Switzerland (central europe)
dragan replied to Soma's topic in News & Announcements
I'd be very interested as well! -
How to Access Same Website Locally and Non-locally?
dragan replied to fastpurplemedia's topic in General Support
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).
- 6 replies
-
- no results found
- GET parameter
-
(and 2 more)
Tagged with: