apeisa

Thanks Teppo, looks great! The bugs I reported earlier were not fixed on these updates. That make me look more careful the server setup and the issue was that PW timezone was not the same that server was using - that caused history tab to work inproperly. Interesting thing is that the field specific compare/restore did work nicely even on bad configuration.

Sorry guys, haven't used (or developed) Fredi in years. I have no idea what it takes to fully support it in latest PW versions. First thing to try is to add <?php namespace ProcessWire; as a first line to each php file in the module to prevent PW from compiling the files. Probably the issue @lpa is describing is something to do with new PW features and requires proper debugging though.

Hi guys As a @sforsman's coworker I'll let him know about this. We do use namespaced version of this module ourselves.

I think profields table would be most suitable for your needs. https://processwire.com/api/modules/profields/table/

Hi @teppo Finding out that there is also few more bugs with PW3: revisions don't work - it always shows the latest version (the sliding preview or /setup/version-control/preview/?pages_id=1328&revision=511 urls). I did debug this quite a bit and this SQL generated by PageSnapshot::snapshot always returns Empty set (although there should be data and database seems to been populated fine): SELECT t1.pages_id, t1.id AS revision, t2.fields_id, t2.property, t2.data FROM ( SELECT MAX(t1.id) id, t1.pages_id, t2.fields_id FROM version_control__revisions AS t1, version_control__data AS t2 WHERE t1.id = 513 AND t1.pages_id IN (1328) AND t1.timestamp <= FROM_UNIXTIME(1511771437) AND t2.revisions_id = t1.id GROUP BY t1.pages_id, t2.fields_id, t2.property ) AS t1 INNER JOIN version_control__data AS t2 ON t2.revisions_id = t1.id AND t2.fields_id = t1.fields_id GROUP BY t1.pages_id, t2.fields_id, t2.property In history tab clicking pagination also changes the tab (minor annoyance) I also updated this to PW3 (well, added namespace to each .module file and changed PDO references to \PDO, but that didn't had any affect to these bugs (didn't test the earlier image test though). Here are those attached if you are interested (didn't test that well and took about a minute or so). ProcessVersionControl.zip

Access granted! Thanks for purchase

Yup, just answered!

Running a little autumn sale, so if you haven't tried or bought Padloper yet, now is good time! https://www.padloper.pw/buy/ 30 day money back (no questions asked) if it doesn't fit your needs.

If there is someone missing access to the support forum, just email or PM me.

Sorry guys. Buried with work currently, but it is getting better. Padloper is alive and kicking!

@teppo have you taken look at this yet?

Thumbs up for 3.x branch!

PW doesn't use latest version of the PHP SmartyPants, it uses 1.7.1 while latest is 1.8.1 Maybe updating that would fix your issue? You can try it by updating that module by yourself and maybe creating github issue or PR for Ryan to update it in Core too (shouldn't be in the core at all imo). Here you can find the llibrary pw uses: https://michelf.ca/projects/php-smartypants/

Not sure I understand what you are trying to achieve. You need PHP to use PW, you cannot use it from html only. Why don't you install processwire on www,yoursite.com/api/ subdirectory? There your /index.html could be static html/js and then /api/* would go for pw.

Yes, you can include processwire from any path: https://processwire.com/api/include/