Modules Directory

[ryan]

@Pete: thanks I've fixed the created/modified date bug.

@Soma and @Apeisa: I'm confused about the best way to solve this. Just adding the callback var? I guess I'm not familiar with this technique. Since it's probably not safe to just echo back a GET var, what sort of filtering/sanitization should I do to it? I will get this working tomorrow morning.

[apeisa]

Soma: using php cache would be pretty much identical in speed, no difference. Implementation is much cleaner though with JSONP.

Ryan: you can be pretty strict - If I remember correctly jquery uses only numbers, but I think it would be good to use same sanitizing than pw pagenames have. Actually you could even hardcode it, but that would make it harder to use using jQuery's callback (since it always adds random stuff there).

http://www.michaelhamrah.com/blog/2010/02/using-flickr-and-jquery-to-learn-jsonp/

[Soma]

What apeisa said -

[ryan]

Thanks for the info. That's easy to implement, so I went ahead and added it now and will read more tomorrow. Soma let me know if this does what it's supposed to? If you include a 'callback' get var, it just echos it back (after pageName sani) in the format you mentioned in the earlier message.

[Soma]

Thanks Ryan it works!

Like this it can be used with a callback. Not sure what about jQuery adding it's own with random number and =timestamp, but using data: {} to overwrite it works.

function callback_json(data){
console.log(data);
}
$(function(){
var $res = $.ajax({
	url : "http://modules.processwire.com/export-json/admin-hot-keys/?apikey=pw223",
	dataType: 'jsonp',
	data: {callback : 'callback_json', 'of' : 1 }
});
});

[JeffS]

The modules directory is a really nice addition. Thanks for the hard work and also a big thanks to the module creators.

@ryan - Regarding the link out to the forum topic (the module), I ask that you consider creating a child forum for each module since pointing to a topic becomes a frustrating experience since the conversation tends to end up "all over the place" versus within specific topics. Not sure if your structured for that though.

[Pete]

The problem with that is that we will end up with thousands of subforums over time

[Adam Kiss]

@ryan - Regarding the link out to the forum topic (the module), I ask that you consider creating a child forum for each module since pointing to a topic becomes a frustrating experience since the conversation tends to end up "all over the place" versus within specific topics. Not sure if your structured for that though.

The problem with that is that we will end up with thousands of subforums over time

But there is always way to do this;

Imagine following forum structure:

- Modules support
 - [modules groups subforums]
   - [modules subforums]
     - support 'tickets'

Now, this would be a bitch to navigate through; however, a clear link from modules detail would solve this (and take you straight to modules forum].

---

Of course, if the problem is in the sheer size of the forums, that's a different story... But as Ryan uses to say: disk space is cheap.

[Pete]

Most forums would have one topic though so what's the point in that? I get that a few have more discussion but it seems like overkill to me.

[Adam Kiss]

Not to have big eyes, but I think the traffic will pick up, I think... So will support time.

--anyway, you're the forums admin

[Pete]

Yep, exactly so I'd have to manually create a new forum for each new module

[ryan]

I don't think it's practical for us to maintain one board per module, nor do I think any major forum software is designed to scale boards rather than topics. But I understand the desire behind the request -- longer term there will be some modules that need more than just a forum thread. In those cases, I would suggest that the module author setup their own forum or link to a GitHub support/issues page or something like that. In the modules directory, we just ask for a support/forum link. It doesn't necessarily have to be in processwire.com/talk/.

[Adam Kiss]

Yep, exactly so I'd have to manually create a new forum for each new module

Oh, I see. Super impractical. Thumbs up for laziness.

J/K

I don't think it's practical for us to maintain one board per module

But it would be awesome! Imagine how the devs would love the PW, if we gave them a way to manage support tickets!

Of course, you can do that on github easily.

[Nico Knoll]

I guess with Processwire you can give them another way to handle them

[Pete]

ryan - can I request that more fields be searchable? For example:

• searching for "CSV" returns nothing, but I think it should return the Process Data Import module since it's in the summary text.
  
• assuming that that might be because of the 3 character limit on some search selectors, you would think that "ProcessDataImport" which is the class name would return a result also, but it only seems to search the title field which has spaces in between the words. In some cases the class name is quite different to the module title in the directory
  

I think that's all I spotted... for now

[SiNNuT]

I guess it would make sense to adjust the mysql settings to allow 3 (or even 2) character min word lenght. Or just use %= selector version. On the scale of the modules directory this would perform good enough i think.

( http://processwire.com/talk/topic/1544-bug-process-page-search/#entry13972 )

[ryan]

Strange, I replied to this yesterday and now don't see my message. I'm wondering if I forgot to hit post or something (or maybe I'm losing it?) Anyway I fixed this yesterday morning so searching for CSV should now work. I switched it to use '%' and added the summary, description, class_name and instructions fields to the search.

[diogo]

we just ask for a support/forum link. It doesn't necessarily have to be in processwire.com/talk/.

But would be nice if everything would be kept in one place.

We have also the tags. Maybe if each new module post defines a tag to be used when referring to it...

[ryan]

The modules directory has been updated so that it talks a lot more with GitHub behind-the-scenes. This provides the following new features for modules that are hosted at GitHub (which is the majority): 

• It keeps your module version up-to-date automatically. You no longer need to go in and edit your module listing to bump the version number. It performs this check on every GitHub repo linked by the directory, once per day. So once you update the version number in your module's PHP file (getModuleInfo), and have it committed to GitHub, that's all you have to do, as the directory will detect the change in a few hours. 
• When you add a new module, it is able to pull in most of your module's information automatically from GitHub after you specify the project URL. As a result, the add new module link asks for your project URL before anything else. 
• The directory now displays the contents of your README file at GitHub, and keeps it up-to-date automatically (checking it once per day). Because of this, you may no longer find it necessary to use the directory's built-in Extended Description or Instructions fields. I recommend that you have your README in either Markdown (README.md) or Textile (README.textile) format, which just looks better, but plain text is of course supported too. 

Hopefully this makes it a whole lot easier to keep your modules up-to-date in the directory. Please let me know if you run into any issues with it. 

Please note: Your module must have the same name as the repository. Meaning, if your repo is named MarkupTwitterFeed then your module must be named MarkupTwitterFeed.module. This appears to already be the case with all the modules in the directory, so I'm not sure this even needs to be called out, but figured it was worth mentioning just to be sure. 

[Soma]

They also drink beer? I guess they also talk about you? Be cautious with the NSA¡ (hey guys!)

[kongondo]

They also drink beer? I guess they also talk about you? Be cautious with the NSA¡ (hey guys!)

Uh?

Edit:

OK, now I get it

[WillyC]

it.does supports full duplex prism connection now ?

or no ?

[Soma]

Ryan I noticed some with the module version it takes from github module.

For example LanguageLocalizedUrl module has "0140.1.1"

[Martijn Geerts]

I don't think it's an error, LanguageLocalizedUrl was build far in the future.

[ryan]

Thanks Soma, I've fixed that regex so that it ignores comments on the same line. I'm still seeing a few issues with Nico's module versions since they are using a different format from all the others, but not sure there is anything I can do about that yet.