pideluxe

Thank you very much for taking on this topic, as it is often needed and a reasonable and simple implementation is important.

What do you think about including a duration in the field? If you were to use the data from this field for a calendar, it would be good if the duration was also stored immediately. I found out that php-rrule doesn't directly take duration into account, but there is a issue for this. I've already made some changes to include the duration in your fieldtype, but this is more project-specific and one would have to think about how to implement this in general.

I'm now at 1 1/2 hour from the laravel video and he's still copying database entries to php-files to import it... 

I think the videos should be split into (short) comparisons to other frameworks/cms and an introduction (longer) to processwire. That way, users of other systems could be attracted to watch the introduction.

For the comparisons, it would be great to have experts from other systems doing the same things someone does with processwire. But one could also take videos like that one from laravel and do the same in processwire.

You could also add the parent element as first element in the sub nav. The processwire website does it also this way.

According to their trello board for new suggestions:

• Project must have >5k stars on GitHub or equivalent

The star count for processwire is currently under 700, so this is a long way to get there.

Have a look at the API docs for the $datetime variable (https://processwire.com/api/ref/wire-date-time/).

Just insert the date form PW page as argument and convert it to the format you like.

From the recent discussion about the roadmap & wishlist for 2021 and some other posts by @ryan, it comes to my mind that developing and coordinating the whole project for one person is becoming harder and harder and leads nearly to the reverse of expanding the ProcessWire ecoysystem. This is not against Ryan, i think everyone here knows how engaged he is about ProcessWire, but he has only 24/7 (sometimes i think he's got far more than that...). 

We as the community could support the project (financially) to relieve Ryan and could take over some tasks from him. This could be, but is not limited, to:

• Building a Foundation/Association/Company to ensure the persistence of the project and to fund the work put in ProcessWire of Ryan (and others). Nearly every other CMSs i checked has something like this (Drupal Association, Typo3 Association, Joomla Foundation, Wordpress Foundation, Contao Association, ...). This also puts more trust in the project, if someone new will check on his engagement in ProcessWire.
• Assigning persons/teams to work on things:
  • Extending the core (when necessary)
  • Developing and maintaining major modules (e.g. page builder, admin themes, internationalization, marketing, ecommerce system, ...)
  • Testing and inspection of modules developed by others
  • Making translations of modules (translation of the core is mostly covered, i think)
  • Working on PRs & issues submitted on github
  • Working on the homepage
  • Coordinating the community efforts

I know, some resorts are already covered by others (e.g. @Pete for the forum, @horst for images, ... ), but there are many other areas where this ist not the case. By joined efforts by the ProcessWire community this hopefully will also attract new developers to the system and by a growing number of users this assists in the things above in a circular process. What do you think? 

You could use a masonry-like component, f.e. Filter from UI-Kit (https://getuikit.com/docs/filter).

Place the tags from the images in the filter-tags. For creating the filter elements, you could create an array of unique tags and then loop over the array for creating the selectors. 

I would also be interested in testing, thanks in advance.

$home = $pages->get('path=/');

I used delayed output and markup regions to make clear, they are just other concepts of templating (engines). Delayed output-strategy is about inheritance and markup regions are the so called blocks in twig. Templating in other languages/engines than php is about using other syntax and replacing php-tags with something else, e.g. {%...%} for twig... 

And for terms of reusability: If you are using different fields, you cannot reuse your twig-files, or am i missing something here?

Pls tell us, what is the advantage of twig templating over pure php and using the delayed output strategy with markup regions?

35 minutes ago, joshuag said:

I have been working on regular repeater support, but it's not quite there. The current problem is that the event object is taking its data from the parent page, in the case of a repeater, it's the repeater page (not what we want). So I have to do a bit more work detecting if it's in a repeater and use getForPage() to populate the event object. A couple other little details. Getting close, but still not there. 

It's coming though! 

Sounds great, thanks for the quick answer!

Is it not possible to use recurme within an Repeater? In Repeater Matrix it works, so it is not a big problem, but for my purpose a repeater would suffice...

BTW great module and support, Joshua!

Hey joss,

like that little hanna-snippet. But why are you using it in this situation? Would it be not better having a page reference field selecting the tags? 

Really nice features!

But sounds really not easy to use for everybody right away, maybe it could be a baseplate for theming in pw.

Maybe sharing a future version which is less specific would make more sense.

On 15.3.2017 at 8:15 PM, Macrura said:

I use a custom theme engine module that sort of speeds up the whole process of integrating a pre-made design... (from any html source)

 

Would be great if you would that module with us.

Hi diogo,

really nice site, your minimalistic style fits really well to the artistic magazine and i love the typography.

As a little sidenote, i noticed a little glitch when viewing at smaller width: the "hamburger" and shop icon are placed over text when scrolling.

+1 for sharing your work

hi, there buddy ;-)

it would be nice if you post your nice modules for all.

My name suggestion would be: RockettForms

Thanks for all your thoughts about this (especially the beardman). Maybe my first post did not express what i wanted to say. Draft and versioning isn't a must for being in core, but a free available module with reduced functionality would be good. Sure, you could build that by yourself and PW makes it easy, but for one coming from an other CMS this is not the best answer for convincing to switch to PW.

I agree that versioning is not needed in every situation, but a workflow or being able to preview a pagewihtout publishing are often demanded features also here in the forum. Everyone who is evaluating PW for using it for a larger scale website or working in a team asks for this.So telling them: "yes, it's available, but only if you pay something" (regardless how cheap it is), may they move along looking for others.

It comes down to the question: what is the fundamental functionality a free CMS should offer. And here are the opinions different from one to another, so Ryan as the leader is settling the path where PW is heading.

In his latest blog post, Ryan annouces his works on the ProDraft-module for handling publishing workflows. While this is really great news, there is, at least in my opinion, the drawback that this module is a Pro-module. I really appreciate the tons of work Ryan puts into PW and see the need for getting some money back not being able to do work for some clients. I also like the idea of the Pro-modules, where advanced functions not needed by anybody is sold at a moderate price, i myself have bought some Pro-modules already. 

But such fundamental functionality like draft-versioning or defining a workflow for publishing should be in the core and made open source. I would like to raise a discussion about this, how it could be solved or what other developers think. All other major open source CMS have versioning integrated, so this a field where pw lacks behind and the chance with making that in core would open more opportunities for attracting more people using PW. But then getting this functionality only by paying a decent amount could draw them immediately back without getting the beauty of PW:

Some solutions to solve this that cross my mind:

• Sponsoring: Already Avoine has sponsored some other modules being developed by Ryan, so maybe they or other companies that need drafting could stepin.
• Crowd-Sponsoring: If there is not one company or individual taking over the sponsoring, why not community fund this like a kickstarter-project? I think, most of us could spent at least the amount the Pro-module would cost or even more to make it open for public.
• Making only support Pro: Now all the Pro-modules get higher priority support by Ryan. Not only being the only person doing this, but maybe the only individual capable of supporting all the modules at moment, this can become a bottleneck in the future. Being open source, others can work on adding functionality and bug tracking and Ryan could concentrate on supporting. Other CMS are already doing this more or less (i.e. Acquia for Drupal).

What do you think, should fundamental functionalities stay available in core for all or only being available as Pro?

Hi Caelan,

at the moment i think the easiest way would be to disable the site while updating, make changes to fields and templates and upload your local template-folder to your live-folder.

But to really answer your question, we need some more infos from you :

Why do you want to copy the live DB to local DB? Do you need pages from the live DB to be backuped? Especially the users, why do you need to import them in the local DB?

There a some articles in the forum which deal with this issue, the topic is continious integration or something like this.

You are saying that building custom applications in PW with the "everything is page"-mantra has its limitations - and that's right! No one has said, that every possible application can and should be built with PW-pages. PW is a Content Managment Framework, and for most of the contents you need for the web, its possibilities are more than enough.

I think it is not fair by judging over PW while developing an ecommerce-application as your first application. Look at most of online-shopping suites like Magento or Prestashop, how difficult they were to develop just with php(-frameworks). Some applications are not best suited for PW (or any other CMS), at least with not building some helping modules or components, which could make it easier for plug the application together.

Just another thought: would you have considered any other CMS with its built-in editing & API to develop an ecommerce solution on top of that?

Thanks for the replies, so this has not to be on the wishlist, it is already there! Maybe we could build an integration into the backend.