Jump to content

processwire.dev — Tutorials for web development with ProcessWire


MoritzLost
 Share

Recommended Posts

processwire.dev

Hi everyone, I'm happy to present my latest project, which is a collection of guides and tutorials for web development with ProcessWire written by me.
https://processwire.dev/

What is this?

I have written several tutorials in this forum, and I wanted a central place to collect all my tutorials and put them in a logical order. processwire.dev is exactly that, a curated list of tutorials for different topics related to ProcessWire development. I have revised, updated and expanded most of my existing tutorials. There are also some completely new tutorials.

Notable topics

What's next?

I hope this will be a useful resource to all of you fine people. Please note that these tutorials are very much opinionated, and they reflect my personal experience and development practices. So if you disagree with some of my conclusions, that's perfectly fine! I'm happy to discuss all my recommendations and approaches with you, so let me know if you have any feedback, suggestions or error corrections!

I plan to expand this resource over time and already have some new topics planned. If you have suggestions for new topics, go ahead and post them here as well!

Start reading now: processwire.dev

  • Like 33
  • Thanks 5
Link to comment
Share on other sites

Thank you for sharing !

I've already had a good read and it's interesting to see your way of dealing with PW. I'm not sure I'm into Twig, but I really like the way you're organising your files and allowing to use composer / nodejs, I'll try that in my next project.

I would also be interested to read more about your development flow, like how you deal with git or the transition between local and prod environments.

  • Like 2
Link to comment
Share on other sites

@monollonom Thanks! I really recommend giving Twig a try, once you get used to it you can never go back ?

3 hours ago, monollonom said:

I would also be interested to read more about your development flow, like how you deal with git or the transition between local and prod environments.

That's actually an area I don't have a good solution for yet. The problem is that all the template and field configuration lives only in the database, so it's not easy to put under version control. The simplest solution is to include a database dump in the version control, but that is a one-way street. Diverging versions of the database dump are really awkward to merge, so it's impossible for multiple people to work on a project independently and merge their work into one repository later, because they will have different database states that can't really be merged liked diverging versions of source code. Also, it doesn't help with continuous deployment (developing additional feature in a dev environment and updating a live site), because importing the database dump would overwrite the actual site content on the live site as well.

The other solution are migration modules like RockMigrations which encode all changes as config files or migration scripts. However, writing those migrations is just so much work, especially with all the field properties which aren't really documented consistently. Mostly it just doesn't feel worth it, especially since it doesn't really solve the problem of multiple people working on a project independently of each other.

I'm not even sure if there is a great solution for this. Fundamentally I would prefer if the entire template and field configuration was file-based so it could be versioned. But of course that's a completely different system design.

  • Like 5
Link to comment
Share on other sites

Sqlite might be a possibility, given it has pdo support and is still a sql database and even that is likely a lot of work for making the things currently expecting mysql as a db flexible. Going away from sql would mean needing to replace all the query building facilities, which basically hits almost all parts of processwire – I'd estimate that as at least a rewrite of half of processwire. And that's just the implementation. For actually making this a reality it would need extensive testing and ongoing maintenance efforts, both of which I doubt will happen – at least without any appropriate financial incentives.

  • Like 2
Link to comment
Share on other sites

  • 1 year later...

Hi Moritz, I was following your Using Twig with ProcessWire article today to set up a site for using Twig and have come across a strange problem.

When I first started, I quickly created some templates and added a few words in them to see if they were rendering correctly.

Then I began working on the site properly. Everything was going fine until I tried to test a page in responsive view.

Suddenly, everything I'd been adding to my twig templates had disappeared and I was being shown the small amount of dummy text I'd started with, like a cached version of the very first page rendered.

I found that switching to responsive mode had logged me out of PW and it wasn't until I logged back in that everything I'd been working on displayed again.

The being logged out when switching to responsive mode is weird enough, but a separate issue, (setting $config->sessionFingerprint to false fixes it) but do you know what might be preventing my pages displaying correctly unless I'm logged in?

  • Like 1
Link to comment
Share on other sites

Ignore me, I'm an idiot. I had caching turned on for the template I was testing. ?

I have come across another problem though. I have a ProFields table field with a text and two checkbox fields. I'm looping through the rows like this:

<tr>
    <th scope="row">{{ row.field_field }}</th>
    <td>
        {{ row.field_match }}
    </td>
    <td>
        {{ row.field_training }}
    </td>
</tr>

field_field renders OK, but with the checkbox fields in the template, I get "field_training|match does not exist or is not callable in this context".

But if I add {{ page.field_status.first.field_training }} outside my loop, I get the correct output.

  • Like 1
Link to comment
Share on other sites

@Tyssen Hmm, difficult to say. I've had a similar error with the Select Options field. When you use the dot to access object properties / values, Twig tries a lot of things to get the correct value. For example, it will try the name both as a property and as a method, try if there's a method for that property prefixed with get/has/is etc. Sometimes, this unintentionally calls a method that does exist, but is intended for a different purpose or expects some additional parameters. In those cases, using explicit methods instead of the magic get functions usually fixes it. I can't check right now, but isn't there something like get or getField on TableRow objects? Using one of those should work around this issue.

3 hours ago, Tyssen said:

Ignore me, I'm an idiot. I had caching turned on for the template I was testing. ?

Happens to everyone ?

23 hours ago, Tyssen said:

The being logged out when switching to responsive mode is weird enough, but a separate issue, (setting $config->sessionFingerprint to false fixes it) but do you know what might be preventing my pages displaying correctly unless I'm logged in?

Yeah, the browser may change the User-Agent to match the selected device in responsive mode, so if the session component checks for matching User-Agents you're gonna get logged out.

23 hours ago, Tyssen said:

Suddenly, everything I'd been adding to my twig templates had disappeared and I was being shown the small amount of dummy text I'd started with, like a cached version of the very first page rendered.

Just in case you get this error again and it's not caused by the template caching: Twig compiles all templates to PHP files and only recompiles those automatically if the auto_reload option for the environment is turned on. I usually couple this to $config->debug so I get automatic reloads in development but not in production.

Link to comment
Share on other sites

12 hours ago, MoritzLost said:

@Tyssen I can't check right now, but isn't there something like get or getField on TableRow objects? Using one of those should work around this issue.

Yep, row.get('field_name') worked. ?

  • Like 1
Link to comment
Share on other sites

I have some text formatters applied to CKEditor fields – Profields Auto Links, YouTube video embed, and Srcset Image Textformatter.

The modified output's not working with the Twig set up. Is there something else other than setting autoescape to false that needs to be added to done?

  • Like 1
Link to comment
Share on other sites

2 hours ago, Tyssen said:

I have some text formatters applied to CKEditor fields – Profields Auto Links, YouTube video embed, and Srcset Image Textformatter.

The modified output's not working with the Twig set up. Is there something else other than setting autoescape to false that needs to be added to done?

@Tyssen What do you mean it's not working? Are you getting escaped HTML output or something else?

If you turn autoescape off (though I don't recommend that), nothing else should be required. If autoescape is on, you need to use the raw filter to prevent HTML output from being escaped.

Maybe you're using ProcessWire's built-in textformatter that escapes HTML?

Link to comment
Share on other sites

1 hour ago, MoritzLost said:

@Tyssen What do you mean it's not working? Are you getting escaped HTML output or something else?

I haven't checked pages with output that the others use, but one page that uses the Srcset Image Textformatter should take something like <img src="image.jpg"> in a CKEditor field and transform it to:

<img src="image.jpg" srcset="image_320.jpg 320w, image_480.jpg 480w">

based on settings you enter into the module for the size variants. The output is just the normal non-srcset version of the image.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...