ryan

Shopify is another decent payment solution to integrate with ProcessWire. Shopify is pretty much self running and easy to setup (they host it), but has a feature called post order hooks that you can have ping your defined URLs (in your PW installation) with JSON data about a completed order, etc. This makes it fairly simple to create or modify user accounts or other pages based on the results of a store transaction.

I don't see anything wrong with #2, other than that I'm wondering if your $pages->get($local_lang_url); really makes more sense to be a $page->rootParent call instead? But if your current one isn't working, I would suggest that the /de/ page does not have any visible or viewable children that have a field 'page_key' with the value 'block_m-help-legal'. Are you sure you didn't intend for your children() to instead be a find()? Example: $blocks = $page->rootParent->find("page_key=block_m-help-legal"); The problem with #3 is that it looks like you are expecting a PageArray, but getting a Page. If you simply changed your get() to a find(), I believe it would do what you are expecting. And it should return the same exact results as the example above I posted. If you can achieve the same thing with one find() that you could with a combined get() and find(), then the single find() will likely be faster. For all practical purposes, it probably doesn't matter much though. If your level-1 pages are language segments, like "/de/" as you mentioned, then $page->rootParent will always refer to the root of your current language. I have a feeling this is what you want to be using rather than detecting it some other way. find() is not slow. Every function that returns a Page or PageArray eventually gets routed through find(), so we've really tried to make sure it is fast and optimized. But I still think you probably want a $page->rootParent->find("page_key=..."); rather than a $pages->find("has_parent=...");

Thanks for the update–It works perfectly here! I will submit a pull request to you that makes the title attribute translatable. I also moved the hook-attach logic to a ready() method (rather than init), and made it attach the hooks only if the page template is 'admin'.

I totally agree that we should strive to keep clients away from code when we can. But things like phone numbers and email addresses aren't far off from the type of codes we're talking about here. Sometimes a bit of code (more a tag in this case) that references something is the simplest possible solution from a development standpoint. In this particular case, the tag could technically be completely behind the scenes and the client could just see an image. That would be ideal, and I think this is what we should strive for long term. But the implementation of that is no doubt expensive (time and money) and has editor dependencies. The solution that works for TinyMCE 3 won't work in CKEditor or even TinyMCE 4. I don't think anyone disagrees on what would be the perfect solution from the user standpoint, and this is what we should eventually aim for… when someone can afford the time/cost investment to make it happen. But I also like to see solutions that solve problems, that are maintainable and realistic with time and budget. They provide solutions to questions that would otherwise remain unsolved, sooner rather than later. Very often these are also important intermediate steps that eventually facilitate creation of something even better.

Currently I can't see any reason why this wouldn't work. But a few things you might try: 1. Clear your opcode (APC?) cache. I do this whenever I encounter something odd that doesn't add up. 2. Clear your modules cache. You can do this by clicking "check for new modules" on the Modules tab. 3. Check your Comments field settings. Is it set to redirect after post? Try disabling that option, temporarily, to see if it makes any difference. 4. While I'm not aware of any issues related to this in PW 2.3.0, maybe try switching to the dev branch (2.3.1) just to change things up. Also: Uninstall your module. Then click "check for new modules", then re-install it. I'm wondering if it maybe started out as NOT autoload, and that setting got cached in the DB. PW doesn't load all the module settings at runtime, as it caches some of them, especially autoload status.

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.