ryan

Wow that was quick – Thanks, great update! It seems to work well, but two issues I'm running into, at least on the default admin theme: Clicking the toggle button for the first time works, but throws a JS error. Clicking it a second time does not work. So you can switch to expanded view, but not switch back to tabs. The JS error is: "Uncaught Error: cannot call methods on tabs prior to initialization; attempted to call method 'destroy'." I did try to debug it a bit, but wasn't sure how to fix it. Not a bug per se, but the position of the toggle icon seems a little unusual at least in the default profile (see screenshot). Maybe there is something that works better across themes, not sure? Though let me know if you think there is an issue in the default admin theme CSS that needs tweaking. Thanks for your great work on this module. It's already one of my favorites.

WireArray implements PHP's ArrayAccess interface, so actually the something like $images[0] ideally would work. The reason for the inconsistent behavior is that images are indexed by filename, not by number. So $images['filename.jpg'] would be the actual ArrayAccess implementation. However, I think I could find a way to make it work by re-implementing the offsetGet() method in the Pagefiles and having it do a slice() to return a specific index. Thanks for reporting it!

Given that this piece is informational only, and not tied to any user input, hiding it with CSS or JS seems adequate. This one may be tricky to target with CSS since it doesn't have a defined id attribute. But I think you could do it with: #ProcessPageEditSettings .InputfieldMarkup:first-child { display: none; } You can put this in your own css file in /site/templates/styles/admin.css. Then edit your /site/templates/admin.php and put this at the top (after the opening php tag): $config->styles->add($config->urls->templates . 'styles/admin.css');

I'm really liking this module. Thanks for making this! I used it yesterday, all day on a multi-language site that I'm developing with 5 different languages. It has really made the interface a lot nicer to look at and use. It makes me think we should have this in the core. There are two things I think I'd personally add to it though: I'd make the tabs that have un-populated text a little different, perhaps a little faded or lighter text or something to indicate the empty state. Either that, or the populated tabs bold. I'd add an option to to switch between tabbed view and regular stacked view. The reason is that I anticipate clients have cases where they are translating and want to see the text in multiple languages at the same time. But overall tabbed view seems like a much better default than what we've got now. Has anyone tried this with Teppo's text version control module? I'm wondering if it would break that... will probably find out later today.

There are a few different ways to approach a multi-language website. The answer will depend on what multi-language solution are you using. If you are using the multi-language page names module native to PW 2.3, then you would have checkboxes on your settings tab that indicate whether the language is active or not. However, since you mentioned you have 2 different pages, I'm guessing you are using some other multi-language solution, but not sure which?

Just to confirm, the issue is, or is not, occurring in the latest dev version?

I would still like to resurrect it in PW2, but just haven't yet had the need for it in one of my projects. There are also some alternatives now we may want to look at too. But I would like to see a MarkItUp option in PW.

Chances are the text you've got is already entity encoded (like from TinyMCE), and the HTML5 validator is complaining about an ampersand somewhere outside of that. Can you 1) remove the entity encoding textformatter for that field; and 2) post the URL (or PM to Teppo and me if you prefer) so that we can see the full context?

Not sure you'll get a good reply on that just because I'm not aware of anyone else here using the Yii framework. However, if you think of your ProcessWire template files as regular PHP files (which is essentially what they are) you can easily include any other things that you want. I would start there and simply include() your Yii framework file in your template file and see how that works.

Thanks for finding it. Looks like a bug, but an easy fix that will be committed later today. I missed it because I'd changed my default search operator to %=, which doesn't exhibit the issue. What is the silver admin bar? Is this the AdminBar module or something different?

You need an Avatar one of these days Kongondo! If I recall, WillyC made you a pretty awesome one awhile back. Though if you like the anonymous man one, maybe we can at least dress it up a bit (perhaps a hat, ears, gratuitous lens flares or something?)

Don't forget that PW pages can act as a media manager. When it comes to inserting images into copy (like from TinyMCE) you can choose images from any other pages (see screenshot). Taken to the next logical step, you can choose to create a section of pages as a media library, should it suit your purpose. While there are some aspects of a media manager that may be beneficial, I've found the need for it to be null once you really get into the PW way of doing things… even on sites built completely around photos. If we were to add a media manager of some sort in the future, it would be primarily because people are likely to find and understand it more easily, not because it would be doing something you can't already do in PW.

Michael, it sounds to me like you want to use a web service to display a calendar. Is that correct? Or are you wanting to import the calendar to your site into pages? Since your goal is to display a table with the 5 next events, I think the best bet is to use an approach similar to the MarkupRSS or MarkupTwitterFeed module, which is to poll the web service, display the results, and optionally cache them for a period of time. I've not worked with caldav or baikal, so don't know the considerations there but most likely the approach you take would be the same in ProcessWire as it would be outside of it. Meaning, any PHP examples you find from the company providing the service should be applicable in ProcessWire.

Did you get any errors during installation? The 500 error you are getting there indicates Apache is most likely upset with something in the .htaccess file. But to double check, rename your .htaccess file to htaccess.txt (temporarily) to see if the 500 error goes away (I'm guessing it will). If it does, rename it back to .htaccess and then start commenting stuff out in the .htaccess file till you can determine what it is, starting at the top and working your way down. Focus on the parts that aren't surrounded by <SomeBlock>...</SomeBlock> sections first. Please let us know what you find. Chances are your web host has disabled some feature typically allowed in an .htaccess, and we just have to determine what it is and find an alternate. If it does not, please PM me a link to a PHP file on your server with <?php phpinfo(); in it.

Great site Nico. I'm assuming so that the images look sharp on high DPI displays (aka Retina displays). We do the same thing on processwire.com with several images where it counts, doubling the resolution and scaling down. Though not more than double. So a 960px to 240px would be more than necessary for any displays that I'm aware of.

I've not ever seen that particular issue. Though know that there was a sorting bug in a certain MySQL version (bug in MySQL not PW), so that would be something to look at. That's the only thing I can think of. Unrelated, but also be sure to get your PHP version up above 5.3 if possible.

It seems okay to me. I would double check that you aren't getting any errors by enabling debug mode. But if it works, I can't currently think of any problems with doing it.

Okay I think I've got a better idea of what you are seeing now. But it still looks like the request "http://mywebsite.com/en/sitemap.xml/" has a trailing slash. Though I'm guessing that's actually the second redirect and that the LanguageSupportPageNames module is issuing them. LanguageSupportPageNames is actually not meant to work with the trailing slashes turned off (yet). So in your case, I would go ahead and enable trailing slashes for your sitemap-xml template and try again. Meanwhile, I'll work to get LanguageSupportPageNames compatible with trailing slashes.

I've yet to come across a host that doesn't have iconv support. This one comes with PHP and the only way to remove it is to specifically disable it when you compile PHP. Sometimes when dealing with smaller hosts (or those running their own server/VPS) they disable everything they don't recognize. Since iconv is part of PHP's core distribution, it's not something a host should disable unless they are only hosting a single site that they know doesn't need it. Most likely LiquidWeb does have it enabled, but the VPS owner compiled PHP without it. I think the best thing to do here is to ask them to enable it, along with any other PHP core features they may have disabled. Though since your installer didn't report anything else, iconv may be all you need. I don't think ProcessWire uses iconv() anywhere other than the pageName sanitizer, so if you don't want to wait on the host, you could always try modifying that line to an alternate solution.

Thanks Horst. I can't come up with any theories on why that particular error would occur, and have never seen it anywhere else. So if it's not holding you up, I think I may wait a bit to see if anyone else reports the same thing.

Fieldtypes have a getInputfield() method that returns the Inputfield needed by that Fieldtype. So what Inputfield a Fieldtype uses is defined by the developer of the Fieldtype, not the user. Though the developer of the Fieldtype can decide that they might make that configurable to a limited set of other Inputfields that are known to be compatible. This is the case with the Page fieldtype, which is compatible with any Inputfield that is derived from InputfieldSelect. But that's kind of an exception, as the vast majority of Fieldtypes are married to a specific Inputfield.

Happy Birthday Roope! I personally don't like having arrays in GET variables (they are overly verbose and make ugly URLs). But if you want the MarkupPagerNav to keep arrays in their native GET variable state, you can tell it to by using the 'arrayToCSV' option and setting it to false. echo $mypages->renderPager(array('arrayToCSV' => false));

I don't think parenthesis affect the logic here. I like to wrap ternary blocks in parenthesis just for readability, containing it to a visual open "(" and close ")" to the statement. But I don't think ternary operators and/or parenthesis aren't the issue here. The original issue is that the poster was comparing an object to an ID, which was probably failing. Later it was followed up with one where "==" are being used to compare two objects. That's not an ideal way to compare page objects because that double equals goes in and compares all the properties of both objects. If they are two different copies of the same page, it will fail. The best way to compare pages is to compare the ID (per my post above). Though if one literally wants to compare that two objects are the same instance then 3 equals "===" should be used, since that will compare the memory pointer (efficient) rather than every single variable in the object (not efficient). But I recommend comparing only the 'id' property, just on the off chance that you've got two different instances of the same page. It's also easy to remember, always works, and adds clarity that you are dealing with page objects.

Beyond being a CMF/CMS, the goal of ProcessWire has also been to provide utility to PHP like jQuery does to Javascript. That means we accept PHP best practices as our best practices, rather than inventing proprietary, usually more complex and short lived alternates that do the same thing. It also means using very simple, yet tried and true PHP like functions and includes for code reuse rather than snippets, blocks, chunkers, snaggers, widgets, tagalongs, bangers or whatever concepts are being pushed out there. ProcessWire provides tons of structure when you want it to, and gets out of your way when you want it to as well. For me it means template files that rarely have much code in them (occasionally none), unless the output need is different from the rest of the site. Most of the site's markup gets generated either from a "main" output file, or from shared render functions. As a result, most template files tend to have limited or no markup and look like the example at the bottom of this post. It also means that I don't usually have more than 2-3 other PHP files, beyond the template files. See the template file structure section of this post for details on how I structure my template files–I've found this method to work best for me through several sites. The delegate approach and some of the others I've seen don't suit my needs as well, but seem to work very well for others. The Blog profile uses an MVC style approach that may appeal to those looking for lots of predefined structure, though I still prefer approaches that involve fewer files. For small stuff, the approach taken in the default profile (included with ProcessWire) is about as simple as it gets, even if it's not as elegant. But when it suits the need, I don't see any reason to shy away from it. Regardless of how you structure your site, the important thing is to aim for DRY (don't repeater yourself). home.php $body = renderSlideshow($page->features) . $page->body; $side = renderNews($pages->find("template=news, sort=-created, limit=5")); The example above uses the /site/config.php 'prependTemplateFile' and 'appendTemplateFile' options to include an _init.php (prepend) file that initializes variables like $body and $side with defaults, and a _main.php (append) file that outputs them in the predefined places within the context of an entire HTML file. The template files get executed in between those two and modify $body and $side as needed specific to the data and needs of the template and page.

Sounds like something is getting paginated that you don't want paginated. Add a "start=0" to your children() selector, i.e. <?php foreach ($pages->get("/article")->children('sort=-created, start=0, limit=5') as $articles) { ?> See the "side effects" section in the pagination documentation.