ryan

Nice, I think that's a definite improvement. I also think it would be just fine to not have any red background over there–it's a great looking admin theme either way. But I understand the purpose of the red is weight and balance, so can see why you want the color in the sidebar – it anchors the right side, sets the boundary and carries some weight to balance the sidebar with the content area. From that standpoint, I think your solution (with the search box background) is a good compromise. Thanks again for your great work with this admin theme!

Looking great Nikola! For debug timer, you might also try giving it a name just in case it's getting confused with another, like this: <?php Debug::timer('futura_timer'); // 1. start a new timer called futura_timer // do a bunch of stuff echo Debug::timer('futura_timer'); // 2. echo how long it took // do more stuff echo Debug::timer('futura_timer'); // 3. Echo how long it took (since timer started, step 1)

That's correct, and that would be the simple fix in this case. But because this particular module isn't singular (i.e. a new instance is created whenever you load the module) it would have to keep track of how many instances of it are running (via a static variable in the class).

Here's a couple examples. This first one grabs 'ProcessLogin' and places the output in $content: <?php $process = wire('modules')->get("ProcessLogin"); $content = $process->execute(); Here's another example. This one uses ProcessController, which will take care of access control and matching URL segments to functions in the Process module. This is the preferred way to do it in most cases (specific to Process modules only): <?php $controller = new ProcessController(); $controller->setProcessName('ProcessLogin'); $content = $controller->execute();

It may be better to come in with a 'before' hook and as the class attribute directly, rather than doing a preg_replace. But I don't know the full context here so can't say for certain. Can you hook in before it? i.e. $this->addHookBefore('ProcessPageEdit::executeSave', $this, 'myExecuteSave');

Thanks for the log. The function nesting looks right to me. I can follow the path of functions in the log and it looks as expected, so I guess that means we just need a higher function nesting level than what xdebug provides by default. I would bump it up to at least 200.

You should be able to hook InputfieldPageName::render, but note that it will return markup (and should just be the <input /> tag). If you want to modify some attributes from it or something, then you'd want to hook in before(render). If you want to modify the returned markup you'd want to hook in after(render).

Nice work Nicola! Another beautiful and fantastic admin theme–looks great! I like the design, colors, layout, sidebar, footer, and it all flows very nicely. Thank you for taking the time to put this together! A few questions/suggestions/ideas: 1. I'm not sure I understand why there is a headline in the sidebar that says "sidebar"? Is this to make sure I don't confuse it with the footer or masthead? ;D just kidding, but was mainly wondering if it might not be necessary? 2. Depending on the number of buttons someone has in their admin, they may run out of space in the top nav–a good solution might be to move the label "you are logged in as ..." into the right side of the bar below it (the breadcrumb). That's just an idea. It works great how it is, but just wanted to point out that many people may have more pages in their admin root than what will fit up there (depending on screen width). 3. The last "s" in "Process" of the ProcessWire logo appears to be slightly cut off. Though I'm viewing it away from my desktop so might be this computer too. 4. I'm seeing some strange behavior in PageList when clicking the "move" link... some extra rows show up when the tree is opened up a bit. Like in the default profile, if you click 'move' on 'Child Page Example 1'. 5. If you are interested, PW has a built-in debug timer in the file /wire/core/Debug.php. It works like this: $t = Debug::timer(); echo Debug::timer($t);

Got it–I see what's going on. I was thinking that 'config' was not yet set, but I should have read more closely as you said it was just $config->urls->admin and $page. PW has to start loading pages before it knows what the admin URL is, so that's actually something that happens after the modules are initialized. And that's the only $config->urls property that's determined after module initialization. So what I think you'll want to add a ready() function to your module and use that instead of init() here. PW calls that ready() method after it's determined the current page but before its rendered it. So it's pretty much the same as init, except that init() happens before any page activity (should you need to add a hook before such activity occurs). Whereas ready() is more appropriate in your case since you need to know things about the requested page.

I probably need to take a look to see what's up. Do you want to email the module file over to me? Email my first name @rc-d.net or PM it to me. Rest assured, all the $config vars should be available in any module's init() (and even __construct for that matter).

Where is the module being started/instantiated? I guess this question is only applicable if you don't have 'autoload' => true; in your getModuleInfo() function(). Specifically, I'm wondering if you are doing something like: $instance = new YourModule(); somewhere outside of ProcessWire's execution path, rather than $instance = $modules->get("YourModule"); ?

Thanks for submitting the issue, I will fix. Also I'd like to find a way to get Comments (and any multi-item properties) working as well, should be easy. The feeds I'd originally tested with were pretty basic and didn't have these extended properties.

So long as ProcessWire is booting your module, wire('config') should always be available. In fact, it's the first API var that ProcessWire sets and it's added to the API before $modules is even instantiated. And when init() is called, all API vars should be available (excluding the requested $page). So I'm not sure how you'd get a module init() to not have access to the $config API var unless the module was being initialized somehow outside of ProcessWire? Can you tell me more about the context where this is occurring?

Hey Adam, if I understand correctly, you'll want to do something like this: <?php $pages_with_image = $pages->find("whatever you use to find your pages"); $copy_to_path = '/some/suspicious/dir/'; // including trailing slash foreach($pages_with_image as $p) { $source = $p->image->filename; $target = $copy_to_path . $p->name . "." . $p->image->ext; copy($source, $target); echo "<p>Copied $source => $target</p>"; }

I would have made everything hookable the first time, except that hooks are somewhat of a compromise, so I take a more cautious route and add them as needed. Functions that are hookable don't execute quite as quickly as they would if they were native PHP. However, in this case where the functions are called once per request, it makes sense for everything to be hookable. It's the things that get called a few hundred times a request that I implement more cautiously. In this case, I'm just going to make all the form generation functions hookable so that you can hook directly into any one of those tabs very easily. While at it, I'll do the same thing with ProcessField.

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.