ryan
-
Posts
16,715 -
Joined
-
Last visited
-
Days Won
1,517
Everything posted by ryan
-
if($tagPage instanceof NullPage) { ... } You can also do this to accomplish the same thing (at least, I prefer the syntax): if(!$tagPage->id) { ... } Also wanted to mention that the call to $videoPage->of(true); should instead be $videoPage->of(false). That turns off output formatting for the page, putting it in a save state (vs. presentation state).
-
From the API you can call the removeVariations() function from any image: foreach($page->images as $image) { $image->removeVariations(); } That actually removes them at the time the function is called, so you don't need to do a $page->save().
-
I wasn't sure what first what you meant by switcher, but now I think I get it. Assume I understand correctly, you need something to target the switch like a GET variable, i.e. domain.com/?theme=pretty Then before you send any output (like before your <doctype>) you'd check for that GET variable and stuff it in the session. if($input->get->theme) { // set the theme $session->theme = $sanitizer->pageName($input->get->theme); } Now that value in $session->theme will be retained regardless of what page they click on, or at least until they set another. When you get into the <head> part of your document where you are going to be outputting the stylesheet links, you would just check the value of $session->theme: if($session->theme == 'grunge') { $css = 'ugly.css'; } else if($session->theme == 'pretty') { $css = 'baby-unicorn.css'; } else { $css = 'default.css'; } echo "<link rel='stylesheet' type='text/css' href='{$config->urls->templates}styles/$css' />";
-
This is great Soma, thanks for writing this. I'm finally going to have to try out the GitHub client for Mac myself (I've been just using command line).
-
This sounds like a bug to me. I'll take a closer look here, thanks for pointing it out.
-
I would expect to get this error if doing a "continue;" outside of a foreach. Did you place the "continue;" within the foreach? It should have been placed right before the line that has: $r->setOutputFormatting(false); If that still doesn't work, then you can just use an if() instead: if($input->post->submit) { $r->of(false); // turn off output formatting $r->cost = $input->post("cost_$r"); // and do the same with your other fields $r->save(); }
-
Here is the first release version of the Blog Profile! http://modules.proce...s/blog-profile/ It is now up on GitHub as well: https://github.com/r...ign/BlogProfile Below is a lot more talk about this blog profile and how it works, but if you just want to install the profile and test it, it's not necessary to read anything further unless you want to. I've simplified this a lot from where it's been. It does all the same stuff on the front-end, but the code behind the site is no longer a huge departure from the basic profile. I've rebuilt this profile 3 times trying to find the right balance between making it as flexible as possible and making it as easy to understand as possible. I think it's got a better balance now than before. It's now at a point where it does everything it always has, but the template code behind it should be a lot more accessible and easy to understand. There is no longer a separate module or API variable. Everything here just happens in /site/templates/ files. Consistent with making it simpler, I've also removed the drag-n-drop theme support. While it was cool to have, it always felt a little dirty introducing some kind of proprietary theme support that was so different from the way I'd build any other site. This thing is pretty darn simple to theme as it is (just edit a CSS file). Maybe we'll take it further in the future, but we don't have many PW site profiles out there right now (1 or 2?) and so I decided this profile needed to stay more accessible on the back-end. How the template files work In ProcessWire there are any number of ways you can use your template files. In this case, we are using our template files (in /site/templates/) to populate 3 variables ($content, $headline and $subnav) and then including an HTML file (main.inc) to output them in the right places. The $content variable represents the center (body) column, the $headline variable represents the text headline of the page, and the $subnav variable represents the navigation that appears in the left sidebar. Once one or more of these variables is populated, the template file includes the /site/templates/main.inc file. That main.inc file is just a big HTML file that outputs the $content, $headline and $subnav variables in the right places. We've made an attempt here to separate most of the logic used in the template files from the output. Most of the markup is generated from files in /site/templates/markup/. These files are included from the template files to output specific things like a blog post, comment, etc. Because a lot of output needs are similar among the various template files, we've created a file called /site/templates/blog.inc that has a few shared functions in it. If you look in any of the template files, you'll see that most of them include blog.inc as the first thing. This blog.inc file also initializes our $content, $headline and $subnav variables, mentioned earlier. Outline of /site/templates/ with this profile /site/templates/blog.inc Shared blog-specific functions included by most site templates. /site/templates/main.inc The main HTML markup file through which everything is output. /site/templates/markup/ Contains PHP files that generate markup for specific things like posts, comments, etc. This is separated from the site templates to make it simpler for you to modify the markup if you want to. This is primarily used by the blog.inc functions, but also included by a couple templates as well. /site/templates/skeleton/ This is the Skeleton CSS framework. It is identical to the one they distribute except we added a wider viewport to it. You probably wouldn't have much need to edit anything in here. /site/templates/styles/ Stylesheets used by the blog profile. The most useful one in here would probably be theme.css, which contains all the color definitions for the profile. /site/templates/scripts/ Javascript files used by the blog profile. Not much is happening in here at present.
- 197 replies
-
- 12
-
-
Thanks for the info. That's easy to implement, so I went ahead and added it now and will read more tomorrow. Soma let me know if this does what it's supposed to? If you include a 'callback' get var, it just echos it back (after pageName sani) in the format you mentioned in the earlier message.
-
@Pete: thanks I've fixed the created/modified date bug. @Soma and @Apeisa: I'm confused about the best way to solve this. Just adding the callback var? I guess I'm not familiar with this technique. Since it's probably not safe to just echo back a GET var, what sort of filtering/sanitization should I do to it? I will get this working tomorrow morning.
-
"Allowed memory size" issue when working with many large $pages calls
ryan replied to evanmcd's topic in API & Templates
Those API calls are probably loading all 10k pages since you are doing the count after the query. Try changing it to this and it should fix everything: $totalUnpublished = $pages->count("template=entry,status=unpublished"); $totalPublished = $pages->count("template=entry, parent!=/entries/rejected/"); $totalRejected = $pages->count("template=entry,parent=/entries/rejected/,include=all"); Another way you could do it would be this (though I prefer the way above): $totalUnpublished = $pages->find("template=entry,status=unpublished, limit=2")->getTotal(); $totalPublished = $pages->find("template=entry, parent!=/entries/rejected/, limit=2")->getTotal(); $totalRejected = $pages->find("template=entry,parent=/entries/rejected/, include=all, limit=2")->getTotal(); Either of those examples were perform at the same speed (which should be very fast). -
Beyond my response from your PM, I'd also suggesting doing a redirect after the logout, just in case that's causing any issue here. if($input->get->logout) { $session->logout(); $session->redirect('./'); } Also make sure that no data is sent before the logout and/or redirect. Cookies (sessions) and redirects happen as a result of http headers, which are sent before any output. Once output is sent, headers are no longer applicable. So you could get unusual behavior if you'd output anything before the $session->logout() call.
-
Your executeFetch method will only get called if the URL is /path/to/your/page/fetch. Since Process modules make use of URL segments, make sure your template has urlSegments enabled. I think what your executeFetch method is doing looks fine from the aspect of it returning JSON. Note that PW is going to output that JSON in the middle of an admin template unless the request actually comes in through ajax. So if you see JSON in the middle of PW's admin template, don't worry, just try it again pulling the data from ajax and PW should detect that and only output your JSON.
-
Attached is an update to /wire/modules/Fieldtype/FieldtypePage.module that lets you do this, once you replace your existing file with the one below. You should be able to specify just about any native or custom page field after the dot, like above (where we're using 'title'). If anyone can test it out to confirm I'd appreciate it. I'll commit to the source after testing a little more locally too. FieldtypePage.module This type of syntax is already used by repeaters. But if you mean something like: "repeater_field.referenced_pages.title%=$query", I don't think the attached update would let you do that, though havent' tried. If it doesn't, it's probably not much of a stretch to support it though.
-
I think you can do this with just having a single page. When your module creates your template, assign this property to it before saving it: $template->altFilename = 'admin.php'; That will make your template use the existing admin template when it comes time to render the page, hopefully executing your process along with it. If you want to test it out before going in the code, this is also a property you can set from PW's template settings. Edit the template and then click on the 'advanced' tab. You'll see a setting there called 'Alternate Template Filename'.
-
Just for clarification, the intended search would be for: (body OR title contains $query) OR (referenced_pages contains $my_referenced_pages) and not this? (body OR title contains $query) AND (referenced_pages contains $my_referenced_pages) In ProcessWire you can't do the first one in 1 find(), at least not yet. Though the second one you can do and is pretty common: body|title%=$query, referenced_pages=$my_referenced_pages I'm hoping to make this possible pretty soon (but it isn't yet): body|title|referenced_pages.title%=$query
-
Module: Video embed for YouTube/Vimeo (TextformatterVideoEmbed)
ryan replied to ryan's topic in Modules/Plugins
I wish that was me. You are thinking of Marty. I've not launched a bunch of projects lately, not by a long shot. The ones I posted about in Pub a month or two ago were done over a long period of time. -
What would probably be best is to abstract it to a $this->copy($url, $dest); function that checks what's available. If CURL is available, it delegates to $this>copyCURL(). If not, it checks if ini_get(allow_fopen_url) and calls $this->copyPHP(). Or something like that. ZipArchive is another thing that may not be in all installations (PW uses exec('unzip') instead, which also isn't universally available. If the file system isn't writable, using PHP to FTP to localhost is another option to perform installation. You are right, lots of potential factors. But probably best to start simple and require ZipArchive and a writable modules dir, and then expand upon that later. Do you mean like uploading a ZIP file of a module? Looking good! I just let my Modules Manager update itself, which is always fun. Language packs are already installable from the admin, so don't think we need to do anything there. Admin themes would be a fun thing to have installable in the modules manager, longer term probably. Site profiles won't ever need to be installable through the Modules Manager, since they get installed before the site exists.
-
Good suggestions. This makes sense to me. I've added the code to add a class of PageListItem_[template name] to each item. Going to test a bit more locally and commit early this week. Thanks, Ryan
-
That's a good idea by Soma. But I don't see any reason why these functions shouldn't be hookable in ProcessField, so I've just made them hookable. The following are now hookable: buildEditForm buildEditFormBasics buildEditFormCustom buildEditFormAdvanced buildEditFormDelete buildEditFormInfo I've also added a function to ProcessField: getField() -- returns the current field being edited (as set by buildEditForm) So if you make a hook into one of the above, you'd retrieve the field like this: public function yourHookFunction(HookEvent $event) { $process = $event->object; $field = $process->getField(); // ... }
-
Regarding learning OOP, WillyC actually makes a good point there about something that is kind of helpful in learning it. Thinking about interfaces in code the way you do interfaces with the objects you interact with in real life. Objects are meant to be self contained things that have defined inputs and outputs, hiding the [potentially complex] details of how it happens and just giving you predictable inputs and outputs. If you start relating objects in real life to their equivalent in code, things start to come together a little easier and it gets your mind in the right place. Stepping back from his toilet example and use something like a faucet instead. The inputs are knobs that set the temperature and strength of flow. And the output is water at the temp and flow you set. $faucet = new Faucet(); $faucet->setTemp(97); $faucet->setFlow(10); echo $faucet->render(); (or something like that)
-
Who's using octals? The module version number was never meant to be octals. It's just meant to be a plain integer. If you've ever seen me put leading zeros in a version number (whether in modules or in examples) then it was by mistake (let me know where so I can fix it!) If you want to have version 0.0.1 then use: 1 If you want to have version 1.0.0 then use 100 If you want to have version 2.1.1 the use 211 Does this make sense? Or am I misunderstanding the question?
-
ProcessWire Conference 2013 / London / Cambridge
ryan replied to ryan's topic in News & Announcements
Thanks, glad to hear there is some interest. I'll keep looking into it more here. Cost is certainly a big factor to me too. Just flying over there may be beyond my budget resources, but not going to worry about that now. So if we find the costs could be a hindrance to anyone, then we'd look at alternatives or delay further in the future. However, my understanding from this client (who is also family, btw) is that it really is the whole point of doing it this way… Kind of piggy-backing and sharing the expertise, planning and resources of another conference to get the most value. Planning this kind of stuff really isn't my thing, and so would need someone to take care of all the details, which is what they do. I'm also not particularly comfortable as a presenter (I like to type, not talk ), but am more interested in rising to whatever is best for growth of the ProcessWire project, so figure this is a good opportunity worth exploring. -
Soma, an alternative to libcurl is to just use copy(). At least, that's how ProcessWire does it with images that you add() from remote URLs. It's true that it requires PHP to have allow_url_fopen setting enabled. But then again so does file_get_contents(), which you are already using with a remote URL. copy("http://remote file", "local file"); I'll be happy to help, though I think you've already got as much "advanced stuff experience" as anyone here. I don't want to take over, just want to collaborate and work towards getting it in the core (if you are open to it), but you stay in charge of it. (I already got too much to keep track of). This will be one of the best and most important core additions to date. It literally eliminates the need to add future optional core modules. For instance, there would no longer need to be core-but-uninstalled modules like LanguageSupport, FieldtypeRepeater, etc., since they could be installed just as easily via the Modules Manager. I am wondering how we should integrate this into the existing Modules page in the PW admin? I'm thinking this should probably replace the current Modules list in PW, but there would need to be a clear differentiation between what's installed and what's installable (maybe each as a tab on the modules screen). The "what's installable" screen should probably start out with a category selection, since I'm anticipating the installable modules to get into the hundreds and eventually thousands, so needs to be more scalable than a long linear list. Just initial thinking and ideas. You may have already put a lot more thought on this stuff than I have.
-
It looks like hotlinking images from the forum also doesn't work. Not sure if it's the same issue with whether the user is logged in, or if it's just that the URLs are so long and complex that BBCode no longer recognizes them as valid image URLs. During one of the next updates to the directory, I'm hoping to add file upload capability for image and archives, for the situations where GitHub may not be in use. I don't know? Curious if anyone else does. I don't think I've worked with octal numbers in PHP before.
-
This is something we had on the roadmap a long time ago back when it was just a forum thread. I think it's a good idea for sure. It would be nice to have the PW API fully available via javascript. It seems like there aren't many hurdles to overcome with it, at least to implement the $pages API variable for read-only access. It could use something like the Ajax page search API (but built for the front-end).
