ryan
-
Posts
17,232 -
Joined
-
Days Won
1,700
Everything posted by ryan
-
If you want to make one, that'd be awesome–definitely go for it! If you do, let me know if there's anything I can do to help.
-
The only thing I can guess here is that your version of PCRE doesn't have UTF-8 options bundled into it. I think this is one of those things that is not universally part of all PCRE installs, and I've found the PCRE version sometimes varies even on the same version of PHP. Another route you could take would be to just match all non-word characters up till the http, like this: $page->body = preg_replace("#<p>[^\w]*https://www.youtube.com/watch\?v=([^\s&<]+).*?</p>#i", $replacement, $page->body); There isn't any reason why that shouldn't work, but I won't make any assumptions as these characters are clearly difficult to match and may be affected by the PCRE version since I can match them here but you can't there. Except that Youtube, Vimeo, Facebook, etc., are companies, not universal standards (though I'm sure they'd like you to think otherwise). Companies and their services come and go. My opinion is that anything tied to a company or specific outside service belongs as add-ons rather than native to PW or TinyMCE. So I think this would be a great idea for an add-on module for PW, something that knows how to recognize the URLs for major services and automatically inserts the proper iframe/embed code... sure would be convenient anyway.
-
I think in this case you'd point both domain.com and campaign.com to the same IP. If your needs were simple, your template file could just check what host it's being served from, i.e. <?php if(strpos($config->httpHost, 'campaign.com') != false) { // display or load something for campaign.com } else { // display or load something for domain.com } If your needs were more complex, then you could create an autoload module to handle your flow control. That module's init() would modify $_GET['it'] that hold's the path to the page requested. That $_GET['it'] var is the means by which PW's .htaccess file sends the requested URL to ProcessWire. Since an autoload module is init()'d before the page is loaded, it has the opportunity to change it, i.e. <?php public function init() { if(strpos(wire('config')->httpHost, 'campaign.com') !== false) { // change path like /about/contact/ to /campaign.com/about/contact/ $_GET['it'] = '/campaign.com/' . ltrim($_GET['it'], '/'); } } Then your campaign.com site structure would just be created below a page named '/campaign.com/' in your site tree. I've not tested this out, but I can't see any reason why it wouldn't work. Also, I'm sure the same thing could be accomplished via the .htaccess file rather than an autoload module, but I'd have to do more research on that before I could post an example.
-
I like the idea of a quick 1-page reference to PW's API. I actually think we could fit the whole API on a coffee mug. But a 1-page printable PDF API quick-reach document would be great. I will think more about this.
-
Lets see if we can get a quick-start tutorial going here. We'll start with something really simple and then work up from there. Tell me when something makes sense and when it doesn't and we'll adjust as we go. My thought is that we'd make a tutorial that plays on the 'hello world' phrase and lists information about planets in the solar system, starting with Earth. To keep it simple, we'll assume that the basic site profile is installed, as that's what comes with ProcessWire (so there's no need to uninstall anything). But we won't start using any of it's files tat this stage. Instead, we'll start out by creating our own files. STEP 1 – Create a template file Create a new file called: /site/templates/planet.php, and copy+paste the following HTML into that file: <html> <head> <title>Earth</title> </head> <body> <h1>Earth</h1> <h2>Type: Happy planet, Age: Millions of years</h2> <p>Earth (or the Earth) is the third planet from the Sun, and the densest and fifth-largest of the eight planets in the Solar System. It is also the largest of the Solar System's four terrestrial planets. It is sometimes referred to as the World, the Blue Planet, or by its Latin name, Terra.</p> </body> </html> The above is just a plain HTML file with nothing specific to ProcessWire. We will use this as the starting point for our template, and we'll go back and modify it later. STEP 2 – Add a template to ProcessWire Login to ProcessWire admin and go to Setup > Templates. This page shows a list of templates currently in the system. Click the Add New Template button. On the next screen that appears, you'll see it found your "planet" template file. Check the box next to the planet template and click Add Template. You may ignore any other options that appear on this screen. STEP 3 – Creating a page using your template Your planet template is now in the system and ready to use, but it's not being used by any pages. So lets create a page that uses the planet template. In the ProcessWire admin, click Pages in the top navigation. This is a site map if your page structure. We want to create a new page under the homepage, so click the new link that appears to the right of the home page. The next screen has 3 inputs: title, name and template. Enter "Earth" for the title, and the name should populate automatically. For the template, select planet. Then click Save. Now you have created a new page using the template that you added. You are now in the page edit screen and you should see your title field populated with "Earth". Click the View link that appears on this page edit screen. You should see the output of the HTML from step 1. Click the back button in your browser to return to the edit screen. STEP 4 – Creating a new field Now you know how to create a template and a page using that template. You could create more pages using the same template if you wanted to. But that wouldn't be particularly useful – this template file is just a static HTML file. Lets make it dynamic by creating some fields and adding them to it. We are going to create 3 fields to represent the pieces of data that currently appear in our static template. These include the planet's type, age in years, and a brief summary. We will call these fields: planet_type, planet_age and planet_summary. In ProcessWire admin, click Setup > Fields. This screen shows a list of fields currently in the system, most of which are general purpose fields for the basic profile. For the purposes of this tutorial, we are going to ignore those and create our own. Click the Add New Field button. On the next screen, enter "planet_type" for the Name, select "text" as the Type, and enter "Planet Type" for the Label. Then click the Save Field button. Now that your field is saved, you are on the Field Edit screen. At this point, your field is created and ready to be added to your planet template. Optional: While editing your field, click the details tab where you'll see a select box for Text Formatters. Select "HTML Entity Encoder" – this ensures that characters like "<", ">" and "&" will be converted to HTML entities and not confused as HTML tags. While not required, it's a good practice for text fields like this. After you've done that, click the Save Field button. STEP 5 – Creating more new fields In step 4 we created the planet_type field. Now we want to create the planet_age and planet_summary fields. So in this step, you'll want to do the same thing for the remaining two fields: Create the planet_age field exactly like you created the planet_type field, but enter "Planet age in years" for the label. Create the planet_summary field exactly like you created the planet_type field, but chose "textarea" as the Type and enter "Planet summary" for the label. Note that a "textarea" field is just like a "text" field, except that it can contain multiple lines of text. STEP 6 – Adding new fields to your template Now that you've created 3 new fields, you need to add them to your planet template. In ProcessWire admin, click Setup > Templates > planet. You are now editing your planet template. In the Fields select box, choose planet_type, then planet_age, then planet_summary. You will see each added to the list. Cick the Save Template button. STEP 7 – Editing a page using your template Now that you have new fields added to your template, go back and edit the Earth page you created earlier and populate the new fields that are on it. In ProcessWire admin, click Pages at the top, then click the Earth page, and click the edit button that appears to the right of it. You are now editing the Earth page you created earlier. You should see the new fields you added, waiting for text. Enter "Terrestrial planet" for Planet Type Enter "4.54 billion" for Planet Age in Years Paste in the text below for Planet Summary and then click Save. STEP 8 – Outputting dynamic data in your template file While still in the page editor from step 7, click the "View" link to see your page. Note that it still says "Happy planet" for type (rather than "Terrestrial planet") and "Millions of years" rather than "4.54 billion years". That's because the page is still being rendered with just the static data in it. We need to update the template file so that it recognizes the fields we added and outputs the values of those fields. Edit /site/templates/planet.php and replace the static text in there with tags like this, replacing field_name with the name of the field: <?php echo $page->field_name; ?> If supported by your server, you may also use this shorter format which some people find easier to look at and faster to enter: <?=$page->field_name?> Here is the /site/templates/planet.php file updated to output the content of the page using tags like the above: <html> <head> <title><?php echo $page->title; ?></title> </head> <body> <h1><?php echo $page->title; ?></h1> <h2>Type: <?php echo $page->planet_type; ?>, Age: <?php echo $page->planet_age; ?> years</h2> <p><?php echo $page->planet_summary; ?></p> </body> </html> After making these changes, save your planet.php template file. Now view your Earth page again. You should see it properly outputting all of the content you entered on the page, including "Terrestrial planet" for Type and "4.54 billion years" for age. Any changes you make from this point forward should be reflected in the output. STEP 9 – Creating more pages, reusing your template For this last step, we'll create another page (for Jupiter) using the same template just to demonstrate how a template may be reused. In ProcessWire Admin, click Pages and then click the new link to the right of the home page. Enter "Jupiter" as the Title and select "planet" for the Template. Click Save. Now that you are editing the Jupiter page, enter "Gas giant" for Type, enter "4.5 billion" for Age in Years, and copy+paste the following for Planet Summary: Click the Publish button and then View the page. You should now see your planet template being used to output the information for Jupiter rather than Earth. CONCLUSION In the above, we covered the basics of how to develop in ProcessWire, including the following: Creating templates and their associated template files Creating basic text fields and adding them to templates Creating and editing pages that use your templates Outputting the values of fields in template files If all of this makes sense so far, I thought we'd follow up next with a tutorial to take this further: Adding and outputting photos for each planet Creating navigation that lists all the other planets that have pages in the system …and we'd keep building upon the tutorial from there. If you all think this tutorial is helpful, then perhaps this can be a draft for a real tutorial we'll put on the site, so all of your help is appreciated in making this as good as it can be.
- 66 replies
-
- 17
-
-
-
Not without installing a module to do it. The LoginNotifier module keeps track of logins in a log file in /site/assets/logs/. I don't know of any modules that log every page edit at present, except for the Page Revisions module I'm working on–though that's not technically a log, but a revision/version system. But all the hooks are there to make very detailed logging possible–good idea for a future module.
-
Great, that's it then. That also explains why the floats were getting rounded to integers. Now maybe I should go back to floats in the DB, not sure. But I've just committed an update that replaces any commas with periods when it sets the lat/lng values, so hopefully that will fix it regardless of the localization settings. Thanks again for your help testing. The whole family is now up and I'm getting told to turn off the computer. Glad we were able to fix this one. -
Interesting. Still can't duplicate here, so I'm wondering if this has something to do with PHP or JS localization. Would a number like 33.7766779 be represented any differently than that where you are? like 33,7766779 (comma rather dot). The module will set the number to blank if is_numeric() fails, so I'm wondering if is_numeric() is failing due to differences in localization.
-
Try it with the 'u' modifier at the end. Just tested here and it does work. That enables "\s*" to match whatever those odd whitespace chars are. I was also able to duplicate that \s won't match without the 'u' modifier.
-
Unfortunately I don't know where it could be getting rounded to an integer. There are 3 places where it could be: PHP, MySQL or JS. I'm guessing it's not JS though. Clearly there's some server side precision setting that's breaking the floats. Rather than worry over that, I'm just going to use strings instead. I just pushed an update that changes these to be strings in MySQL rather than FLOAT(10,6). If this doesn't fix it, then I'm really wrong about what the problem is. You'll have to delete your current MapMarker field and create it again since the schema has changed. Thanks for our help in testing this.
-
There must be some unusual UTF-8 whitespace in there or ascii 160s or something like that. Adding the 'u' (UTF-8) modifier to the end should fix it: $page->body = preg_replace("#<p>\s*https://www.youtube.com/watch\?v=([^\s&<]+).*?</p>#iu", $replacement, $page->body);
-
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.
