apeisa

I have hard time understanding the real benefits redactor offers over ckeditor? I mean the acf, plugin architecture and already available plug-ins, inline mode, easy of settings/modification etc are very well done in ckeditor. Is it better looking and few kilobytes smaller? The size is not really an issue imo, since js is cached anyways. Also really pleased to see all the small improvements Ryan has implemented into ckeditor inputfield, which make the usage even simpler.

Of course, clever one Diogo! Rarely needed with page IDs, that's probably reason it looked like a new solution

Yep, that's good. I often forget to change module name (if I take boilerplate module or edit some existing one), so that will help finding the new module.

You would need cache field per template. If your "parent" template and PageTable template has same searchable fields, then you would be good with one cache field. Although I am not sure if one field would go in either way (if it just skips the fields that are not interested template then one field works). Anyway, both of your templates need cache field attached, selector could be something like "(cachefield%=$q), (PageTable.cachefield%=$q)". Parenthesis make it Or selector, so it would be enough either of selectors match, no need for both to match.

Diogo, wouldn't work with that logic. Either two queries or OR selectors (as simple as parenthesis there). On mobile now.

To avoid adding all the fields (and also making your search faster) you should use cache field: https://processwire.com/talk/topic/5513-fieldtype-cache-please-elaborate/ "Sub sub fields" are not available, but subqueries should do it: pagetable.repeater=[subsubfield%=$q]

Manfred, any interest updating the Finnish language pack also?

On the 2.4 dev branch: 1. Edit template 2. Go to family tab 3. Choose single (1) template as Allowed template(s) for children 4. New section becomes visibly on the same Family tab, called "Name format for children" No modules needed.

It's in the core (latest dev).

Create new role, let's call it "editor" Add editor role these permissions: page-edit page-delete page-move page-sort page-template Hint: don't give "user-admin" role. Publish role and then go into templates => home => access (tab) => check edit, create and add children checboxes for editor role. That should be it.

1. Closer than you believe: https://processwire.com/talk/topic/2117-continuous-integration-of-field-and-template-changes/?p=68899 2. I have something coming for these, although probably on much simpler scale than Omnipay. 3. I don't understand what you are saying here. First you are talking about bootstrap at admin, but then go into FormBuilder (which is for front end). PW has great form class (Inputfields), that you are free to use on front- and backend. Can you explain a bit so I can follow? 4. New Tutorials section is pretty much for it: http://processwire.com/docs/tutorials/ also extended cheatsheet is coming (it's like php manual).

Wow - works really great. I like both things - will definitely start putting field&template changes under version control, but also love how this will simplify even the simplest scenarios: exporting & importing some features from one site to another (or from dev environment to live).

I splitted three pages of posts from here to https://processwire.com/talk/topic/7166-wp-tavern-article-and-processwire-themes/

I think most of us go little bit too hard on this article: it was mostly a well written response to a Mike's "PW vs. WP" article, responding some of the reasons that Mike underlined why they moved from WP to PW. It was honest about the scope regarding ProcessWire (30 minutes, looked for demo, visited forums etc, but mainly just first impression). It also has nice summary about why PW is not Jeff's next publishing system: PW audience seems to be developers (instead of "I just want cool looking website without any coding") It doesn't do out of the box things that Jeff excepts from publishing system PW doesn't have themes PW and WP are totally different tools and I think that both Mike's and Jeff's articles showed that it is pretty hard to have "head to head" comparisons between these two. I really enjoyed reading both articles, and I believe that most developers who end up reading those articles (and their comments!) probably will at least try ProcessWire. Now we should also try to get people from Laravel, Zend, Django, Drupal etc. crowds to try PW. I think that is much more interesting crowd than your regular "hi, I created WP site in 5 minutes" people. Developers using those frameworks are building the greatest stuff there is currently. Of course lot to learn from WP camp also, but I would really focus on developers and framework side of PW instead of "best website builder there is". It's not surprise that WordPress seems to be heading also to more "general cms / framework / platform" direction instead of "easy to use publishing". The latter is very competitive market, with all those website builders like squarespace, virb, weebly, wix, google sites.. even facebook etc. You need keep developers happy, to make sure cool things are coming in future too.

Well, I have spend under 30 minutes reviewing many systems. If it doesn't meet any of the expectations, then 30 minutes is more than enough. I find Jeff's article pretty good - I would assume that first impression is pretty much that, if you just wander around admin and look for buttons that do cool things for your site. If we want to go after big wp audience, then we would really need to focus on things like themes, plug and play modules etc. I would keep our audience where it is (people who are build websites, rookies and experienced). When developers are in, the rest will follow.

Pw creates new session on login. Please see if your session_id changes. Hard to believe that jQuery mobile has role here (that's of course possible too), I would debug the login part and/or shared sessions between pw and codeigniter.

Not sure if that is planned scenario, but you can use selector fieldtype and then getting the pages is as simple as: $pages->find($page->selectorfield)

I have made some nice progress: DeliveryPost done, which asks post address + email.These DeliveryModules pretty much control the whole checkout process (and also adds some admin actions). This is the part of the shop that I guess will be most often customized. It also keeps things simple, when your needs are simple. module that hooks into DeliveryPost and adds shipping options order events (or order history - what has happened and when) Oh, and the module has a name: PadLoper (named after cute turtle species) Here are few teasers:

It's about output formatting, which is set off if not in template context. And image fields & output formatting is documented here: http://processwire.com/api/fieldtypes/images/

What are you trying to do exactly? ProcessWire uses salt also, so telling foxycart just about the hash algorithm PW uses has no use at all. Is there some documentation page on Foxy carts site that we can reference?

As for feature set: my aim is not to solve each and every e-commerce situation there is. I would consider this more for "small shops" at this point, haven't tought about scalability for hundreds thousands orders for example. Here is short feature lists what I have so far and what I am planning for release: E-Commerce modules: Shopping cart Support for different delivery modules (these changes whole checkout process, what fields to ask from customer, what to show after payment success / fails etc. Currently I have done "DeliveryEmail" which only asks email address from customer and then sends email confirmation with possible download links. I will implement more general "DeliveryPostage", where we ask postal addresses also) Support for different payment methods (currently stripe implemented, looking for paypal too for the release - payment methods are independent, so they can be used in other projects too than only this shop) Admin page to manage downloads Fieldtype to attach downloads to products (products are always pages) Since products are pages, support for variations etc are easy: just use repeaters or PageTable. Admin page to manage orders: printing packing slip, mark them as delivered etc... (50% done) Admin page for simple monthly reports (todo) Multiple taxes and taxes for products (todo) These E-Commerce modules are planned in a way that first you build your product catalog (just using ProcessWire) and then install these modules (only those modules you need). So in a way these are quite a "transparent" glue there. Shop profile (might implement this after the beta period): Starter profile for "full featured" shop: product template, categories, tags, product search, related products etc... Can be used as a standalone shop or just for educational purposes (look how certain features are implemented and add them in own store).

I hope to open beta testing soon - planning to open it first for just one or two person and then after that start selling it with 50% off beta pricing. Yes, this is totally new system, no single line from current shop module used. Yesterday I got file downloads working. Couldn't use PW:s pagefiles, since those would have been public (because product page is public). So I ended up having general "downloads" section, where shop admin can add/edit/remove file downloads, and then new "downloads fieldtype", which allows attaching those downloads to page. This method has one drawback: adding file downloads is two step process (first add file into downloads section, then go edit product to attach it). There are some good sides also, especially if same downloads are found from mulptiple products and the files are updated every now and then. File downloads work by "codes", which are unique for each file and each order. You can set rules how long codes are active: for n or unlimited downloads or until certain date or always. There is also possibility to "re-deliver" digital downloads order from shop admin, so customer gets new email with fresh download links.

What you mean by multi postage modules? Macrura: yes, what comes to building product catalogs, there ain't better solution than ProcessWire. Also about flexibility: I have something called "DeliveryModules", which modify the checkout process: what information to ask, what to do after payment, how to deliver the goods etc. I think it keeps things simple per shop: for example no need for tons of postal related options, if you only need email address from customer and deliver the goods digitally.

Much better. I was worried about the scalability of old method when user count was in thousands.

If I remember correctly, I did that at template level, I can check that later (not at computer now). For all you interested in e-commerce and pw: I am working on new set of modules to create really robust base for pw e-commerce. Some of the modules will be open sourced (like general payments modules, stripe is already done, released soon) and some will be commercial. I hope to release these this summer, along with full featured shop profile. Currently working on paid downloads and tax support. Thanks for Nico for "pushing" me to build this, it's looking very promising so far.