Leaderboard

I just returned back in town about 30 minutes ago, after being out of town with the family most of this week. As a result, I've got no blog post for this week. I'd hoped to at least get the email newsletter out, but unfortunately didn't have the necessary internet access to do so. Thankfully back online now. I'll be sending out a double issue of the newsletter next week. Hope that everyone had a good week and has a great weekend!

Hello MrSnoozles, in Processwire template files are not actually templates and You can actually use them as controllers (see the "delayed approach" in pw tutorials). In template files You can manage the request ($input), build forms (InputfieldForm module instances) and assign variables which are later used in the included view file(s). (btw, I use the ".phtml" extension for my views/partials to distinguish them from template/controller files ".php"). If you ever worked with Silverstripe you can actually think of template files code as Silverstripe's Page_Controller classes ' method code. You can leverage pw's urlSegment feature to add sub-routes for the current page/template. If you have a contact-page template (/contact-us/) You can use a "submit" segment ($input->urlSegment(1)) and use "/contact-us/submit" as the form action, the same way You can add any route segment in a Silverstripe (Page_)Controller class. I don't find it useful to add code used only by the "contact-page" template in a global function inside (_func.php). As in Silverstripe cmf the segment approach has the advantage that it continues to work even if you change the url (name) of the page using that template. Think of template files as controllers: while in other frameworks you have to assign controllers to routes, in PW a route (Page path/url) is automatically linked to a peculiar controller (template) by the fact that the Page with that route is using that template. kind regards, maks feltrin

Hi, @HMCB This blog post by @clsource should clear things up a little bit: https://medium.com/@clsource/understanding-processwire-templates-fields-and-pages-201aecd0a1a4 When talking to clients, you might want to mention that in the ProcessWire world a Page (=> "special PW terminology") represents a database record. Most of the time it is just enough for them to know as most of them are not skilled enough to digest too much in this regard. Since you are free to label/name your pages whatever you want to (using some appropriate names, of course), you should do so and when talking to clients just refer to those "pages" by using their labels/names.

Currently working on a premium module and I would love to be able to sell it through the PW store (currently not possible) and maybe have the store handle code creation.

Can you reproduce this behavior using a clean install of ProcessWire? I've had no issues running PW3 on PHP 7 so far. It's running like a champ and much faster on 7 thought

Hello, As you can see the blog rss is not updating since April http://processwire.com/blog/rss/ Weird :S

Many thanks all! Happy to be here. Very encouraging to hear - this will enable updates to be done during active development phases with a site, so there can be a general round of testing rather than trying to test everytime after installing frequent updates. I'll check out the upgrade module.

I think it would be great to start the marketplace precisely by doing it with Processwire as a module, then that module is also on offer as a platform demonstration. Maybe?

Here are two resources i found quite useful leaving jQuery behind.. https://plainjs.com/ http://youmightnotneedjquery.com/ Have a nice weekend.

Of course you are right @szabesz. I can understand why we don't have it yet. I just wanted Ryan to really consider it and to know that there are people that would be happy to support him with a referral fee or something. That's the point I'm not quite sure about. Have a look at https://invisioncommunity.com/features/commerce#elCommerce_marketplaceContainer (This is a feature of the forum software processwire.com/talk/ is using) The board works great so I guess the feature might do what it's supposed to do out of the box quite well?

While I agree that a one and only "official store" would be great and help ProcessWire to prosper, I suggest that developers willing to sell such modules should unite Consider that Ryan is a human too, with only 24 hours a day to use up meaning: implementing, maintaining and running the store requires extra effort and time which might be a mayor constrain here, hence my suggestion of doing it as a teamwork and sharing the benefits as well. Currently we have: https://processwireshop.pw/ and https://processwire.com/talk/store/ Although it would be welcome to see the two "merged", I guess it is not as easy as it sounds.

@tpr, just a heads up about another issue over on GitHub along with a possible fix.

@tpr, I've been having a look at the images-in-repeater issue for non-superusers (I discovered this one a while back but forgot to report it here, sorry ). ----- Edit: I did report it over in the Github repo. Edit 2: looking at some PM history it looks like a solution (same intent but different implementation to that proposed below) was found but never merged into the repo? ----- As you found, the $this->editedPage property is the source of the issue. Seeing as the things this property is used for within the module either don't work within repeaters (e.g. field edit links) or aren't needed for repeater pages (e.g. breadcrumb features) I think $this->editedPage should never be set to a repeater page. But it's much easier to exclude repeater pages in ready() because in init() it is not yet known which class a page is an instance of. So could $this->editedPage be set in ready() instead? This is what I did in my testing and it seems to work okay: public function init() { // removed code that sets $this->edited page // populate self::$configData self::$configData = $this->modules->getModuleConfigData($this); // ... // a bit further down we need to change $configData[$subModule] to self::$configData[$subModule] public function ready() { // set $this->editedPage // excluded repeater pages, minor refactoring $this->editedPage = false; $editedPageId = $this->sanitizer->int($this->config->input->get->id); $editedPage = $this->pages->get($editedPageId); if( $editedPage->id && !($editedPage instanceof RepeaterPage) ) $this->editedPage = $editedPage; self::$configData = $this->modifyConfigData( $this->modules->getModuleConfigData($this), $this->editedPage ); // ...

@bkno http://modules.processwire.com/modules/process-wire-upgrade/

ProcessWire does have an router, even though it does look vastly different to what you're talking about. It's routing requests by the page template to the corresponding template.php file. What you proposed does not correspond very well with that core routing strategy, because neither urls nor the http methods are the identifying factor here. It's the pages template and the existence in the page tree. If you're looking for a more traditional mvc routing layer, you can set an alternative template file for your templates (by hook or in the backend). Just point all of them to e.g. a router.php file and use whatever router package your like to route requests to wherever the action should be handled. And about the core routing of processwire. Always keep in mind that mvc frameworks do not have something like the page tree, which is why they need a router to work on the url of the request. ProcessWire does not need that with it's approach.

Hi @Peter Knight 1. You can use MarkupSEO, just change type of needed field to multilanguage text/textarea ( seo_title, seo_description etc.) 2. I think yes. Can't remember if I had some issues. 3. All of my sites are multilingual and I never had a need to use a separate tree for every language. You can switch off multilanguage support on template level (Advanced tab) and there is module that lets you control whether multi-language support is enabled at the page / branch level. 4. Yes. You should read about hreflang. Also, there is "What should happen when this field's value is blank?" option in field settings. Usually, I don't inherit values from default language, because in that way I can get duplicated content ( not good for SEO ). Image and files fields are multilingual through language-alternate values

I guess it was not adjusted to the new environment: https://processwire.com/blog/posts/amazon-aws-now-powering-processwire.com-sites/ also, automatic "version string" update seems not to be working here (related maybe?): https://processwire.com/download/

Yeah, I tend to stick to the tree-model for this kind of thing. In this case, I tend to use "legal/terms", etc. If need be, there's always Jumplinks for quick redirects.

I dont know how they work internally, whether they depend on each other, but I'd love to be able to test and buy RepeaterMatrix or Multiplier or Table (or any other) module individually. Whole pack of ProFields modules seems awesome to have, however, being able to buy one for ~$30 --instead of all for $130-- sounds much more affordable and this way I could buy the whole pack part by part in several months and wouldn't think twice. But $130 at once, I can't really justify it (and still havent been able to) just as easily with low (to none) disposable student income. Or instead, having sales one - twice a year would be great as well. One advantage of this change would be allowing more people to buy -> support the development & community -> give feedback -> improve these products. This could also potentially pose a disadvantage where requests from people would increase the headache and time required to respond to all these requests, but this community is more than able to handle that. I'm sure there's a reason to why these modules are sold together, and I'd love to hear your side as well, @ryan, (and all other maintainers). Regards, Abdus.