arjen

This case convinced lots of clients over here, but it seems they moved to WordPress unfortunately.

Another case of a well known brand is Burger King (at least Poland and Italy) are using ProcessWire.

Maybe superfluous, but I've banged my head around this on several occasions. Don't forget to add the WireTabs in your JavaScript.

Hey @jtborger,

Sorry to hear you are getting errors. The past years we haven't used the Dutch language pack much, so I haven't checked it for 3.0. What kind of error do you get? 

Thanks @bernhard! This needs to be on the front page 

20 hours ago, szabesz said:

I do not know what makes a genius but Steve Jobs was a rather controversial character.

There is often a thin line between madness and genius. For example Einstein has his dark side too. I'm glad they are not my father. We can learn from the good and the bad.

This video is also worth checking out. How to responsive to an insult. Again the thinking... No blurting... And a great answer. 

The hello world module probably isn't the best module to start if you want to learn Process Module. Take a look at the ProcessHello module or other Process modules like ProcessAccessOverview or ProcessLoginHistory.

Hi @noelboss,

I've tried a few times, but I've found it really hard to describe the application without showing screenshots of the workflow. It is unfortunately not as easy as hiding the logo and branding. The customer has a lot of competitive advantage using this tool. I also moved jobs since. During the Christmas holidays I might have some spare time to work out a tutorial of a custom build application. Thanks again for your showcase.

2 hours ago, bernhard said:

Give yourself 30 minutes and learn to create a process module.

Agreed. This is easier than you might think. A whole new world opens up. This should be highlighted as an USP for ProcessWire. Especially with the new UIkit3 theme no need to built custom front-ends anymore.

These are the articles we need! So many thanks @noelboss! We need more articles like this. We have built a great application for an international corporate using ProcessWire with over a million (1.000.000) pages and counting and hundreds of concurring users all over Europe and the United States. We built it right in the back-end of ProcessWire using ListerPro and +/- 20 custom Process Modules. Unfortunately I can't write a showcase (I'm dying too ...) due to legal stuff.

I could not agree more with one of the disadvantages:

6 hours ago, noelboss said:

Separation of Stucture and Data

The definition of the fields and templates is stored in the database, so the separation between content and system is not guaranteed. This complicates clean development with separate live- and development-environments. However, there is a migration module that looks promising — another module, which is expected to write these configurations into the file system, unfortunately nuked our system.

Thanks again! I clapped 50 times

Thanks @szabesz solid request. 

We are using it on one ProcessWire install which is used heavily. We have around 20 Decimal fields with over 200k+ pages with all kinds of automated calculations (thanks @Martijn Geerts). Still working fine ...

I haven't tried it on other installs, so I would really like to see @sforsman giving his blessing.

You might want to test it out yourself. If it works for you I can cover the maintenance, no worries.

Great @webhoes, that's why you should read the entire thread. I knew it had to be somewhere.

This is possible with the Multi-site module. Read through the whole thread. There is valuable info in it. You may need the restructure your tree a bit.

I tried several options but for me adding all fields to the user template would be the way to go. I've experimented with different templates per role, but like @LostKobrakai mentioned this won't work when you have roles with overlapping functionality. Using several templates with Page fields is also an option I tried, but then the amount of templates increased.

My simple solution: create per role a Fieldset and show and hide these fieldset based on InputfieldDependancies. So fieldset_role 1 will only show if role=1. This way you can visually hide fields that don't belong to certain roles. Yes, you have more fields, but at least you won't see them. And getting and setting data from the API is pretty straight-forward too. Although the template option won't create much overhead.

You assign the fields where they need to be stored. For example:

1. Save every field which should be connected to the user to the user template (for instance: an address field, since every user will have their own address) 
2. Go to Setup > Templates ... Filters > Show system templates. When you need to add logic to a role 99% of the time it makes sense to use permissions. For instance create permissions so show specific parts of the layout like a comment box for a specific type of user. I have seen rare edge cases where it would make sense to add other fields to a role. See permissions and user.
3. Role are used to store permissions, but since they are pages you can assign any field which makes sense. See point 2
4. ProcessProfile is where the superuser defines which fields the user is allowed to change on their profile page (/processwire/profile/).
5. ProcessUser is the process module for the users page (/processwire/access/users/).

Hi @kixe,

Have you seen my PR? It would be very convenient to be able to allow the job to run on certain hostnames. This idea is 'stolen' from the ProCache module.

2 hours ago, gebeer said:

disable session fingerprinting

You don't entirely have to disable it, just fingerprint the browser for instance. There are several options. See this commit in wire/config.php by ryan.

2 hours ago, BitPoet said:

[...] especially with corporate networks [...]

This. We've ran into this on so many occassions I have disabled IP addresses from the fingerprint in all our configs.

1 hour ago, gebeer said:

Although I don't feel comfortable messing with security features

I initially felt the same. Then I realised: you are taking one brick of the security wall. There are probably more issues with human errors like people with bad passwords or outdated computers prone to trojans and such.

Hi @Sipho,

Welcome to the forums.

Instead of unpublished you could also make them hidden. They won't show in a $pages->find() either unless you explicit ask: $pages->find('include=hidden')'.

Also check out this famous post on how to organise content in ProcessWire with great examples. This will give you good insight on possibilities on how to structure your data.

@bernhard, I've struggled with this in the past too inside ProcessModules. Didn't find another solution but to use " die()". Feels awkward 

Hi @HarryPhone,

Based on what I know now: there are no specific modules you need.

I would use pages to store the data. You can read the csv file and use the the API to save the data. See this comment on how to create a bash file. Make sure the the new file is somewhere accessible over the internet of place the csv file in a folder. Then you can create a cronjob and trigger the bash script to periodically execute the script.

InputDependencies will work with the forms api as well:

$field = $modules->get('InputfieldSelect');
$field->showIf = "something=123";

Absolutely. Nowadays we build most of the stuff in the back-end with custom Process modules in combined with the forms api. Importing content is also pretty easy. You might ask why not in the front-end? Because the roles and permissions work flawlessly in the backend and the back-end looks pretty good (Reno looks imo the best), but you can create your own based on Uikit. If you want to overwrite the default styling take a look at AdminCustomFiles where you load css and javascript files. Also take a look at MarkupAdminDataTable since most of the stuff you will need is forms and tables.

This makes it pretty easy to prototype. 

5 hours ago, szabesz said:

I was thinking of it too, but even in that case the password reset should work but he reported the opposite.

Agree, but are we sure the right script has been executed with the right usernames? Perhaps they don't know the right usernames and therefore it seems like it won't work. I would suggest looking up in the database. Assumptions ...  

@jen, where did you execute the reset script? Did you get any errors? 

When all passwords won't work anymore at the same time I'm pretty sure someone changed the salt in the /site/config.php. 

Otherwise find a superuser in the 'pages' table in phpMyAdmin or another databasetool and try to reset it.