ryan

Save process: $page->fieldName = 'value'; sends 'value' to Fieldtype::sanitizeValue(); and then sanitized value is kept with $page. $pages->save($page); calls Fieldtype::savePageField() for each field on the page that changed. Numbers 3 and 4 below repeat for each of these calls. Fieldtype::savePageField() calls Fieldtype::sleepValue() to return value as basic type for storage. If value is something simple like an integer or string, then sleepValue may not need to do anything at all. Fieldtype::savePageField() saves the "sleeping" value to DB. Load process: Access to $page->fieldName (i.e. $page->title) calls Page::getFieldValue(). Page::getFieldValue() calls Fieldtype::loadPageField() to load value from DB (if not previously loaded). After Fieldtype::loadPageField() loads value from DB, it calls Fieldtype::wakeupValue() to convert value from basic storage type to runtime type (i.e. array to object). If value is something simple like an integer or string, wakeupValue may not need to do anything at all. The "awake" value gets returned to Page::getFieldValue(). With this value hand, Page::getFieldValue() remembers the value so it doesn't have to pull from DB again. If $page->outputFormatting is TRUE, Page::getFieldValue() runs the value through Fieldtype::formatValue(). That modifies the value for runtime output (example: applying an entity encoder to a text value). In the case of text fields, this would be when the value is routed through Textformatter modules. Note that formatValue() is called on every access to $page->fieldName, as PW only keeps the unformatted value in memory. Page::getFieldValue() returns the value, which you see as the result of your $page->fieldName call. Note that when you get a $page object, the fields aren't actually loaded until you try to access them. Meaning the above process occurs upon field access, not at page load. However, if the field has the "autojoin" option checked, then the above process is very different. However, those differences don't matter to any Fieldtype code (or any other code I can think of). As for error handing, this would typically be done in the Inputfield module, most commonly at Inputfield::processInput or in some cases Inputfield::setAttribute('value', 'my value'). However, it is also okay to trigger errors from Fieldtype::sanitizeValue, but just note that that method will be called on values regardless of whether they came from the API, user input or from the DB. Meaning, time consuming validations are best performed at the input (Inputfield) stage. This sounds a lot like a Textformatter module. If that's your need, then your job is simple and you don't have to worry about any hooks or anything other than making a Textformatter module with Textformatter::format($value) or the newer Textformatter::formatValue($page, $field, $value). More likely you just want FieldtypeTextarea::wakeupValue, as that should be called for both instances above (FieldtypeTextareaLanguage extends FieldtypeTextarea). Most likely you are getting double calls having the two above hooks.

@Jan Romero: What version of PHP and MySQL are you running? You also mentioned 3rd party modules–which modules? (If not Textareas ProField?). The ProFields have been developed in tandem with the dev branch, so I'm fairly sure that wouldn't be it. But the commit you indicated did change the way module information is cached. I found one other instance of a similar upgrade error and we traced it to a bug in a specific PHP Version. That's why I'm curious about the versions of software you are running. I think this is largely the inclusion of CKEditor. The Iridium profile does take up some space since it has a lot of photos, so I may leave that one as an external install. Overall though, I think we're being pretty safe with file size. I can still download a ZIP from GitHub in less than 3 seconds, and we've never had any complaints that file size was preventing someone from trying or using PW. As a result, I think we're better off using file space where we can to make sure PW really impresses people when they download and try it out. On the other hand, we should also be safe and not include multiple RTEs, etc. For example, we removed TinyMCE when we bundled in CKEditor. There has been little demand for this, that's why it keeps getting pushed back. How many threads do you see posted of people asking for this capability? I agree it's a nice capability, and I would like it too. But I try and focus my efforts on what will get used the most. At least the non-sponsored new additions you see in 2.5 are largely based on what's been asked for repeatedly in the forums (as well as what I would personally find useful). So we'll count your request here as momentum for drafts. The funny thing is that PW1 had full drafts capability, had a huge amount of work behind it, and it worked well. The unfunny thing is that clients rarely used it. The primary time that clients (my clients at least) wanted a draft of something was when creating a page. That's why we've already got that in PW2. I ended up feeling that all the work behind drafts in PW1 was kind of a waste of time. Of course the PW2 user base is much larger and the potential audience for such a feature is much larger now. I personally would like to have drafts for already published pages too, but the reality is there's only a small segment that will actually take advantage of it. It's a feature that sounds good, but few use. Still, we may have the critical mass now for it to be worthwhile. And it's also on the checklist of many, even if they won't use it. I even have it mostly built already, and have been occasionally working on it, but it's been kept in the background as more popular features have gotten attention. I appreciate the interest of course, but I don't think this is necessary. We've already got commercial modules funding developing of ProcessWire. The focus on what gets added is also largely based on what are the most common needs people have around here, within the limits of feasibility and schedule.

That modules issue mentioned above should be fixed now, though let me know if you still experience it. A few interesting mid-week updates for those following ProcessWire 2.5 development (aka the dev branch). Here are links to the blog post about it: The ProcessWire installer now lets you choose a site profile New site profile exporter is far better than the previous Support for append/prepend files on a per-template basis With ProcessWire 2.5 getting very close to release, we could especially use help testing out the new installer if anyone wants to give it a try.

I might not be totally understanding the scenario, but if a child can't be deleted then the parent definitely can't be deleted either. Otherwise, you'd end up with orphaned pages in the DB. So there wouldn't be much purpose in issuing a warning or doing anything other than halting immediately. Something that would result in orphaned pages in the DB should be a fatal error, at least in my opinion.

I can't seem to duplicate this one. Can anyone else? I have a few work-in-progress files I've not yet committed, and don't think they should affect this, but that's my best guess. Can someone else confirm they are seeing "required: 1" regardless of the field's required state? Properties that begin with an underscore, like _dateInputFormat are for runtime use only. Previously it would blindly accept those. Now it remembers not to save them in the DB. I'll update the export function to exclude them as well. But since the property shouldn't be there in the first place, go to Fields > act_start_date > Alert. Check the box to delete that property and Save. Though if you don't see it listed as a property, you might also be able to solve this just by going to the field and saving it without doing anything else.

Hani, are you able to update this module listing to point to a GitHub repo of this project? With the module installation options in the PW modules menu, the current linked file (a .module file) doesn't work for automatic installation. While a GitHub repo is preferable, it may work if you can ZIP the module into an archive and post that instead. In either case, we need to update your module listing so that it points to GitHub and/or your module repo. Let me know if I can assist.

SiNNuT, glad you are liking this tool. I just committed an update that should fix this (I had an array_merge() with the wrong order of arguments). Actually, I was getting required as always empty (even if it was required) so the behavior I saw was a little different than what you mentioned. Can you confirm it fixes the issue?

Alejandro, any idea how you were able to install ProcessLanguage before LanguageSupport? I've been here trying to figure out how that might have happened, but I can't find any paths that let me do it. Even the API will halt the operation. Clearly there must be some path to do it though, as otherwise I don't think you could have gotten that error. I don't have an install button for ProcessLanguage either (that doesn't appear until the dependencies are met). Adrian it sounds like you might have clicked on the module title, as there's no Install button present. A default javascript action will still pop-up if you click on it, but it's got nothing to do since there is no install button. If there's any confusion coming from that, I think we'll just drop that javascript action, as I don't think it's even translatable at present... and it's not had much purpose ever since we moved install has been a separate button.

Wayne, thanks I think you've done a good job of outlining the issue. Before we attempt to fix it by requiring a re-translation of existing terms, I thought we might try to solve it by making the order of terms translatable. Could you (or anyone else that wants to try) try replacing this line in /wire/core/Functions.php: return sprintf('%s%d%s%s %s', $prepend, (int) $difference, $space, $period, $tense); // i.e. 2 days ago (d=qty, 2=period, 3=tense) With these lines: $quantity = $prepend . $difference . $space; $format = __('Q P T', __FILE__); // Relative time order: Q=Quantity, P=Period, T=Tense (i.e. 2 Days Ago) $out = str_replace(array('Q', 'P', 'T'), array(" $quantity", " $period", " $tense"), $format); if($abbreviate === 1) $out = str_replace("$quantity $period", "$quantity$period", $out); return trim($out); Then translate the /wire/core/Functions.php using the Setup > Languages > Translation tool, and adjust the order of Q, P, and T in the translation engine according to what makes sense with the locality. For instance, it German it sounds like it should be: T Q P. I'm curious if this solution resolves the issue or if further changes might be necessary. Thanks.

Raymond, Can you try out the update I just pushed to FieldtypeConcat? I couldn't duplicate the issue you are seeing, but I can how why it's feasible to occur. I updated the module to identify it's requirements for ProcessWire 2.5+ dependencies and am wondering if this might resolve the issue.

Child pages don't become part of the PageTable unless they are added from the PageTable field. It is possible for a parent to contain multiple children, some PageTable some unrelated. So just adding a child to a parent does not automatically add it to a PageTable (not currently anyway). The relations are tracked with a separate table rather than with a parent/child relationship.

This is possible. Try the cmscritic example. Click like on ProcessWire. You should see a "products you liked" link on the top right corner of directory list pages. If you'd like I can send you the readme file which has instructions on how to implement.

The configuration as it applies to Fieldtype or Inputfield modules is exported/imported. If you are talking about other modules (like the configuration that's in Admin > Modules > Site or Core), then it's certainly feasible to do it the same way. Something to consider for the future.

Soma, thanks for testing it out. I'm guessing there are a few Fieldtypes it's not going to work with yet (I've tested most, but not yet all). This whole system should be considered alpha at this stage, so the usual disclaimer applies: use it for play rather than production. In the case of the error message you got there, it looks like FIeldtypeCache has a bug where its attempting to access its DB table before the field exists. I think this is something that has to be fixed in FieldtyepCache rather than import/export. But I would like the export/import to capture those kinds of exceptions, so this'll be a good one to test with while I fix it.

In case anyone is interested in trying out some of the things I was talking about in previous posts here, the latest dev branch has a field import/export function. You'll see it in the lower right corner of Setup > Fields. It enables you to copy and paste any fields across any PW installations. Locally, I also have this working for templates (with fieldgroups), though that part needs a little more work so it's not yet committed. I also have fields, templates and fieldgroups mirroring every change to JSON files, as an option that can be enabled for those that want to version these things with Git and what not. That part also isn't yet committed to dev, but will be soon. However, I figured the copy/paste function probably had the largest use potential. It makes migrating field changes (or creation of new fields) quite a simple task. Next up on the commits will be the same thing for templates (with fieldgroups). (note I didn't take these screenshots together, so they aren't referencing the same fields).

We can take criticism here, it's always helpful. It's true that 30 minutes really isn't enough to understand or evaluate ProcessWire, but I do like hearing the 30 minute perspective because I can see that is something we need to work on. While I think our audience is currently a bit different than WordPress, WP is the largest CMS platform by far and so we always have to pay attention as to how we're perceived by the WordPress community. I would like that perception to be one where people that enjoy WordPress would consider ProcessWire when they have needs to develop something beyond what WordPress specializes in. Not that WordPress couldn't handle it (it's powering some quite large and comprehensive sites) but that ProcessWire can accommodate more custom, complex and larger sites quite a bit more easily and efficiently, at least once you know ProcessWire. WP and PW are both useful tools for any developer to keep in their pocket. While you can develop quite a nice blog in PW, you may save yourself time to do it in WP. Likewise, you can develop quite large and complex sites in WP, but you would save your save quite a bit of time to do it in PW instead. That's an oversimplification of differences, but just saying that these tools aren't mutually exclusive. We're both on the LAMP and GNU teams too. As a side note, ProcessWire is here in part because of WordPress, or at least the founder. I didn't even know about WordPress at the time (beyond hearing it was something like Moveable Type), but was really inspired by Matt Mullenweg's speech at SXSW (I think it was 2006, it's been a few years), and that led me into open source. The way he spoke about open source struck a chord. We exchanged a couple of emails afterwards and I thanked him and told him I was going to develop ProcessWire as an open source project because his speech was such an inspiration. Prior to that it had been in development, but as a closed source project. It took more than 4 years and 2-rewrites before it was released, but that's where PW started as an open source project.

@Jeffro: Great to have you here! Thanks for joining the community, and thanks for writing about ProcessWire. @Joss: Just read your comment posted there and that is epic, you always have a way with words. I wish I had your gifts with words... composition... voiceovers... humor.... plants... and who knows what else you've mastered, but just glad you are here!

Great link Diogo. Thanks to you guys that replied to the article. It would really be quite an upset if a WordPress cheerleading site named WP Tavern came out with article saying they were switching their publishing platform to ProcessWire, wouldn't it?

Btw, if you are on WHM/cPanel, moving accounts (to another WHM/cPanel) setup is really easy. Pretty much a 1-click process. So if whatever change you make involves moving to a server where they can't migrate it for you, just use the migration tool built into WHM which has worked great in my experience. I used to host some clients on my own VPS and when they grew and moved to their own dedicated server, this migration tool made life easy.

If there is any evidence of it being a broader trend that extends beyond your experience, we'll look at it. But as far as I can tell it is an isolated issue. I'm just sorry you are the one to experience it. The growth has been slow and steady over a very long time. I'm not aware of any major new changes in growth there, other than acquiring the Amsterdam data center a couple years ago. I agree, that does seem like a long time. Without knowing the details of exactly what the problem was or how far it spread, I don't think I could analyze how long it should take to fix though. If you want to know why, definitely ask them about it. They are pretty straight up with these kinds of questions. We are on a dedicated server in the Reston data center. If they are able to share a dedicated server, it would be news to me. I like the way you are thinking though. But if I were you I'd make a more major change so that you can get off the bad luck train. Try out the LA or Amsterdam data center at least. Reston data center has been great to us, but not so good to you, so change up the location or even the host, otherwise you or your clients' minds will still be on outages and thus attracting them. I think your affected clients would also appreciate your effort in making those changes. But before you decide anything, just call them, tell them what you've run into, that you need a big change, and ask them what they suggest. They will also be the best ones to advise on your redundancy questions. I've found them to be very knowledgeable on this stuff.

Matthew, sorry to hear you are continuing to have outage issues. I always feel obligated to reply here because I stake my name and reputation on ServInt by recommending them here on the site, and that recommendation comes with a lot of long term experience with ServInt and numerous other hosts. I feel badly that you've not had a good experience. The only outages I've seen were 10 years ago, the latest Reston one, and that's it (though both went largely unnoticed by my clients). Beyond this site, I've got pretty much all of my clients at ServInt, in both Reston and LA data centers, all with their own dedicated servers and/or VPS accounts. I have experience with more than a dozen servers there over the last decade. I have also dealt with numerous other hosts over that time period. My experience has led me to trust ServInt very strongly relative to others, and I consider them the best in the business. I'm stating this not to contradict what you are saying or take anything away from the unfortunate experience you've had–it definitely gives me pause. Rather, I'm stating it to say that I think your experience may be unusual and unique. At least I hope that's the case. If it turns out to be a broader trend, we'll act on it, but I don't see evidence of that. Sometimes when things get started on a negative path, it's hard to get off of it (like the law of attraction), and you've got to throw a wrench into it by making a change. I would encourage you to call them and communicate your experience and ask them to make things right. Since your clients that use this server are in Europe, a switch to the Amsterdam data center seems to make sense. But just change something, whether as little as asking them to change the host node, or as major as switching to an entirely different data center (or even web host). I hope you will communicate your experience directly to them, because I don't think they will ever see this thread, which is unfair both to you and them. The site http://www.webhostingtalk.com/ is probably a better place for this discussion because I know they do sometimes read that and may have the opportunity to respond to your experience and make things right (something that can't be done here). Your best bet is just to call them though.

Both. The goal with ProcessWire is to be attractive web designers/developers with programming skills and those without programming skills. ProcessWire is primarily a CMF, somewhere in between a framework and a CMS, but with the ability to be completely one or the other as needed. The admin UI is an application on top of the API. No action in ProcessWire actually requires the admin UI. The admin UI is there to help you. If you don't like that kind of help, you are likely in the minority, but ProcessWire still has you covered. However, if you want to work purely in code you should also look beyond CMF/CMS and towards dedicated frameworks like Laravel. ProcessWire is fundamentally different from any of the CMSs you mentioned, and if you don't realize that yet then I'd encourage you to get to know the system better, and we're all here to help. While our system is fundamentally different, the web designer/developer side of our audiences are similar to those CMSs. Speaking outside of anything specific, we can't ignore what are likely our largest audiences. Perhaps in your system. Whatever limitations your opinion is based on are not present in ProcessWire. I put together a proof-of-concept here when the request came up a few messages above and I can assure you it works quite well. If there's enough demand for it, I'll finish and migrate it to the core. Though if it's something that less than 30% of people will actually use, then it doesn't belong in the core. This is why I'm more enthusiastic about supporting specific-audience features like this by extending API calls and hooks that help other module developers build these tools. Even when tools like this exist in a stable state, I see their value as being for migration and versioning, not for configuration. I don't believe any developer would choose to configure the rather comprehensive aspects of templates and fields from a text file. ProcessWire is more powerful than the systems you've mentioned. The options available to configure for any given field/template are not predefined like they might be in other systems or frameworks. The options vary broadly depending on what Fieldtype and Inputfield is in use (all of which are themselves plugin modules that define their own options). Options can also be affected by other plugin modules. Dependencies are also in place, meaning the presence and requirements of some configuration options can depend on the values already present in other options. Further, some Fieldtypes can ride on top of others (like some of the ProFields), maintaining their own configuration along with those of their host. All of these things lend themselves extremely well to a user interface, and greatly benefit the developer in many ways, especially with regard to instruction and documentation. All of these things can be configured from the API, and could certainly be configured from a text file. But I would consider myself very lazy and remiss in my responsibilities if I expected people to use text files (YAML or otherwise) as the primarily method of configuration for this. I sure wouldn't be a happy web developer having to use that. On the other hand, if you are dealing with a system that is limited to predefined options that are self documenting, then I'm sure a text file for configuration is just fine. But there's little point in comparing ProcessWire to such systems, because ProcessWire provides a level of power that goes far beyond that, and far beyond what I think anyone would find desirable to configure from text files. We use a user interface here for exactly what a user interface is meant for.

I'm not aware of anything broken with the caches in 2.4.8, though there was an issue in 2.4.6 that has been fixed. However, it looks like your MySQL version does not meet the minimum requirements. You mentioned you are using 5.0.8-dev, but the minimum required MySQL version is 5.0.15. If I recall, 5.0.8 is the version of MySQL that had some major issues with sorting. I'm not positive on that, or even sure if that MySQL version is the reason why you got an error, but it seems like the most likely possibility so far. If you are able to reproduce the error again, you might try enabling debug mode so that you could see if any other error messages get output. But chances are that there will be incompatibilities between PW and versions of MySQL prior to 5.0.15.

You are right–I'd forgotten we had that in the htaccess. Yes, I'd leave it for now. I just wanted to point them out because I think these will be beneficial for this module once 2.5 is stable. I agree, you don't need it for now. My default is always to double up on security, but thinking through it more it's probably not necessary here. I mention it as a possible future addition though just because the URLs hitting a website aren't always confidential. The token is only as private as the logs. For most of us, that's a non issue. For some it's a potential ddos entry point, but only if the token gets in the wrong hands. I think what you've got is just right for the majority, and if someone needed something more, like an IP limiter, then probably better to leave it to them to add in rather than making everyone else fuss with it. Sorry, I missed that wget was already there. There may be some benefits to having the cron job run the PHP File directly, but it would be more difficult for the user to setup (creating executable PHP shell scripts and such). Also, having initialization of the job URL accessible makes it easier for people to use external CRON services. As a result, I think sticking to the method you are using is better. Thanks for adding to the modules directory!

This looks fantastic djr! I've had a need for something exactly like this and will definitely look forward to using it. I took a quick look through the code and think it looks very well put together. I do have a few minor suggestions: Rather than backing up the DB to the root path (where it is temporarily web accessible) I'd recommend backing it up to a non web accessible directory, like /site/assets/cache/. Likewise for the tar/gz file. Beyond just looking for "runbackup" in the request URI, I recommend designating a page that it will only run on. For instance, if you wanted it to only run on the homepage: $shouldBackup = $page->path === '/' && (strpos($_SERVER['REQUEST_URI'], self::RUN_BACKUP_PATH) !== FALSE) && $this->wire('input')->get->token && $this->wire('input')->get->token === $this->token; This might be a good module to experiment with conditional autoloads. In your getModuleInfo, you can do this: 'autoload' => function() { return (strpos($_SERVER['REQUEST_URI'], self::RUN_BACKUP_PATH) !== FALSE); } In truth, conditional autoloads are more reliable in PW 2.5 (a few minor issues have been fixed) so this may be a v2 kind of thing as well. In PW 2.5, you can also isolate the entire getModuleInfo() to a separate ModuleName.info.php file. Beyond just the token, it might be worthwhile to have an IP address limiter since there's a good chance one's CRON job is always going to be coming from the same IP. Though not sure it's totally necessary. In your docs file, I would mention if possible what command you recommend for the CRON job, for instance: wget quiet no-cache -O - http://www.your-site.com/runbackup?token=abc123 > /dev/null Lastly, might be good to mention that it requires exec/system access for executing commands (many hosts have these disabled by default, but there's usually a way to enable them). Please add to the modules directory when ready! Thanks for putting this together!