apeisa

It's not giving page not found (404), but internal server error (500). So site and code most probably ok, but server settings probably not. Look for the .htaccess and try various tips that there are commented. Consult your hosting company if you don't manage to get it working. mod_rewrite required. Always good idea to try clean install if moving site into new host to see if it meets all the PW requirements.

What! Are you old enough for beer?

Mike, just to wrap the discussion: only issue is the "failed..." notice while deleting the module? The module itself works great with latest pw.

I'm pretty sure it's because Fredi installs other module also.

That is correct behaviour. I just tried the delete methodof (first time, didn't know that before) and it worked fine, although I got the notice about that it couldn't delete module. Fredi (and it's companion module) install and uninstall just fine. I believe the issues here are with pw module handling and how those work with 'installs' information.

Just tested this with latest dev (2.5.19 dev) and everything worked just fine. I installed by giving "Fredi" in "Add Module From Directory => Module Class Name". Also tested using it and all worked without any problems. Not sure if the install problems you were having are related to modules manager somehow?

Definitely not a showstopper. Especially on brochure sites where there is no complex searching involved. Also if elasticsearch or something else is used, then no problem at all.

From editing perspective I think PageTable and -Extended do everything discussed here. What I don't like in that is the searching. No more "body*=foo". But that's the price. On the plus side there is 100% freedom for markup (not necessarily the case with "hybrids", like using ckeditor widget).

Hmm, very strange, going to test here this evening. What you mean by deleting the module? Did you installed it using some autoinstall stuff like modules manager or giving module name? Or traditional upload and install method?

I agree. Still think this is most promising open source "block rte": http://madebymany.github.io/sir-trevor-js/ LostKobrakai has been building modules like a crazy: maybe this one next?

Most probably. Not yet tested though, so please try and report? Drilon, sorry noticed your issue just now. Not sure I fully understand, can you describe your problem again with clear steps to reproduce?

Congratulations! We are currently running over 100 pw powered websites / applications. Most of those don't have any kind of version control (other than modules). We have separate dev/staging installation, where development is done and then manually migrated into production site. That works pretty ok, since our clients tend to buy bigger updates instead of lots of little tweaks. Also few shell scripts to create new sites based on profiles, resetting the dev enviroment etc. Very simple setup, and we are currently looking little tweaks into the workflow (adding git and sass into mix for example). I think that we will still keep separate installations and (semi)manual deployment. What do you mean with migrations in this scene? If migrations from another system, then currently we always build custom migration scripts where needed. If data schema migrations when adding new features, then see deployment part of my answer. If something else, we probably do it manually also. We also have some software that we have build using ProcessWire (one big one coming) - there we have given much more thought on these issues, since we need to have it automated. We have our model installer, that reads YAML files and does templates/fields/pages based on those. That's pretty advanced and currently tied into our product, but might be something we could try to generalize a bit and release at some point. Well, depends what you are looking for. Front end fellows that have been fighting with Drupal or WP are very happy with ProcessWire. Backend guys who like PHP in general do enjoy PW also. More experienced PHP developers do find the documentation lacking, when you dive deep enough. All in all, PW is technology that most devs & designers find exciting and I think recruiting people into ProcessWire is "easy" (recruiting is never easy, but with PW you can really focus on the person and his skills, not that if he/she has 3 years of experience with certain legacy tech). Last time I recruited the fellow I ended up hiring did build full pw website on the very same day we had an interview

I think officially pw is just on Twitter. Fb, google+, irc etc are all "community driven communities". FB probably works better as hidden, though I think it has big overlap with this forum anyways. I don't post to fb because my friends mught see that on their walls, but because I find bigger audience from here.

It is pretty new (I think maybe a year now?) - that is something Ryan came up when need to hook into often used methods came for the first time.

I know that this "trick" is used for just few methods - those that could be possible be run hundreds of times per request (like the url). So the performance issue is probably something that is probably not meaningful for normal hooks (where method is called only once or twice), but meaningful in commonly used methods.

Gayan, looks great. What about putting site into demo mode and allowing backend login?

Really? I got frustrated in 5 minutes. Though it might be that I tested with my laptop. Seems to require huge screen.

Yeah, I know what you mean. What I meant that separating Stripe API would really be beneficial if you actually need Stripe in multiple modules in single site. Of course it would be pretty trivial to bundle API (and having api keys as settings) as separate module, so I don't see much harm in that either. Regarding Payment Module (the base module) - I think feature set is pretty much there: supporting single time payments with multiple items/products/rows and customer information. If we go further than that, base class will be covering more stuff than many payment gateways offer, so you cannot really use it in generic way. For subscriptions, I am not sure if it is good idea to try abstracting them. My reasoning is that need for subscriptions are pretty specific (pretty much webapps, donations and payment walls) and all the gateways offer very different solutions. So it will be big task that will benefit only projects where pretty much will be custom customer handling logic anyways. So if you go further with Stripe subscriptions and decide to keep Stripe API as separate module, I am of course interesting using it instead of bundling stripe php sdk with PaymentStripe. I am not planning to add subscription support into PaymentModule. But if you think it would be simple task (it seems it's not?) to add somekind subscription support directly into PaymentStripe, then I'm fine with that route too!

Great news Pierre-Luc! Separate module for API keys - do you think it's worth it? For most projects I think they use either or - not both (normal and subscriptions).

Nico, feel free to help me with $file and $image parts...

500 comes from Apache, so take a look at Apache error logs.

No js library used in frontend validation, but browsers own implementation works in most situations. Native field dependencies are available for form builder also.

Quick search, lister pro maybe? Page path history (moving and renaming pages without worrying broken links or redirects at all), image abilities with croppable images... But most importantly good use of page relations. Build the site in a way that they never have to update same information in more than one place.

I felt dirty having fixed path for base class. Requires definition in module info is much nicer.

It's how autoloading is done in PW. Also that was nice play to add "active payment modules" setting.