ryan

I agree with Adam on this that it is okay to use a different jQuery on admin and front-end. If the jQuery used on the admin is the version you want, then there is certainly no harm in linking to it and using it. But I wouldn't want you to run into a situation where you upgrade ProcessWire (which likewise installed a newer jQuery core) and for some reason it wasn't compatible with your site's jQuery code or jQuery plugins. The safest thing to do is to keep your own separate copy of jQuery in /site/templates/scripts/ (or wherever you place your JS files). It good insurance given that your web site and the ProcessWire admin are two completely separate applications with potentially different needs.

Let me know if that solution doesn't work... I haven't tried including ProcessWire from Drupal. Because many ProcessWire's class names are fairly generic, like "Page" and "User" and "Session", etc., there is a possibility for class name conflicts. This will be a non-issue once we standardize on PHP 5.3 which has built-in namespace support. But it is a possible issue right now when including ProcessWire from other apps. Another approach is to setup a template in ProcessWire to act as a web service, outputting an RSS feed, HTML snippet or JSON feed, and have your other CMS (or just javascript) pull in the data that way. This is the approach I have used in the past, though admittedly to pull data from WordPress into ProcessWire.

So far I can't seem to duplicate it. Tested in Safari 5.0.2 on OS X. Maybe I'm not catching it quick enough? I move the page with children, but it opens back up before I can even click on it again. Maybe I need to insert some javascript induced delays in there in order to reproduce. Or can you tell me if I'm doing it wrong?

One other possible workaround is to re-purpose the existing image description field. Setup a multi-image field and set it's description field to have 4 rows. Then assume that the first line is always the title, second line always the URL, and any remaining lines are the description. <?php foreach($page->images as $image) { $lines = explode("\n", $image->description); $title = trim($lines[0]); $url = trim($lines[1]); unset($lines[0], $lines[1]); $description = implode("\n", $lines); // now your $title, $url and $description fields are ready to use. } Like I say, it's a workaround, but it would solve this particular case. This could be improved upon, but this is just a simple example.

Hi Jim, You found a bug! It was in the Pagefiles class in the makeNew() function, which was returning a populated list when it should be been returning a blank one. I have fixed it in the latest commit. Thanks for finding this. https://github.com/ryancramerdesign/ProcessWire/commits/master Ryan

I've added the next() and prev() functions and properties to the Page class, so that you can now use them. I've updated the reference information here: http://processwire.com/api/variables/page/ Example: <?php echo "<p>The next page is: {$page->next->title}</p>"; echo "<p>The previous page is: {$page->prev->title}</p>"; ...but be sure to see the reference as there are more options and considerations (for large scale) on these kinds of functions.

Thanks for your report. What browser, version and platform did you notice this behavior in? I want to make sure I test in the right environment.

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.

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.

You are both right

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.

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.

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

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.

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.

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

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

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.

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...

Is there any possibility that two different artists will have the same name? (with different IDs at last.fm?)

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.

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.

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.

Great! glad that fixed it. I look forward to checking out your app!

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.