Leaderboard
Popular Content
Showing content with the highest reputation on 04/16/2012 in all areas
-
In a current project it became necessary to implement more extended image manipulation functionalities as I needed to fix image orientation of photos where the orientation data was just stored in images's exif data set. As it was just one more manipulation among several other's the ImageSizer was already taking care of, I thought it would be nice to be able to extend the native ImageSizer class by individual methods. But as I - of course - didn't want to change core files and the ImageSizer itself isn't a “module” that seemed hard to achieve. But after I did some research, I found a solution using an instance of ImageSizer encapsuled within a module using magic methods to direct native method calls to the ImageSizer while providing extended methods from the module itself. It's far from perfect. The code is still messy and I just added methods to check for orientation data, fix orientation and therefor of course image rotation and flipping. Haven't been testing everything yet, but I uploaded the module to github. Could be useful as a starting point. https://github.com/o...geSizerExtended It is used the same way as the original ImageSizer: $sizer = new ImageSizerExtended($path); $sizer->method();1 point
-
Hi, i've this field: NAME LABEL TYPE NOTES TEMPLATES bandiera Flag TextLanguage 1 I also did a search on the forum and the API section but could not find answer, is I use echo $page->bandiera; I will only output the value (italia for example), I would rather have as output LABEL: VALUE (Flag: Italia for example) thank u...1 point
-
Welcome to the forums Buothz! Good question. Here's how you could do it: $language = $languages->get("spanish"); $field = $fields->get('bandiera'); $label = $field->get("label$language"); echo "$label: $page->bandiera"; If you want a specific other language replace the first line above with this: $language = $languages->get('italia'); . Edit: Code fixed first example and changed to make more sense. (Soma)1 point
-
If I'm understanding the need correctly, it's not that hard to do with Google Maps v3 API. Here's a few examples that uses the MapMarker fieldtype: http://www.di.net/almanac/firms/ http://www.di.net/almanac/buildings/tallest-buildings/ http://www.di.net/almanac/buildings/art-museums/ These use the stock Map Marker fieldtype, so that each item (firm, building, art museum, etc.) has a Map Marker fieldtype. Then the index page with the big map cycles through all the children and adds the coordinates for each: $js = "<script type='text/javascript'>RCDMap.init('map', 0, 0);"; foreach($page->children as $item) { $js .= "\nRCDMap.addMarker('{$item->title}', '{$item->url}', '{$item->map->lat}', {$item->map->lng});"; } $js .= "</script>"; echo $js; The above uses my RCDMap class. Feel free to grab it if you find it helpful. You'll want to view the source on any of those URLs above to see how it works. http://www.di.net/almanac/site/templates/scripts/RCDMap.js Note that you'll also need jQuery and Google Maps in your <head>: <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js" type="text/javascript"></script> <script type="text/javascript" src="http://maps.google.com/maps/api/js?sensor=false"></script>1 point
-
Looking good Adam! I replied in Diogo's thread something that may be more applicable here: That link mentions referencing other pages with a tag. So one way to make tags extendable is by tying them to a page and rendering the output of the page. I think there are cool possibilities there, but don't think it's enough... If we're going to have an extendable tags system, it probably needs to be a module that other modules can add hook functions to, and they become tags. It would utilize the existing hook system. That way another module could add a {subpages} tag by doing something like this: public function init() { $tagscript = wire('modules')->get('Tagscript'); $tagscript->addHook('tag_subpages', $this, 'subpages'); } public function subpages($event) { $page = $event->arguments[0]; $children = $page->children(); $out = "<ul class='subpages'>"; foreach($children as $child) $out .= "<li><a href='{$child->url}'>{$child->title}</a></li>"; $out .= "</ul>"; $event->return = $out; } As for format of tags, I think it may make sense to use the existing selector format already used elsewhere in PW. There is already a built-in parser for it, it would be consistent, and it could pass the params in the selector directly to the tag event in the $event->data array. So an example of a tag would be this: {subpages: limit=10, include=all} ...and the tag_subpages function would retrieve them like this: $limit = 0; if(isset($event->data['limit'])) $limit = (int) $event->data['limit']; Further along, we'd also want to be able to do this for markup independence: {subpages: limit=10, include=all} <li><a href='{url}'>{title}</a></li> {/subpages} I have a parser that does that that I was working on awhile ago. Might be time to resurface it.1 point
-
Here's some PW (Dictator) tag stuff from the past. Stillmovingdesign mentioned CSS classes, so thought maybe some would be interesting. Dictator CMS (the one before PW) used tags like this for images, except that each image could be assigned a tag directly in the editor. Then you would type the tag (like "image" for example) in any text field like this: {image} If multiple images had the same tag, it would display all of them. Any image could have multiple tags too. If you wanted to assign a CSS, class, you'd do it like this: {image}.class So you could create a CSS class like "left" and "right", and display an image like this {image}.left If you wanted to grab an image from another page, you'd do this: {/some/other/page:image} You could actually do the above with any field. So if you wanted to display the 'body' field from some other page, you could use this tag: {/some/other/page:body} While I'm less keen on tags nowadays, I actually kind of miss enabling an editor to use tags like this in their text fields. So am glad to see Diogo's module as a step in that direction. If people like being able to do this, we could always bring back some of the older tag options like above.1 point
-
To get things started in this forum, I'm going to post some of the Q&A from emails that people have sent me. That's a good question. For most cases, I would not try to create a different page structure for years/months because that's more work and it invites the possibility that the links will change over time as you move pages to archive them. After using different strategies over a few years, I think it's better to have a single container page under which all news items will be placed, permanently. Then set that container page's default sort to be by date, so that newer items always appear first. From there, the news page should focus on the newest items, and provide links to past news whether by pagination, month/year links, etc. In this respect, you can treat a page in PW2 in the same manner that you would treat a channel in EE2. There is no problem with scalability… PW2 will run just as well with 10k+ subpages as it would with 10. When following that suggestion, these are the only scalability considerations: 1. You may occasionally have to consider the namespace with the URL "name" (aka "tag" in PW1) field. For example, if you have two news stories with substantially similar headlines, you may have very similar URL name fields. But ProcessWire will enforce that namespace, so it's not going to let you create two pages with the same name under the same parent. What that means is it'll make you modify the page's URL name to be unique, if for some reason it's not. I'm talking strictly about URL names, not headlines or anything like that. 2. When dealing with news stories (or any place that may have a large scale of pages), you want to pay attention to how many pages you load in your template API code. If you are dealing with 10k news stories, and load them all, that will slow things down for sure. So the following applies: Avoid API calls like this: 1. $page->children 2. count($page->children) Instead, use API calls like this: 1. $page->children("limit=10"); 2. $page->numChildren $page->numChildren is something that ProcessWire generates for every page automatically, so there is no overhead in calling that, like there is in count($page->children). But if working at a smaller scale, it doesn't really matter what method you use. The most important thing to remember is just to use "limit" in your selector when potentially dealing with a lot of pages. That applies anywhere, especially when making things like search engines. So when you want to support unlimited scalability, these are the functions where you want to place limits: $page->children(...) $page->siblings(...) $page->find(...) $pages->find(...) The other reason someone might like archiving to year/month is because it makes it easier to link to since you could just link to /news/2010/04/ for instance. But it would be a fairly simple matter in PW2 to make your template look for "month" and "year" get vars, or a URL segment, and produce results based on those… See the other topic in this forum for one way that you might do that.1 point
-
Hi Martin and welcome to the forums. $s->createdUser right thing here, but it returns user object (which is actually just a regular page like others), so $s->createdUser->name should return user's login name. Gotta mention here, that user template (=user profile) is also just a normal template, so you can add more fields there too (like firstname, lastname, phone number, image, address etc..) and use those values just as easily: $s->createdUser->firstname1 point