ryan

I agree, this is not something you need to worry about. Some unoptimized preg_replace's might be something to worry about, but not str_replace on any reasonable length of content.

I'm not sure about this one, I've not used xdebug. I will install at the next opportunity and see if I can duplicate it.

Right now this one isn't hookable, so the only way is by modifying the markup returned by ProcessField::executeEdit. That's not a very desirable way to do it. I will plan to make this one hookable when I get back to the office after the holiday. Following that, it should be easy to hook into it and I'll post an example.

Another route is that you can grab the process module that you want and just execute it on your own without PW admin. Depending on which one you are using, you may want to use ProcessController to execute it for you. But either way, it's easy to grab the output that way, whether from a site template or anywhere else. I can post an example when I'm at a computer again if you'd like.

I tried it out today and seems to work great! Definitely a nice tool for anyone that wants to work with HTML markup in their textarea field. Thanks Nico!

If I recall correctly, SimpleXML doesn't work with the properties that have colons in them. But you can fix that by replacing the colon properties with underscore properties in the XML data. So in this case, you'd want to add this line in the load() function: <?php public function load($url) { $this->items = new WireArray(); $xmlData = $this->loadXmlData($url); $xmlData = str_replace('dc:creator', 'dc_creator', $xmlData); Or you may be able to cover all the colon properties at once using a regexp like this: <?php $xmlData = preg_replace('{(</?[_a-z0-9]+)[_a-z0-9]+>)}', '$1_$2', $xmlData); What that does is convert properties like <dc:creator> to <dc_creator> so that SimpleXML will understand them and likewise you can access them in the module. Let me know if this works for you. I'm not in a place where I can update the source on this module today, but will plan to add something like the above soon. I don't know why the <comments> property wouldn't be getting parsed, as that appears to just be a string (URL). I need to test and experiment with that one to find out why.

Soma, thanks for testing this out. For the purposes of translation consistency between languages (especially with the default language), I think it's good to be able to see them all at once ... at least as a default. But I think it will depend on the use. Right now I also question how useful multi language fields will be in practice, especially since we recommend multi-language trees instead. But it's also one of those things we can't do without because we need page references to have language support. Otherwise, using page references would be a lot more work. But because I'm not yet sure how much people will be using these multi language fields beyond this, I think it's best to start simple with the UI, and build from it as the practical uses become more clear. An option for tabs and per-user are good ideas that I'm sure we'll implement if people start using these a lot. I'm having the same issue-it's a bug. Should have it cleared up soon. Thanks, Ryan

I haven't noticed any speed issues on the site here. There are all kinds of factors that can affect the speed at which a site loads, so best to track down what it is first. If the site loads quickly for one person and not another, chances are there is a network issue between the host and user, or there is a factor on the site where performance is affected by the users' software or hardware (i.e. JavaScript execution speed). If a site is consistently slow for most users then more likely the web host, server or the site itself and it's use of server resources. When browsing the site I monitored the request times in firebug and there is an above average 'wait time' between request and response on the page's URL. However, it's not something I would have noticed. But that may point to some heavy lifting happening at the server, whether in PW or any number of other factors. When it comes to PW, it will let you consume a lot of resources very easily, so you do have to take care sometimes, especially with larger sites. For instance a call to $pages->get('/blog/entries/')->children could load all blog entries if you didn't specify it with children("limit=n"). Likewise, siblings/next/prev functions are good to avoid on a page with hundreds of siblings. With great power comes great responsibility. PW will happily load up a few hundred or more pages, but it's not something you want to do if you don't need to because it will affect performance. And even when you need to, it's good to reduce the number of times. One way is by using the MarkupCache module, especially for things you are having to generate on every request. Likewise, the template caching is good to use in instances where you don't need to change something on every request of a page (ie don't need randomization or second by second updates). But my opinion is that it's best to use caching only after you've made your other code as fast as it can be and have made sure you aren't loading pages you don't need to. These are just general guidelines and aren't much of a consideration until things get big. This site is at a size (with several hundred blog entries) where some of these scalability considerations should be observed. But it may or may not be applicable in this situation. The site performs reasonably well for me and I would not have ever noticed it as slow. But then again, maybe I was the only one accessing it at the time. Anytime anyone wants me to look at your code for potential bottlenecks I'm happy to. Feel free to post in the forum or privately to me. Most issues that would affect scalability are simple to fix because PW is designed to really sing at the larger scale and just requires occasional tweaking to how you use the API.

Thanks Pete, I'll take a look at this and should be able to change the BG color. PNGs should be okay, as I think we've fixed something similar with PNGs in the past. GIFs are generally terrible for any kind of resize and I'd recommend avoiding them in any situations where you need to be creating size or crop variations. But I know it's not always a choice. Hopefully we can get the transparency working with them.

I agree this doesn't need the fieldtype at present since it could be designated as an input for the existing textarea. However, there's no harm in giving it it's own fieldtype. Some of the expansion potential may need it. Nico, if you want to make it PW 2.2 ready, look at the thread on module dependencies in the announcements board. The fieldtype+inputfield is a good 'requires' and 'installs' dependency to use with the new options. Though all are optional.

Very cool Nico, I look forward to trying this one out. My computer access is currently somewhat limited, but hope to try this in the next day or so. Thanks for your work on these new modules.

Looks great Nico, nice work! Seems quite useful now and lots of expansion potential too. My only suggestions would be to remove the 'permanent' from the getModuleInfo on the inputfield. And move the CSS/JS loaders from the fieldtype's sanitizeValue method to the inputfield's init() or render() method. Reason for this is that fieldtypes are supposed to be independent of interactive input, whereas that's what inputfields are for. Otherwise looks great.

I don't see any issues there, looks like a good solution to me. You could shorten it even more like this: $last = $page->parents()->append($page)->filter("bkgimage!=")->last(); Also, just in case none have a bkgimage, you might want to add an if() before the output: if($last) echo "...";

Thanks everyone, hope that you had a great Christmas!

Sorry I missed this in the instructions (will update later) bit this module currently requires the 'full' not 'basic' calendar. So you'd need to replace basic with full in your URL. It looks to me like your full has read access disabled. Try with the example feed if you want.

Really beautiful work Nico. This may be the first full-blog site in PW and its also one of the nicest Blog sites that I've seen, ever. I'm very proud to see this running in ProcessWire.

Hope that you have a Merry Christmas, a Fine Festivus and a crazy New Year! I'm actually hoping to wrap up PW 2.2 on the 31st of December, so if anyone gets bored over the holidays, please help me test. I would have sent you all a card, but don't know anyone's address. So I took a photo of it.

Given a Google Calendar XML feed URL, this module will pull it, cache it, and let you foreach() it or render it. Download at: https://github.com/r.../MarkupLoadGCal USAGE The MarkupLoadRSS module is used from your template files. To use it, you get a copy of the module, tell it what URL to load from (with the load method), and then execute a find() query with a selector string. It works basically the same as a $pages->find("selector string"). <?php $cal = $modules->get("MarkupLoadGCal"); $cal->load('http://calendar XML feed'); $items = $cal->find('from=2011-12-1, to=2011-12-31'); foreach($items as $item) echo "<p>{$item->title}</p>"; To get a Google calendar URL, you would go into your (or another) calendar on Google and click to the calendar's settings. At the bottom of the screen, you will see a section called "Calendar Address" with XML, ICAL, and HTML. Copy the XML address, and use that with this module. If you just want one to test with, use the one from my examples below: http://www.google.co...com/public/full Note: you must use the 'full' not 'basic' calendar from Google Calendar. You can identify if you've got the right one because it will end with 'full' rather than 'basic', as in the URL above. Selector Properties The selector properties you may provide to find() are: from: Starting date in any common date/time format (or unix timestamp). to: Ending date in any common date/time format (or unix timestamp). keywords: Keyword(s) to search for in the Google calendar events. limit: Max number of items to load (default = 100). sort: May be 'date', '-date', 'modified' or '-modified'. html: Set to '0' if you don't want the event description in HTML. The find() method will return the found items. You can then foreach() these items to generate your output. A render() method is also included with the items which provides some default output, if you want it. Calendar Item (Event) Properties Each calendar item has the following properties: title: The title of the event description: Detailed description of the event (in HTML, unless disabled) location: Where the event will take place author: Author of this item from: Timestamp of when the event begins to: Timestamp of when the event ends dateFrom: Formatted date string of when the event begins dateTo: Formatted date string of when the event ends See the module file for additional configuration options. EXAMPLES Example #1: Simplest example <?php // get the calendar module $cal = $modules->get("MarkupLoadGCal"); // set the feed URL: may be any google calendar XML feed URL $cal->load('http://www.google.com/calendar/feeds/3icgo6ucgvsf6bi5orld9moqqc%40group.calendar.google.com/public/full'); // find all items for December, 2011 $items = $cal->find('from=2011-12-1, to=2011-12-31'); // render items using built-in rendering echo $items->render(); Example #2: Rendering your own items <?php $cal = $modules->get("MarkupLoadGCal"); $cal->load('http://www.google.com/calendar/feeds/3icgo6ucgvsf6bi5orld9moqqc%40group.calendar.google.com/public/full'); $items = $cal->find('from=2011-12-1, to=2011-12-31'); foreach($items as $item) { echo " <h2>{$item->title}</h2> <p> <b>Date From:</b> {$item->dateFrom} (Timestamp: {$item->from}) <br /> <b>Date To:</b> {$item->dateTo} (Timestamp: {$item->to}) <br /> <b>Location:</b> {$item->location} <br /> <b>Author:</b> {$item->author} </p> {$item->description} "; } Example #3: Finding Keywords <?php $cal = $modules->get("MarkupLoadGCal"); $cal->load('http://www.google.com/calendar/feeds/3icgo6ucgvsf6bi5orld9moqqc%40group.calendar.google.com/public/full'); $items = $cal->find("from=Aug 1 2011, to=Dec 1 2011, keywords=Eddie Owen"); echo $items->render(); ADDITIONAL INFO Options See the module's class file (MarkupLoadGCal) for a description of all options in the comments of the $options and $markup arrays at the top of the class file. Handling Errors If an error occurred when loading the feed, the $cal will have an 'error' property populated with a message of what error occurred: <?php $items = $cal->find("..."); if(empty($items) && $cal->error) { // an error occurred echo "Error! " . $cal->error; } $items will be blank if an error occurs, but it will always be of the same type, so it's up to you whether you want to detect errors. If you don't, then your calendar output will just indicate that nothing was found. Cache By default your calendar queries are cached for an hour. You can change the cache time by setting the $cal->cache property to the number of seconds you want it to cache. --- Edit: Added note that you must use the 'full' google calendar feed rather than the 'basic' one.

I see what you mean. Well the good news is, they've fixed this in PHP 5.4 and given us the JSON_UNESCAPED_UNICODE option. But nobody's running 5.4 yet (it's in RC3). Sorry to send you on a wild goose chase, but I'm thinking it may be best to hold off on the cache field in your situation. Meanwhile, I'll keep an eye on alternate encoding methods to see if there's any other approaches we might use, at least until PHP 5.4 is mainstream.

You could sort by templates_id or parent_id, but so long as you want the results to be keyword relevancy sorted, I think you'd want to exclude a sort parameter and break it into two queries: <?php $limit = 50; $searchFields = "title|body|summary|headline|fakta"; $matches = $pages->find("$searchFields~=$q, limit=$limit, template!=links|admin|redirect-overview|redirect-url"); if(count($matches) < $limit) { $matches->import($pages->find("$searchFields~=$q, template=links, limit=$limit")); } You may also want to create a new field of type 'Cache' to combine your title, body, summary, headline and fakta fields. Call it 'keywords' and add it to your templates being searched. Then you can just search "keywords~=$q", and it may offer some performance benefit (at the cost of database size). I didn't understand the "template!=," part of your query. I'm not sure that does anything since a page can't exist without a template. Also, the "template!=admin" is not necessary unless the user has access to edit pages in the admin. What I mean by that is that the admin pages may show up for you because you are logged in, but those pages won't show up for other users of the site. You may already know this and just don't want those pages to show up even for you, but just wanted to mention it just in case.

The query in question is the first one executed by PW and this is what you'll see if there's a DB connection error. That's not ideal, and I'm not sure how I missed that error check the first time around–I'm updating the Database class to detect connection errors and throw a more appropriate error message. That way we can see exactly why it can't connect.

Thanks guys, let me know how it works for you. I like your ideas here, good thinking! Perhaps we just maintain another section of modules that represents the uninstalled list. At the moment I'm a little scared of an "install all" in the same request, but perhaps I shouldn't be–definitely something to think about and perhaps implement in the future.

See here: http://processwire.com/talk/index.php/topic,159.0.html If you can't change your mysql settings, you can also use the [slower] %= selector operator rather than the *= and that will support words of any length.

I don't know much about Magento or what the SOAP client modules are. I have a strong preference for services built around HTTP/REST rather than SOAP. But so long as it's providing the services in some form, that means that it's probably a reasonable task to integrate. Magento also seems like a pretty solid system. Though admittedly, I've tried to install and use it before and found it a little overwhelming... Drupal/UberCart turned out to be a better fit for what I needed. But I think Magento is probably stronger overall. Let us know what you find and how it goes.

If using $page->parent in a string context, it's actually going to resolve to the ID. But I think it's better to be clear about what property you are checking. I recommend doing this: if($page->parent->id > 1) The homepage always has an ID of 1 and that's a factor you can count on in PW.