teppo
-
Posts
3,265 -
Joined
-
Last visited
-
Days Won
112
Everything posted by teppo
-
Minor glitch (if you can even call it that): your 404 page is a bit unhelpful. Had an old link to /de/, which ended up serving a blank page and confusing the heck out of poor little me. Site itself is just fabulous
-
@Wanze: are you sure about that? Taking a look at get method in Page.php (which, in turn, is called by magic method __get): public function get($key) { $value = null; switch($key) { ... case 'next': ... $value = $this->{$key}(); break; ... Sorry for all the dots there, but anyway: as far as I can see, actually next equals next() unless PW has already "cached" it's return value as a property, which shouldn't be the case here. And I don't see why above warnings wouldn't apply here either
-
There is a warning about next() and prev() in Page.php regarding larger amount of siblings: How big a problem this will cause depends on how many sibling pages you've going to have in each branch there (and the number of branches, of course, if there'll be a lot of those.) I tried to implement next and prev on a site that, at that time, had around 1500 siblings in each branch and was growing fast. That resulted in significant speed problems for each page load. I didn't have caching on at the time, though -- that definitely helps a lot. With caching enabled PW only has to build each page as a static HTML file once. Even if it's a bit slow, it should only affect first page view of each page in that branch. On the other hand, if content is updated very regularly (which I kind of doubt would be a problem here) this would of course diminish the benefit of caching a bit. All in all, I'd suggest that you implement this, do some tests regarding speed and see for yourself if it's going to be a problem. If possible, add some extra dummy pages to see how things will change once your site grows.
-
Minor addition to above: $page->parent->first()->url should be $page->parents->first()->url.. or just $page->parent->url, which already returns first parent. Also: you could use $page->child instead of $page->children->first() to get first child Other than that, this seems to work properly. Now, I'm sorry for taking this thread a bit off track, but there's something strange going on here I'd like to point out: I was actually going to suggest a very similar approach, but after testing it ran into a problem that kept crashing whole Apache. Seems to be somehow tied to recursive function in sitemap template of default site profile and also happens with solution provided above. Once I comment out sitemapListPage() call in template file everything works properly, with it in place Apache keeps dying on me. Just for reference, code I was going with for the original problem was this: $next = ($page->numChildren) ? $page->child : $page->next; if ($next instanceof NullPage) $next = $page->parent->next; echo ($next instanceof NullPage) ? "This is the end" : "<a href='{$next->url}'>{$next->url}</a>"; After using either my approach or the one @horst suggested above, this seems to cause massive headache to Apache: function sitemapListPage($page) { echo "<li><a href='{$page->url}'>{$page->title}</a> "; if($page->numChildren) { echo "<ul>"; foreach($page->children as $child) sitemapListPage($child); echo "</ul>"; } echo "</li>"; } sitemapListPage($pages->get("/")); What am I missing here?
-
Edit: oh, wait, sorry -- completely misread your question
-
Microdata is always good to have, thanks for sharing this! Personally I wouldn't depend too much on data-vocabulary.org though. Their home page makes it pretty obvious that schema.org is the new toast of the town. With schema.org vocabulary breadcrumbs could be implemented like this: <body itemscope itemtype="http://schema.org/WebPage"> ... <div itemprop="breadcrumb"> <?php foreach($page->parents as $parent) { $end = ($parent === $page->parent) ? "" : " > "; echo "<a href='{$parent->url}'>{$parent->title}</a>{$end}"; } ?> </div> <!-- this follows strictly schema.org example --> Or with markup matching above example: <body itemscope itemtype="http://schema.org/WebPage"> ... <div class='breadcrumb' itemprop='breadcrumb'> <?php foreach($page->parents as $parent): ?> <li> <a href='<?php echo $parent->url; ?>'> <span><?php echo $parent->title; ?></span> </a> <span class='divider'>›</span> </li> <?php endforeach ?> <li> <?php echo $page->title; ?> </li> </ul> <!-- this isn't exactly what schema.org describes but should still be valid.. --> There's quite a bit of discussion floating around whether schema.org version of breadcrumbs is actually useful, but it is what their example currently suggests. Note also that breadcrumb is a property of WebPage, ie. you'll have to be in that context in order to use this properly.
-
So when you submit your search form, you end up at domain.tld/search/ without q GET param? Are you absolutely certain that the form works properly? What about creating another, dummy form with only necessary attributes and fields -- ie. target "/search/", method "GET" and an input with name "q"? If you're a Chrome user, you could also check Network panel in developer tools to see what's happening with your request. Turn "Preserve Log upon Navigation" on with round button at the bottom of dev tools to see if any odd redirects are happening. (Firebug probably has something similar.)
-
.. and now it should definitely be password-protected, hidden or removed to avoid unnecessary confusion / people browsing that instead of real site. Good point, @owzim
-
Using methods/props on non existent fields in a template
teppo replied to owzim's topic in API & Templates
Don't think there's a way around checking if field exists, not at the moment at least. In your echo case you could always do this: if($page->some_radio_button_group) echo $page->some_radio_button_group->value; This doesn't look "cumbersome" or inconvenient to me (none of your examples do, really), but hey -- what do I know.. -
Happy Towel Day everyone! Don't know what that's all about? Don't panic, visit http://t.co/npSvwC5LdX and see for yourself. #towelday
-
It's starting to make sense now Only reason this could break (that I can think of right now) is that you've got multiple database connections open, so it might be necessary to define which connection is used here, like this: mysql_query($sql1, $connection); If that doesn't help, there's probably something else we're missing. You're getting "internal server error" by running this -- any chance you could take a look at Apache (web server) error log somehow? There should be a more detailed description of this error there. PW has it's own error log at /site/assets/logs/errors.txt, which you should also take a look at and another thing you could try (unless this is a live site already!) would be turning ProcessWire debug mode on from /site/config.php. This might give you a bit more information about the nature of this error (though in this case I don't think PW will have a chance to actually put anything there..)
-
Any chance you could specify exactly what (or how) you're trying to do? I don't see a relation between sending email and MySQL, so I'm a bit confused here If it's SQL you're talking about, that shouldn't be a problem at template level, but you should probably run it through PW's own $db object: $sql = "SELECT * FROM my_table WHERE my_field RLIKE 'my value'"; $result = $db->query($sql); while ($row = mysqli_fetch_assoc($result)) { echo "this is a row from database: {$row['my_column']}"; }
-
... and if that's not possible, there's always full page iframe (No, seriously, please don't do that -- it'll screw you in so many ways.) Somas idea is probably your best bet here. Even if moving whole domain is for some reason impossible, you could always point just www (or any other subdomain of your choice) somewhere else and redirect all web traffic there (example.com => 301 redirect to www.example.com.) In any case you'd still require another host for the site.
-
One trick is to use Apache error page as a redirect to index.php and then forcibly fill in GET variable "it" (which ProcessWire uses internally for it's URLs) from REQUEST_URI. Edit: just realized that even though this would make your public site viewable, Admin still wouldn't function at all, partly because a 404 header would always be sent (not to mention that this would probably stop Google bot from indexing your site etc.) Like @diogo already said, this is not doable. Not with a host with such limitations. That's what you should tell your client. If they want to stick with Yahoo! hosting, they're not going to get a proper CMS no matter what they do -- hosting is cheap, so it would make a lot of sense to get another host for the site, even if they (for some unimaginable reason) want to keep their Yahoo! deal..
-
WebFont Loader: easy to use, lightning fast, supports multiple providers, built-in method for handling fallbacks. https://t.co/1ydjE3suhE
-
... and assuming that you don't / can't add all image field names in your code, something like this should also work: $allImages = array(); foreach ($fields->find("type=FieldtypeImage") as $f) { foreach ($pages->find("$f.count>0") as $p) { foreach ($p->$f as $i) $allImages[] = $i; } }
- 3 replies
-
- 11
-
-
I agree that they (Linode) could simplify things a bit for "the common user." The way their service currently works is a bit rough on newcomers. Then again, the whole point of VPS (or dedicated) hosting is that you're in charge, you decide what to install (and what not to install) and how installed applications should be configured, so that's probably not very high on their list. Not to mention that it's a good idea to know how your environment is set up and their manuals are really quite helpful Still, offering an installation package for "common web server needs" -- Apache, MySQL, perhaps PHP / Python / Ruby preinstalled would make sense to me. As a slightly related note, just read an article regarding certain shared hosting provider, and right now I'm even more convinced than before that shared hosting just isn't worth it. I mean.. it's kind of OK if your service isn't going to be very important or contain any "private" or "classified" information, but I would never recommend one of these to a client.
-
It's all about not giving web server (in Ubuntu systems most commonly user "www-data") write access to anything it doesn't strictly speaking need it to. Web server is in direct interaction with outside world and can be tricked to do things on behalf of malicious users. This can be partly avoided simply by not letting it do any more harm locally than is absolutely necessary. Thus it's a good thing that it doesn't have that access by default. If it had (ie. you didn't need to set it during install or right after downloading / cloning install package), I'd be very worried, 'cause that would mean that your web server has full write access not only to /site-default/ but also the directory containing it (and who knows what else.) Obviously locally things are a bit different
-
Symbolic links are roughly the equivalent of shortcuts in Windows environment, if that's what you're more familiar with. They're just pointers to some other location. Having /wire/ as a symlink pointing to another location means that anything you change in that other place is instantly in use anywhere it's linked. This is most likely the easiest way to use one PW core (which, I believe, is what you're trying to achieve here) with multiple directories.. or sharing it with multiple sites in general Creating a symlink is as simple as doing this in your site1 / site2 directory: ln -s /var/www/your/primary/pw/installations/wire wire You'll still need to keep some files (in addition to a /site/ directory) in each subdirectory; most importantly .htaccess and index.php.. though I guess you could make those links to somewhere else too if it really matters.
-
Better image management / better integration with WYSIWYG
teppo replied to mindplay.dk's topic in Wishlist & Roadmap
This is a matter of view, really; textareas hold regular text (even if it's markup) and image / file fields hold images / files (binary data.) It's about separating content by type, even if not necessarily by purpose. Another important thing to note here is that an image isn't limited to one textarea. Current implementation allows one image to be used with as many other fields as necessary -- or none at all if that's preferred. Disagreed. In the context of web content images are never _really_ inline, they're separate entities loosely tied to content (markup) with <img> tags. In some other environments this might make more sense, but not here You're confusing "limitations" with "decisions" here. As always there's more than one way to do it and not doing it "the way most CMS work" doesn't mean it's somehow faulty. Not 100% sure if that's really what you meant here, though that's the message I'm getting. Regarding an actual solution, I'd suggest taking a look at Soma's image manager and perhaps extending on that. I'm certain that contributions would be very much welcome. If it's tags that are bugging you, perhaps this could be tied more strictly with TinyMCE / CKEditor image plugin or something like that? (Sorry, I'm not exactly familiar with this module, so I can't say if that's already something it does.) Edit: after some Googling justboil.me and couple of it's alternatives (TinyMCE image / file upload plugins) popped up. PlugoBrowser seems very nice too, though not free.. but if it's client work you're going to use this for, $20 price tag shouldn't make much of a difference. Perhaps it would make more sense in this case to integrate one of these locally, possibly coupled with a custom plugin / view for selecting images from that location -- unless that plugin already comes with these features, that is. Some plugins for sure do, I even remember using something like that in the past. (Umm.. iBrowser?) Not sure if TinyMCE within PW allows custom modules, but I believe there was an option for it.. haven't really had that need myself -
Better image management / better integration with WYSIWYG
teppo replied to mindplay.dk's topic in Wishlist & Roadmap
In our case just explaining it once usually does the trick -- haven't really had the need to add anything about this to descriptions or stuff like that. It's a simple concept really and our clients have so far seemed to appreciate it, at least once they've been explained why this works this way. Personally I prefer to think of image (and usually file) fields as "storage spaces." If content in those fields should be visible on the page (note: this isn't automatically the case!) it should be added to one of that pages visible fields (in our case most commonly named after columns -- left, main, right etc.) Of course there are special cases where you could automatically show images or files on page.. or you could use repeaters to create fixed blocks with couple of options regarding text and image positioning or something like that. Depends a lot on the use case really. Anyway, my point is that current approach is very good for many situations and can be easily customized for various needs, image manager being just one example of this. Give it a good try, see how it works for you in some real life cases and if it still feels wrong, you can always implement something else for your needs. Regardless of that, one important thing to keep in mind when working with PW is that "page" is so much more than a "page" in some of the other CMS' out there and thus comparing some features between PW and it's competition doesn't necessarily make much sense. In our case a page is an object that can serve multiple purposes and hold all kinds of data for many different purposes.. you really shouldn't expect all of them to be public or even viewable -
@lucas: take a look at http://processwire.com/talk/topic/745-module-want-related-pages/?p=16034 and https://gist.github.com/somatonic/3558974.
-
Just a quick tip: check out source for HookEvent.php. It should / could clarify things a bit, especially the comments there. Wiki article for module development isn't complete yet, but still worth taking a look at too
-
Sounds like a job for a module. There's a ton of material about module development around here, such as this Wiki article, that could be helpful for you in case that you decide to put it together. Then again, have you tried installing PixlrEditor module (https://github.com/PawelGIX/PixlrEditor) yet? Sounds to me like it already does exactly what you want..
