ryan

Not trying to hide anything. Just figured I should test it a little more before announcing it in the modules forum. But I was thinking I'd post something about it tomorrow. As it is now, I thought it was probably the best example I had of a Fieldtype/Inputfield that has multiple columns of data, and how to create one. Since Rob had these needs in his Fieldtype, I thought it would be useful to post here. I didn't originally plan to make it a Fieldtype, but realized it would translate to a good example or starting point for a tutorial. I can't seem to duplicate the integer floats issue. Just testing here again geocoding various addresses and am always getting the full exact lat/lng. Is there a specific address you are geocoding that does that, or is it any address? I'm wondering if it's getting cut by a float precision setting in PHP or MySQL. I might have to keep these numbers as purely strings from the PHP side to keep out any uninvited float precision settings. But before I do that, I want to find out more and see if I can duplicate here. If not, then I want to at least understand where they might be getting converted. Let me know if there's anything I need to duplicate, and I'll do more research here. Thanks for letting me know.

Tested here too. Seems to work great – nice work Nico! I have a couple of suggestions. For loading/writing to the log file, I recommend replacing this: '../assets/logs/errors.txt' With this: $config->paths->logs . 'errors.txt'; I was also wondering about this: $url = explode('/', substr($_SERVER["REQUEST_URI"],0,-1)); unset($url[count($url)-1]); $url = implode($url, '/').'/'; header('Location: '.$url); Couldn't you just do this instead? $session->redirect("../"); In your getInstalledPage() function, I recommend adding this before the $page->save(): $page->sort = $parent->numChildren; That will ensure it gets placed as the last item on the Setup page, rather than potentially in between Template and Fields. Lastly, take a look at PW's FileLog class: /wire/core/FileLog.php. This is what PW uses to create the log files. It includes two functions that may be handy in a future version of your module – particularly if you ever have to deal with really large log files (which may not be very likely with PW's error log). It includes a get($bytes) function that returns lines from the end of the file, without having to load the whole file. It also includes a prune($bytes) function that prunes a log file down to a specific size, leaving all lines in tact from the end of the file. This is preferable to clearing sometimes as it still leaves the most recent entries in tact. PW doesn't currently utilize either of these functions anywhere but just wanted to let you know they were there in case you ever find them useful. I originally coded them thinking of a log viewing/management utility module.

I haven't been able to test this one out yet– I want to learn more about the Piwik software and understand it all before I install to my server. However, I'm very intrigued by what I've read so far on their web site. I did get to look at your module's code and it looks very well put together in all respects: code, comments and documentation. Thank you for your work with this module. I can't wait to use it and am thinking this is one I will definitely be using a lot on my sites and client sites.

Not sure I understand what you mean about the templates labels in the page tree? But the reason for the name 'label' is for consistency with the 'label' and 'description' used by Fields. In PW, 'description' means something that can either be any length, short or long. Whereas 'label' is implied to be short (word or phrase) just like the English dictionary meaning. We want the template labels to be short so they can be used in select boxes and the like. This also leaves room for us to add a 'description' field to templates down the road (should we want it) that would be consistent with the same thing from Fields. Technically template labels aren't really necessary except in a multi-language situation. So PW will likely keep the label field collapsed by default and one can utilize it if they want to.

Well the good news is that I got my virtual machines going again (a VMWare Fusion upgrade did the trick). But I've only got a few minutes online today because it's a holiday here and not likely to get enough time to test today. Everyone is taking a nap so figured I'd try to catch up with some forum posts while I had the chance. I'm going to be online tomorrow though so will plan to test then. Thanks again for all of your help in tracking this stuff down. Edit: This reply is for both of the IE threads (this one and the one about the link selection0

I think the problem might be the first question mark in there (in bold). That doesn't add anything since the '*' is already making the whitespace optional. Adding a '?' technically converts it to a 'lazy' (regex term) match of optional whitespace, and it's unnecessary at best, or breaking the regex at worst (I'm not sure which). I'd modify that regex to this (below), grabbing the whole 'v' variable, whatever is in it, and then matching anything after it until it hits a closing paragraph tag. Also I took out the 's' option at the end so that it doesn't attempt to match one item across multiple lines. I don't think it matters much to the replacement, but I figure it's better to leave stuff out that doesn't need to be there in case it's faster. $page->body = preg_replace("#<p>\s*https://www.youtube.com/watch\?v=([^\s&<]+).*?</p>#i", $replacement, $str);

Hold off on doing anything with modules. Get to know the template system first. Add-on modules are not something that one needs to get a site going. Most modules provide additional capabilities to the API rather than create something literal, so delve into modules later. Once you understand the templates and API, then modules will make sense without even thinking about it. I think that most of the answers you are looking for you'll find in the files under /site/templates/. Start with viewing your homepage, and then take a look in the file /site/templates/home.php. Then take a look at the files it includes (head.inc and foot.inc). If anything there doesn't make sense, post questions here. There is no such thing as a dumb question here -- all questions are welcome. If anyone wants the skyscrapers profile and doesn't mind installing an old version of PW to make it work, please email me at ryan at this domain, and I'll email you a link and instructions. However, the Skyscrapers profile is a more complex example, and I still think the basic profile that PW comes with is the best example to get started with. Only about 10 people have even played with the skyscrapers profile and I think most in this forum haven't seen it, so I don't think many have used that to learn from. The basic profile is heavily commented and kept intentionally simple to guide you through the different template files. Once that example makes sense, then the Skyscrapers profile is a good one to check next. Though once you understand the basic profile, you may realize how simple it all is and want to start using it rather than look at more examples... I think everyone is different in this regard. I like to look at lots of examples... others like to start experimenting rather than look at examples, and I think we can accommodate either way. I think that often people think PW is a lot more complex than it is, perhaps because it's approach is so different from something like Drupal or WordPress. In reality, when you know PW, things like Drupal and WordPress will seem needlessly complex (my opinion at least). I'm hoping to also start adding new profiles to download once 2.2 is out. A blog profile will probably be the first. I still think the basic profile will be the best starting point, but I know people are more likely to learn best from something consistent with their needs at the time. If they are building sites that are a lot different from the basic profile, it may not be as good of a starting point. Having more profiles increases the possibility that we'll be covering the type of examples that someone needs at a given time. I know Pete is also working on something that compiles all the examples into a more friendly starting point than a forum. I'm excited because I think this will be a great tutorial resource.

Rob, glad that you got it working! Thanks for posting the code. Also, I was working on a Fieldtype and Inputfield to provide a good example of how it all works when creating a Fieldtype that needs to hold multiple pieces of data. It's called FieldtypeMapMarker and it holds a mappable address, latitude and longitude. Once you enter an address and save, it geocodes the address to latitude and longitude and shows you the location on a map. Not sure if this is still as helpful to you since it sounds like you already figured it out, but wanted to post the link to it anyway just in case: https://github.com/ryancramerdesign/FieldtypeMapMarker

I'd experimented with getBookmark() and setBookmark() back when I was originally trying to get this working in IE. If I recall, it did solve the problem in IE but then caused major problems in others, so I didn't pursue that further. But your code may be accounting for something mine didn't–I'm anxious to try it. Unfortunately I'm stuck on a rush project for a client today, and can't do much other than take 5 min breaks to check in on email and the forum. But hope to try here soon. Thanks for working on this.

When saving a page, sleepValue won't get called if PW doesn't think the field actually changed. When you save a page, PW only saves the fields that it detects changed. So what I mentioned about $this->trackChange('value') in your Inputfield may be more applicable to your case than I thought. But I don't know the context well enough here to say for sure. Still don't know if we are even talking about pages saved from PageEdit.

The full TinyMCE installation should be in /wire/modules/Inputfield/InputfieldTinyMCE/tinymce-3.3.9.2/ To change the TinyMCE version, add another tinymce-1.2.3.4 directory there like the other (replacing 1.2.3.4 with the version), then update the version number at the top of InputfieldTinyMCE.module, where it says this: const TinyMCEVersion = '3.3.9.2'; All of our custom plugins are in the /plugins/ dir, outside of the tinymce dir, so it should be possible to upgrade the version without worrying about updating anything in the tinymce source. That's assuming that our plugins are compatible with newer versions. I don't think the problem is with TinyMCE itself. I actually think the problem is the use of jQuery UI dialogs, but not 100% sure. I just know that the TinyMCE dialogs work in IE8 (as you saw on their demo). Unfortunately, I never could get the TinyMCE dialogs working with our image and link plugins. I think this has more to do with my lack of knowledge on the inner workings of TinyMCE than it does with anything else. WordPress has this all working pretty nicely with TinyMCE dialogs, but I couldn't duplicate the results (this was awhile ago). Though I still have a preference for jQuery UI dialogs, but I think we can sacrifice to support IE if it turns out we can solve it with that.

What is the context? Is this something that's being edited in a page like any other, or are you using this somewhere else? If in PageEdit, then that process handles all the communication of values between the Inputfield and the $page. If you are trying to use Inputfields somewhere else, then you may need to pull the value from it and set it to your $page or wherever else you want it set. No, Inputfields don't know anything about Fieldtypes. They are designed to function independently. They don't set values to anywhere other than themselves. This enables them to be useful for your own forms elsewhere, regardless of whether they are used by some Fieldtype or not. If used in PageEdit, the setting of values to Inputfields and pages is handled internally by PW, so you shouldn't have to do anything there. PW may set a 'value' attribute to your Inputfield twice. First before it processes the form (the existing value), and during processing the form (the new value). That enables your Inputfield to tell if the value has changed. If you start working with more complex data types in your Inputfield, you may need to tell PW when the value has changed. You can do that just by calling $this->trackChange('value') in your Inputfield. This probably isn't necessary in your case, but if you run up against a wall, try adding that in your Inputfield's processInput() function, just in case. Post some code! I think it'll be a lot easier to help if I can see what you are doing. It's a lot easier for me to understand code by seeing it rather than reading about it. If you don't want to post here, feel free to PM it to me too.

This is the same issue I ran into with IE8 awhile back. I never could figure out why it lost the selection. I'm sure there's an answer but put a lot of time towards it and never was able to solve it. TinyMCE is a pretty complex piece of software, and IE is an interesting browser. There's never a dull moment when those two get together. I would really like to find a solution here. Hopefully between all of us, we'll be able to find a solution.

But if you want the skyscrapers profile for 2.0, just drop me an email and I'll send it to you. The template files are largely the same, but 2.0 is now an old version, so not as useful to have the profile in that version anymore. Still, I've got it if you want it.

Currently yes. But I think you just pointed out something kind of silly in PW's date field. If it's not set, it's going to return a date in 1969 (the first date tracked by a unix timestamp). That's not what we want. I just committed an update that makes it return a blank string if there is no date value set. So once you get the latest commit, you can do this: if($page->startdate) echo $page->startdate; Or you can just echo the startdate and expect it'll be blank if nothing's been set there. There have been a lot of commits in the last few days, so if you haven't updated already, give everything a good test before updating your live sites. Though I don't expect there are any potential problems, but I'm always a little overcautious any time I push a lot of new code to the repo.

Small correction: sanitizeValue is an abstract method in the Fieldtype class, so you have to implement it. But just make your implementation nothing but this for now: public function sanitizeValue(Page $page, Field $field, $value) { return $value; }

That's correct. Anything set to a $page passes through sanitizeValue, regardless of where it comes from. But I suggest that you ignore the sanitizeValue method for now, because there is no reason to implement it at this stage (unless you've extended another Fieldtype that does something with it that you don't want). I'm not sure that I understand exactly what you are saying. But your sanitizeValue shouldn't attempt to modify the value it's given unless it's of the wrong type. So in your case, I would suggest leaving sanitizeValue out of the equation for now and don't bother implementing it until you have everything else working. If things are working until you try to implement them, try doing this: leave the existing implementation in place, but put in sleepValue/wakeupValue methods just to observe what's going back and forth. That should help to clear up ambiguity about why it might be breaking when you try to provide an implementation for them. <?php public function ___wakeupValue(Page $page, Field $field, $value) { $value = parent::___wakeupValue($page, $field, $value); echo "<pre>wakeupValue: "; var_dump($value); echo "<pre>"; return $value; } public function ___sleepValue(Page $page, Field $field, $value) { $value = parent::___sleepValue($page, $field, $value); echo "<pre>sleepValue: "; var_dump($value); echo "</pre>"; return $value; } That way you can see exactly what data is getting sent back and forth without modifying it. Once you know exactly what's getting sent around, you should be able to expand upon it. If you are dealing with a multi field table, then an array is going to be used as the native storage format, and it will have an index called 'data' that contains the primary value. But it's best to observe exactly what's there rather than me tell you since I don't know the full context of your situation. You should be able to do what you are wanting to do. Lets say that you want to have your 'id' integer that's stored in the database convert to an instance of MyClass during runtime. Here is pseudocode for what you would want to do: <?php // convert an instanceof MyClass to an integer id function sleepValue($value) { return $value->id; } // convert an integer id to a MyClass function wakeupValue($value) { return new MyClass($value); } // make sure $value is a MyClass, but don't bother with this for now... function sanitizeValue($value) { if($value instanceof MyClass) return $value; else throw new WireException("value was not a MyClass"); }

Formmailer, thanks for making this – it looks like you've done a very nice and complete job putting this together. I look forward to testing this out!

In your case, you can probably just have sanitizeValue return the value it's given (or don't override that method at all). The sanitizeValue method is just meant to sanitize a value set to a Page. The simplest example would be for an integer field. Lets say that you did this in the API: $page->some_integer_field = 123; When you do that, what happens behind the scenes is that $page does this: <?php $field = wire('fields')->get('some_integer_field'); $fieldtype = $field->type; $value = $fieldtype->sanitizeValue(123); // or whatever value you set $this->set('some_integer_field', $value); So your sanitizeValue method gets called every time a value is set to the page for any known field. In the case of FieldtypeInteger, it would just need to ensure that the value is in fact an integer. So FieldtypeInteger's sanitizeValue() implementation would look like this: <?php $value = (int) $value; // typecast to an integer return $value; That sanitizeValue method just needs to sanitize and convert it to whatever the expected format is. Implementation of this method is not crucial, so this is something you can come back to. This is different from sleepValue and wakeupValue because those two are for converting data to and from the format it should be in the database. For something like an integer (like above) sleepValue and wakeupValue wouldn't need to do anything at all, since an integer will be represented the same way in the DB as in the $page. But more complex things that take values from the DB and convert it to/from an object are more the type of thing where sleepValue/wakeupValue come into play. I'm very happy to have you experimenting with it. This is also helpful to me as I move towards making more official documentation and tutorials for creating this stuff. Definitely!

That's correct. wakeupValue is where you take whatever value is stored in the DB, and expand that to be how you want the value represented at runtime. So in your case, it sounds like you are doing it right if you are taking that ID and then building a an object from it with other data. sleepValue does the opposite of wakeupValue. It will be given the value you created with wakeupValue, and your sleepValue needs to take that and reduce it back to its representation in the DB. In your case, it sounds like that is just the ID number.

Those DatabaseQuery classes were mostly designed around the needs of the PageFinder, so I'm not sure how much utility it would really have outside of that. Personally, I don't like abstracting on top of DB queries (ActiveRecord and the like) but this was one case where multiple classes had to work on the same query, so it would have been dumb to do it any other way – that's where those DatabaseQuery classes came from. If you find them useful for something else, that's great, but these aren't meant as a real framework DB/query wrapper, so you are likely to come across limitations if you want to stretch them. But if you want to use them, then extend the class and override the fuel() function to point 'db' to your own. If there is more demand to provide a real framework DB query wrapper, we can add a setDb() method or something like that (after expanding the utility of the classes). But because these classes are just built for the internal needs of PW, I would look at including something like CodeIgniter's ActiveRecord if you are needing a full blown DB query wrapper.

I agree, I don't think Safari on the iPhone lets you do that (I've tried on a few occasions). Though not sure why not, sure seems like it should.

This is just using the MarkupLoadRSS module and pulling from SMF's RSS feed.

Thanks Dom, let me know what you find. If it's still doing that on a stock installation, and you don't mind giving me temporary SSH or FTP access, I expect I should be able to find a solution quickly. Though we'll find what's going on either way.

Great, glad you got it figured out. I was stumped for the moment