Jump to content

ryan

Administrators
  • Posts

    16,430
  • Joined

  • Last visited

  • Days Won

    1,449

Everything posted by ryan

  1. In the TinyMCE / rich text editor, that's true. Though only temporarily. PW1 would let you select images from another page in TinyMCE, and I'm going to do the same for PW2. You are the second person to ask for this, so that tends to push things ahead as a high priority, and this is a relatively small/simple thing to implement. This is handy for instances where you want to setup a library of images on some other page. Of course, via the api, any page can access any other pages images easily... so there are no such limitations in your templates.
  2. In your module, you can create an ___install() function, and an ___uninstall() function (if you want). Do your requirements check in the install function that is a public method in your module class. For instance: <?php class YourModule extends WireData implements Module { // .... public function ___install() { $v = explode(".", phpversion()); if($v[0] < 5 || ($v[0] == 5 && $v[1] < 3)) { throw new WireException("Sorry, your version of PHP is older than 5.3, can't install..."); } } // ... } Also see /wire/core/Module.php, which contains the interface for modules. Most of the functions are optional, so they are commented out and there just for documentation/reference purposes.
  3. Jim, actually I'm thinking Martin's talking about the next/previous sibling, rather than pagination. Though reading it again, now I'm not sure. Martin, can you confirm? Either way, I do need to add those next/prev sibling API functions.
  4. That's a very good question. I was just going to reply that you should use the next/prev page methods, until I realized I haven't yet implemented this part in PW2 (it us in PW1). Surprisingly, the need just hadn't yet come up in PW2 (at least in my projects). I will implement, hopefully today or tomorrow and then reply again with an example of how to use.
  5. Glad converting to double fixed it. I will update this fieldtype to use double instead. That's interesting how it came up with that number on it's own... I've not used mysql with floating point numbers very much, but it seems like a much more complex subject than I realized before. Good weekend reading material for me
  6. I can duplicate your result here. I think we must be running up against the bounds of what a default float field in MySQL will support. It looks like 6 digits max, whether before or after the point, from testing here. You could try changing it to a double from PhpMyAdmin, but I usually stick to a normal text field for lat/lng values, or for any longish floating point value that I don't need to use for greater-than/less-than comparisons in selectors. I may update this fieldtype's schema to use a double rather than a float, though I'm not positive even that will support the full scope of lat/lng values.
  7. Hi Jim, The purpose of Inputfields is to generate markup for inputs (and retrieve the resulting value). This is why they are separate from Fieldtypes. Since they were originally built just for the PW Admin use, I haven't made them configurable from a markup aspect. Though I do plan to change that, now that the utility of these Inputfields is expanding. Currently, there is only one markup generation method in most Inputfields, and that is the ___render() method. So you can extend any Inputfield, and just override the ___render() method to change the markup it generates. But I'm guessing it's not the actual Inputfields that you want to override so much as the container code generated by the InputfieldWrapper class (with it's jquery-ui classes and list items and stuff). The reason I say that is because the Inputfield types just generate the actual form inputs, like an <input ...> tag. Whereas InputfieldWrapper generates everything else. Until I can modify this class to make it's markup configurable, I would recommend styling the existing markup using the CSS classes in the comments at the bottom of the .module file as a starting point. But I think it will be relatively easy for me to make the InputfieldWrapper class have configurable markup, so it's something I can do quickly if you are interested. But I want to make sure that I'm understanding your needs correctly before I do that. If you just need to modify a single Inputfield's output or something, then we'll focus on that instead.
  8. The configuration option to set the precision of floats was specific to the Inputfield rather than the Fieldtype. Since the Inputfield is only used interactively (not in the API) the precision wasn't applicable to the API. That doesn't make a lot of sense, and I'm not sure why I set it up that way, but I just changed it. I moved the configuration stuff to the Fieldtype rather than the Inputfield. Now you should be able to set the precision and have it honored by both the API and the admin/inputfield. I think there was also an issue with the precision being ignored in some cases, which has been fixed as well. If you grab the latest commits, it should correct this. Please let me know if it doesn't, or if you run into any other similar issues. Some of these field types don't have many miles on them yet (like the Float one). Thanks, Ryan
  9. There was a request that I add an official thread for this module, so here it is. MarkupTwitterFeed generates a feed of your tweets that you can output on your site. When you view the processwire.com homepage and see the latest tweets in the footer, this module is where they are coming from. This module was recently updated to support Twitter's new API which requires oAuth authentication. modules.processwire.com page GitHub project page Usage instructions
  10. If you turn on template caching (Setup > Templates > Your Template > Advanced > Caching), I would set it to at least 1 hour (3600), and up to 1 day (86400). Just note that template caching is always turned off for you (only) when you are logged in, so you won't observe the effect of template caching unless you logout, or try from another browser/computer that isn't logged in.
  11. I also thought that highlighter looked pretty interesting, at least in concept. But it's one of those ideas where it's kind of hard to predict whether people will actually use it.. I'm not sure I would. Though the last time I said that was in 2007 at SXSW when they introduced Twitter...
  12. Is there any possibility that two different artists will have the same name? (with different IDs at last.fm?)
  13. I think you've got the right approach there, checking to see if pageName returned something blank. Very creative to use urlencode here. Using that same approach, you could also try md5($headlinerName) rather than (or in addition to) urlencode() as a shorter option... it will always be 32 characters regardless of the title's length.
  14. Wow, good question. It looks like PHP iconv has no equivalent conversion to ascii for those characters (understandable). Are there any other properties to that artist that could be used as a name... for instance their last.fm id or something like that? The "name" field can be anything, it doesn't necessarily have to be related to the title. If the ID numbers you are getting out of last FM are unique per artist, then it may be best just to use those... that would solve these cases of titles that are not translatable to ascii.
  15. Wow, awesome site!! Please let me know when this is "officially" online so that I can add it to the "sites powered by ProcessWire" page (if you don't mind -- I would be proud to link to this). You are right that it will load faster directly from a flat XML file. But if you create the XML output as a template, and turn on template caching then the difference would be negligible in the majority of cases. Where you'll have an advantage with your current approach is if the size of the XML output becomes so large that it can't all be held in memory at once... then you would have to write it to a file as you are doing now. However, I think you'd have to be in the thousands of pages before that would become the case. But if you don't mind recreating the XML from the admin every time you need to update the site, then it doesn't matter which approach you use. And your current approach does give you a potential nice workflow where you can make several changes before actually publishing them.
  16. Great! glad that fixed it. I look forward to checking out your app!
  17. I think I might know what the deal is. Try changing this line: $gigNameUrl = $wire->sanitizer->pageName($gigName); To this: $gigNameUrl = $wire->sanitizer->pageName($gigName, true); The second param "true", tells it to beautify (remove doubled chars and stuff). I forgot that the Page class uses that beautify option, so adding the "true" will ensure it's consistent in how it generates the page name. I bet this will fix the problem.
  18. Actually this is a duplicate entry error. I've setup MySQL to maintain a unique index between the page name and the parent_id, so that it's impossible to have two pages with the same name under the same parent. So the error you got here is from MySQL telling you that you are attempting to insert a page with the same name as one that's already there. Can you check if a page named "project-decay-nor-w-viisikko-fleshpress-1751059" is already there?
  19. Using name may be better just because it can only consist of these ascii characters: -_.a-z0-9. Meaning it's easy to validate, and easy to use as a urlSegment or GET variable. If all of your artists are in one dir, then you can also change your selector to: $support = $wire->pages->get("/artists/$name/"); There may not necessarily be any advantage to doing that over what you were doing, but it's just an alternate approach. Nothing wrong with coding while ill, just drink Dayquil rather than Nyquil (I speak from experience). (if they have that cold medicine in Finland?). Or better yet, coffee, or both.
  20. For something like this, I usually prefer to use the name field over the title field just because there's no worry about escaping quotes, whitespace, etc. But if your $supporter is never going to have double quotes in it, then you are probably fine to use title. Speed wise, I don't think you are paying any penalty by using the title--it should have a full index in the DB, which will keep it just as fast as name. However, I do think you could improve this by only doing one call to $pages->find(). In addition, yo should probably use $pages->get() rather than $pages->find() since your $supporter_pages[] = $support seems to assume that $support is a Page rather than a PageArray. Here is what I would change it to: <?php $support = $wire->pages->get('template=artist, title="' . $supporter . '"'); if($support->id) { $supporter_pages[] = $support; } else { $support = new Page(); ... } If you want to use the name field instead of the title field (though it may not be necessary), you could do this: <?php $name = $wire->sanitizer->pageName($supporter); $support = $wire->pages->get("template=artist, name=$name"); ...
  21. If you want, feel free to email me the script and I can track it down more easily being able to see it all.
  22. Is there a $gig->save(); somewhere? (to make sure the change was saved)
  23. The syntax in your second example is correct. When you say it didn't work, can you describe further? Was there an error message?
  24. To get it working temporarily, you can set the value of $rootURL in /index.php manually to the correct value: "/racconti-erotici/". But I can see that the problem is that rootPath and DOCUMENT_ROOT are not consistent with each other. They should be referring to the same path, and instead they are referring to different paths. There must be some aliasing going in with the paths at the server side. We've seen this happen in another case, so I think it's something that ProcessWire needs to account for rather than an actual problem at the server. Now to figure out a solution...
×
×
  • Create New...