-
Posts
4,045 -
Joined
-
Last visited
-
Days Won
67
Everything posted by Pete
-
The cynic in me says it was just about getting publicity, customers and not about the actual cause at all, but maybe I'm just too negative nowadays.
-
Yeah, I moved house a few months back and haven't cranked my desk up to standing height once yet - very lazy. That must change today!
-
So what you're saying is we're already ahead of the game? I like it To paraphrase Terminator 2:
-
I've never really used Lister beyond its implementation on the Users page in the admin to be honest. But then there's always one who'll have the opposite view
- 24 replies
-
- 1
-
-
- draft
- Pro-Modules
-
(and 3 more)
Tagged with:
-
What a client might pay him to do could be quite bespoke though, more so than a drafts module, so you wouldn't want really niche stuff going into the core anyway. Plus client work doesn't necessarily result in new modules or core changes at all as they would theoretically usually just be normal sites using existing modules, but still pay the bills. Pro modules seem to slot somewhere in between client work and core. Core is something that a lot/most people would use reasonably regularly, Pro modules are useful in certain scenarios and usually of interest to a lot less people. I think ProcessWire does definitely need some further structure in future in terms of marketing folks etc, but I'm not sure how that sort of thing even gets off the ground in other projects. All suggestions welcome, but probably in another topic.
- 24 replies
-
- draft
- Pro-Modules
-
(and 3 more)
Tagged with:
-
Good spot on that first link WillyC - didn't realise this had already come up so recently.
- 24 replies
-
- draft
- Pro-Modules
-
(and 3 more)
Tagged with:
-
What the guys said above - I hadn't thought about it like that and was going to suggest something else, but the more I think about my own requirements draft pages would only have been used in less than 10% of projects I think, and even then they would warrant the price tag so not an issue really and it shouldn't be core. The only draft I need most of the time is as I'm writing something before it's published, so the unpublished state does that for me. This does come up from time to time with new pro modules (pretty sure I remember a similar conversation way back when FormBuilder or something was released) but there's usually a good answer like the guys have made above. I prefer that everyone who has paid for Pro Modules gets the benefit of everyone else's questions and answers in the relevant support forums. If the modules were free to all, other community members would undoubtedly help out non-paying folks in the forums which is fine, but given that there are a lot of people here generous with their time and knowledge, folks might not need paid support or see the need to buy that option so it would be a bit of a gamble. Having said that, some aspects would be nice in core, but not to the extent as in this module. But someone could easily build a more basic module for drafts - how do you think the Dev Directory works when you post updated content? (It actually clones the current entry, you edit the clone, then when approved it's copied over the original - a very rudimentary draft system built in a short time using just a few API commands in a small module).
- 24 replies
-
- 8
-
-
- draft
- Pro-Modules
-
(and 3 more)
Tagged with:
-
Cool - let us know how you get on with the front-end as I'm always interested to hear about large data projects. For topic lists on the front-end, pagination is obviously your friend, but also so is autojoining some oft-used fields in your post template - things like topic starter, topic start date, last reply date, last reply user, avatar (just guessing at fields here). Basically for the most common fields that are always going to be required whichever way you're viewing a topic (full topic or in a list or search results etc) if you autojoin them it saves on queries. This page explains it better (no idea why I've not bookmarked this one myselef yet ): https://processwire.com/talk/topic/26-what-is-the-autojoin-feature-in-the-fields-editor-and-how-do-i-use-it/
-
If you get stuck, feel free to share some of the code and I'm sure we can help.
-
Indeed. It wasn't many pages it applied to (maybe 70) but there are about 10-15 float fields in the template that need changing so yep - best to double-check these things before destroying a client's data!
-
Thanks man. I was thinking it was more difficult than that for some reason!
-
ProcessWire Site Header and Footer Used in WordPress Blog
Pete replied to quickjeff's topic in API & Templates
I'm going to skip the question "why" and leave that for someone else as I'm guessing there's a good reason for using Wordpress for the blog portion or you wouldn't be doing it this way The way you could do this, without having to try and bootstrap ProcessWire with every Wordpress page load, is to use a caching method as you said. MarkupCache should be able to handle this I think: https://processwire.com/talk/topic/7-new-markupcache-module/ You would have to store all the header data in a varialble and save it to the cache (as per the examples in that topic), but it would have been parsed correctly by ProcessWire and would be standard HTML in the cache and therefore ready to use elsewhere. Same again for the footer. Then you should (theoretically) be able to just include those cache files into your Wordpress template files and hey presto! It would be worth testing with a small bit of text in a MarkupCache cache file and seeing if that works.- 25 replies
-
- 1
-
-
- caching
- header include
-
(and 1 more)
Tagged with:
-
It definitely would help - thanks. I could do with being able to do this tomorrow though so if there is an idiot's guide set of manual instructions on how to change the table data in the meantime that would be fantastic. If that's a bit too tight a timeframe then no problem The way you're proposing is interesting (to solve my "in bulk" requirement), however I'm not sure how many other people might need to do this in bulk. It might be easier (not sure) to do it the way other fieldtypes do on a per-field basis. Fr instance you can change an integer field to a float or text by editing the field, though I've never looked at the underlying code and how it handles any changes to the table in the DB. That might be the more "ProcessWire" way to go, but I'm not saying I would complain about a mass-field-converter either Disclaimer: If changing the fields via SQL turns out to be so easy that I should have known better and done it by now, I'll chalk that up to a tiring week.
-
What I would love is a way to change a large number of float fields to use this decimal field without recreating them (they have data in in a lot of cases and as we're dealing with money things seem to go a bit wrong with a float field but seem to work perfect with this decimal field). Is there a sensible query I can run to change the table structure? I can change the fieldtype used easily enough in the DB but am a bit wary about changing the table structure for fear of losing the data.
-
Why not pre-cache on save, instead of on request? (possible?)
Pete replied to joe_g's topic in General Support
This is exactly what I do on one site - different browser open and load the page as a guest. It helps to do this anyway I think as there can be times where things may display fine for logged-in users but not for guests (usually when I put some sill code in and it breaks something ). -
Hmm... that's a lot of big changes. I wonder why they didn't opt to call that the 2.x branch and then they could make all the changes they like and let the community continue contributing to the 1.x branch as long as they like? Seems to be a lot of things to take into consideration when upgrading, and more breaking changes to follow in 1.26. But I'm happy they're making some changes anyway.
- 7 replies
-
- intranet
- password-protection
-
(and 2 more)
Tagged with:
-
Checking array for a value (might be more PHP question than PW... sorry)
Pete replied to a-ok's topic in General Support
But you never mentioned "parents" before now -
I think this is your limiting factor here. I have built something similar as part of a wider, integrated intranet system however if your time is short you can't beat using some pre-existing software. Nothing will beat ProcessWire if you are likely to want to introduce functionality not available in some other system as ProcessWire is one of the few platforms where you can change your mind about something or come up with crazy new ideas and it not be a problem to make larger changes, but if you're likely to only need a normal WIKI type system then you probably won't replicate all the functionality you want in just a few weeks. That said, I hate that MediaWiki seems to be the main option out there (there are others, but they all come with their own maintenance issues too) as it's a bloated piece of software (so slow and resource hungry for what it does) on an out of date codebase in my opinion. I would love to have the time and money to develop something in PW as coupled with ProCache you'd be onto a winner and have something infinitely more customisable if a lot simpler, but it would be a project that would take several months at least I would think to cover everything (well, the basics) of what something like MediaWiki can do. Not sure where my train of thought is going, but I guess if you're really tight on time, you should probably invest that in installing, skinning and getting to grips with something that already exists. If the project is longer-term overall (as in you'll be looking after this system for years), then this buys you time to develop something as a version 2 and does you a favour in a way as you'll know what the client does and doesn't use in the system you've installed so you know where to focus your efforts in a custom-built system. Hope that's of some help anyway.
- 7 replies
-
- 3
-
-
- intranet
- password-protection
-
(and 2 more)
Tagged with:
-
Dependencies for $page->prev & $page->next methods?
Pete replied to Mikel's topic in General Support
$g is an array of pages in your example that doesn't seem related to a particular page, so how does it know what next and prev are? Next and prev usually relate to the page being viewed, so $page->next() and $page->prev() should be all you need. -
I'm keeping an eye on Flarum lately. Early days, but looking promising for simpler needs.
-
Hi guys Some folks I've known for a long time are putting together a Web comic. It's not your average though - each page will consist of detailed panels and will be around 1mb per page with dozens of pages. In the background will be accompanying atmospheric music at about 3-5mb per track - it's quite the project and the site is being built in AngularJS and there's a big focus on making sure everything is served up as quickly as possible. It's going to get quite a lot of hits the first week, so given the media-heavy nature of it coupled with the fact that there will be global interest, can someone recommend me a good CDN that will handle a lot of traffic? Commercial is fine as they want the best for this project.
-
This is really slick tpr - good work. Did you mean to leave both .zip files up though? Seems like the one two posts up could be deleted now (happy to do it for you - just wanted to check if it could be deleted first).
-
That's awesome Peter - shame it's not intentional.
-
+1 for MariaDB - running smoothly. The only issue I found, and it was a non-PW issue, was I was querying an integer field in MySQL with more characters than the field can accept and MySQL just truncates that - MariaDB does not and I think treats it as 0 or empty or something. Not that that is at all relevant for anything to do with ProcessWire, other than there is no harm switching to MariaDB. In fact if you're using WHM and cPanel you can just switch for all your sites now via WHM. Take backups first though of course as it's very much all-or-nothing.
-
Having actually watched the video for https://siteorigin.com/page-builder/ now it seems very much like how the current template/field system works in ProcessWire (can do widths/columns, re-use fields etc) but with pre-defined widgets and blocks of code and a fun interface for it. Where a ProcessWire version could excel is if fields could be created on-the-fly in this fashion just with normal templates as a start as that has much more power than pre-defined blocks I think, however still of course have the option to use existing fields and - as I mentioned previously - HannaCode snippets as well. Essentially the PW version of the pre-defined widgets are just ProcessWire InputFields so people can create them already as they wish. This would be a big task to do though, but a starting point would be making the template edit screen a bit more like this (as in the grid you can drag, drop and resize) and be able to add new fields on-the-fly rather than on a separate screen (which I think someone - possibly Adrian - has already worked on?).