ryan

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

Can you confirm that the URL is correct, like when it shows the ? on the front end? Are you able to view files/images from any pages? Or does this universally affect all file-based assets on your site?

You can edit it in Setup > Fields

I got your PM and tried out the site. Definitely something strange going on, because all those URLs with the server path in it should be resulting in 404s, yet they aren't. Do you have any other modules installed other than the default ones that come with PW? Would you mind installing a new/stock copy of PW in another directory on the server, just to see if it behaves in the same manner? That will at least tell us whether we need to look more at the server and your site profile, or if we have new situation that is triggering a yet unknown bug in the core.

Those are the expected values there. That makes it more of a mystery because it looks like ProcessWire isn't having any issues getting the proper values from your server (there's no issue with the server environment). What you are seeing in your output is the value of $config->paths->root rather than $config->urls->root. My best guess is that something, somewhere is setting $config->urls = $config->paths (or at least, $config->urls->root = $config->paths->root). Since we haven't seen this elsewhere before, I'm wondering if there might be something in your site that's reassigning that $config var, perhaps a module. One way to test is to install a new stock installation somewhere else on the same server and see if it produces the same result. If it doesn't, then we have to look at what's different with your site. Also, I'm assuming that this breaks all of the links. If it was substituting the server's disk path for the URL, then everything would lead to a 404. But just want to confirm? If the links aren't broken, then we're very likely dealing with some server or browser "feature" that is trying to translate URLs to paths... but I've not heard of such a thing.

But is having past versions of pages query-able in that manner very useful? I'm sure there are uses, but I couldn't think of any situation where I would need it to be (outside of page_id and timestamp). I think of past revisions as archives kind of like a Time Machine backup on my Mac. The main value is just in having the archives. The data is no longer current and won't ever be queried for anything other than page_id or date. At least, that's my outlook on it. But I'm sure the same could be said the other way around. It's just a matter of where you want to make the compromise. I think having selective versions of pages like you mentioned is a good compromise. This is something that I think may be best to implement in the core ProcessPageEdit module. Right now I don't think the hooks are there to do it without having a module come in and create a clone and modify the POST 'id' var before ProcessPageEdit init() is called. Though I suppose you could hook in before Pages::save, see if there is a $_POST['save_draft'] var set (or something like that), clone, then substitute in your new draft version. There are options, but it's not as straightforward as I'd like. It would probably be a frustrating first module to build. I think this capability belongs in the core, and it will be straightforward to implement there. But if you want to try building the capability, I'd recommend working in the core module: ProcessPageEdit. You can always save it out as another module and just change the Process being used by the /processwire/page/edit/ page in the system.