-
Posts
17,239 -
Joined
-
Days Won
1,701
Everything posted by ryan
-
Adam you are right, this part will go together pretty easily, and I thought we'd Ake it part of 2.2. This thread hints at how simple it will be: http://processwire.com/talk/index.php/topic,580.0.html
-
Template 'home' is used by the homepage and thus must have the 'guest' role
ryan replied to vknt's topic in General Support
The purpose here is mainly to reduce the possibility that someone takes their entire site down by clicking the wrong thing. Too likely to cause problems and support burden, so decided to make the guest role required at the root. But it's easy to get around. If you don't want your homepage accessible, add a line at the top of your template: if($user->isGuest()) throw new Wire404Exception('page not found'); If you want that for the whole site then put it in your header include or main output file. -
Nice work Nikola!
-
Thanks guys. That's a good point @apeisa–PW2 turns 1 next month and that's definitely a better thing to celebrate.
-
For experimenting/testing, you may want to just clone the InputfieldTinyMCE class and files (InputfieldSlightlyLargerMCE?) and put it in /site/modules/ so you've got a sandbox version to work from. One way that you can manipulate the TinyMCE config is to edit a page, view the source, and note the JS 'config' var at the top. See any fields that are using TinyMCE and you'll see the configuration settings there. These are in place well before TinyMCE is initialized. And from here you can overwrite any of TinyMCE's defaults, for any field (using javascript or PHP). And it doesn't have to be one that's already there... it can be ANY TinyMCE configuration option. For example, if you wanted to change the URL to content.css for your 'body' field. From PHP, you'd do it like this (in an event that runs before Page::render): $this->config->Inputfield_body['content_css'] = '/url/to/content.css'; Or from JS: config.Inputfield_body.content_css = '/url/to/content.css'; That JS would have to run before TinyMCE is initialized, meaning before the document.ready() event is triggered (unless you have your script fire in document.ready before the TinyMCE one does). So you could do this by inserting a <script> tag into the output before the </head> or right before the </body> or inline if you preferred it. I've not tried this myself, so your results may vary, but I think this should work.
-
I wanted to add this here for those that may come across an admin theme here they want to install, but not know how. It's very easy, just create a directory called /site/templates-admin/ and upload the admin theme files there. That's all there is to it. For more detailed install instructions and a directory of ProcessWire admin themes, go here: http://processwire.com/download/admin-themes/
-
I don't see anything obvious in the code that we can point to. Though there is a lot here, so it's tell without stepping though live code. But if it's something that you yourself can't duplicate, then it's going to be a little hard to troubleshoot so we'd have to do more investigation into the error. I would suggest starting by matching up the time of the error email to entries in your apache log. See what requests were occurring at the time the error occurred. Was it a GET or POST request and what URL was it hitting? Grep the IP address in your log to see if it's a legitimate user or someone fishing for holes. Once you can match the request in your log to the error, we will at least know exactly what page (and likewise what template) is generating the error. It looks to me like PW doesn't yet know what page it's serving because it lists a "?" for the page, so there's a good chance this error may be occurring at bootstrap time. How random is the error? Does it come in at the same times every day and how many do you get?
-
You are absolutely right, it wasn't showing up on GitHub. And yet locally it told me there was nothing to push or commit. So I had to go in and add a comment to the line in order to make something change so it could be re-committed. Must be a GitHub bug. Confirmed it's up there now. Thanks for letting me know, this change might not have shown up there for weeks otherwise.
-
I totally agree. I'm going to add to the roadmap right now.
-
Thanks that's very nice of you all. I'm a little embarrassed by the attention, but hopefully someone else will have a birthday here before too long.
-
Just testing out here, and this is really a beautifully designed theme. It's something completely different and very compelling–love it! Looking forward to spending more time using it.
-
Just fixed this in the latest commit. The problem turned out to be in the Page::__clone() function. If there were page references pointing at each other, it could cause an endless clone loop. I've fixed it by preventing it from cloning Page properties that are themselves Page objects (which didn't need to be cloned anyway). Thanks for providing me the Revive site to test with, this was hugely helpful. If you grab the latest commit, it should now work with your Revive site just fine.
-
Thanks those looks should be helpful, I will take a closer look soon. It sounded to me like Jose had things working well with nginx, though I never did hear back about the directories that needed to be blocked and rewrite rules that need to be maintained for security. I'm guessing that will be a relatively simple solution, but would want to make sure those issues are covered before running it.
-
Just looking in the PageFinder to see where it is using the alias 'rootparent' … do you have any selectors in your site that include multiple paths? For instance: parent=/a/b/c|/d/e/f/ path=/a/b/c/, parent=/d/e/f/ When did the error start appearing, and can you think of any changes you made near the time it started occurring?
-
Module Profile Export module (also upgrade PW 2.0 to 2.1)
ryan replied to ryan's topic in Modules/Plugins
Thanks for testing it out. This module is a bit of a work in progress that is more ready for upgrading PW 2.0 to 2.1 than it is for anything else, and that's where I've focused my attention and testing in the short term. I decided to get it out sooner rather than later since there were several people asking for the ability to upgrade PW 2.0. Though it's not far off from more since the process is so similar. However, profiles are more accurately termed 'installation profiles' so they aren't meant to include user accounts. The fact that it included user accounts at all in your export would mean that's a bug I have to fix. Though the intention is that this module will give you the option to include or exclude user accounts. For instance, if you want to export a profile for migration of a site from dev to live, then you could export a profile that includes user accounts. That will probably come in the next version. -
I see the ability to import data provided by form submissions into pages as pretty important. While it may or may not be in the first preview version of the form builder, it's something that is most definitely part of the overall plan.
-
Here is a link to the roadmap, though it's a bit of a work in progress as I've not yet added everything to it that should be added: http://processwire.com/about/roadmap/ The direction of the roadmap is dictated by equal parts of: What features are consistent with the needs of the development team and the clients they work with. What features are most requested by the community. What features are others wanting to sponsor the development of. What features are most tangible to accomplish in the short term. We don't accept donations, but you can sponsor development of ProcessWire features. For instance, if there is something that you need and you want to see it happen sooner rather than later, then we can give you an estimate and timeline to build it. For instance, the company that @apeisa works for is sponsoring the development of the multi language support in the admin planned for 2.2 (currently in progress). My company (RCD) specializes in the design and development of ProcessWire sites, as well as the development of custom modules in ProcessWire, so please feel free to email me if you'd like to talk more, my email is ryan at this domain name.
-
I haven't heard any more on it here. What environments are people using it in? Is this something used by any hosting providers, or just something one would use on their own dedicated server? Just wondering what might be the best way for me to get a test environment going sometime in the future.
-
I've not seen that error before. Do you have any other context of when it happens?
-
Required is not supported by most fields at present. So you only see the option if you've got the $config->advanced turned on. It's best to leave $config->advanced turned off, because it's easy to break things with it on and there are some things shown where support is inconsistent. That advanced setting is really meant for when we're developing or adding features to PW, and it's troublesome otherwise. Though we will be having full 'required' support for all fieldtypes soon, perhaps in 2.2, and at that time the 'required' option will show up without advanced mode being on.
-
This thread has been really helpful to read. It's interesting to hear how you all found ProcessWire, and it's different than I would have thought. Among other things, It makes me think we should target things like custom fields in our keyword strategy rather than things like jQuery. For instance, terms like 'custom fields cms' seem appropriate, and we don't appear for those right now. We do show up for 'jquery cms' (top of page 2, google) but that's not really a driver of traffic and more clear now that it's not what people are looking for. I don't think this is a quick fix. I don't see a way around the problems with the system unless you tie the votes to accounts or reviews. What they are doing is tying it to an IP address and that's it. So all you need is a rotating IP (remember AOL?), proxy server, or even a cell phone, and you can vote as many times as you want. If you want to down/up vote something fast and en masse, then you just take that same concept an existing site with traffic and point a hidden iframe and image src to the voting mechanism... then every user unknowingly becomes a voter. It's a hugely flawed system. But not any more so than any others that allow anonymous votes. So it's not technically opensourcecms.com's fault, other than that they've chosen to accept the compromises associated with such a system. And those compromises are not obvious to most people that visit. What it gets down to is that I think we're conditioned to give more legitimacy to such ratings than they deserve. For me, that's because I rely on Amazon's star ratings for when I buy stuff. But their system is pretty good– If someone wants to upvote or downvote something en masse, it's a bit hard to do because every vote has to be tied to a real person with a credit card number. It's easy for me to forget that other star-rating systems aren't nearly as legitimate as that. Someone suggested earlier in the thread that they should tie every rating to a real review, and I agree with that. That would prevent automated attacks on the ratings system and make it a real pain for someone to try and manipulate the ratings. I think that's the only way you can give legitimacy to an anonymous 5-star ratings system like this. I didn't realize it was viewed that way before you wrote it, but it's really quite a powerful metaphor and definitely makes me think a little differently about the software. I do wish they had asked for permission before taking the logo and pasting it into the ads. On the other hand, they are still providing a good service to the community by hosting all the CMS demos and I know it can't be cheap and they've got a business to run. My opinion is that if they have to use those ads, then they should only use them on the CMSs they are hosting the demos for… because presumably they are using that hosting service to host the demos. I hope I can get in contact with someone there because it seems like they are overall a good service that is just making a few mistakes and maybe they just don't know how they are perceived. I also want to clarify that this is multi-language support in the admin so that people can see PW's tools in their own language. This isn't a new solution for a multi-language web site on the front end. Though there is some crossover and some may find the additions handy for front-end stuff too. But this would not replace a full multi-language solution on the front end (like what LorGG is working on).
-
Thanks-that is great!! it actually makes a pretty nice looking bottle of wine. And some smooth photoshop work. The branded glass is a nice touch too. If it really were a ProcessWire bottle of wine it would be a jammy zin with 22% alcohol and a patented energy blend of caffeine powder, yohimbe extract, adderall, wheatgrass, partially hydrogenated 5-hr energy, hemp seed oil, nyquil, sodium benzoate (for freshness) and essential vitamins and minerals. A good house wine for any time of the day.
-
Just turned 37 this week and always get a little depressed for a bit every birthday. But these comments and reviews really made my day, and made it a great week! So thanks for that. Also, @slkwrm your in-depth review was really well thought and gives me new perspective. The weightlifter/ballerina concept is intriguing, flattering, disturbing, and hilarious! Especially after seeing Soma's images. This is easily my favorite thread yet. Opensourcecms.com is a bit of a disappointment because we legitimately rose to the #1 spot there over the period of a week with real users and real votes. Then, in the matter of an hour, someone gave us the slapdown with 50 1-star votes. Apparently someone was threatened by PW's placement there. Over the same time (seemingly at least), Joomla rose to the #1 spot despite having a high percentage of bad reviews. To make matters worse, they are using the PW logo in ads on their site so that it appears we endorse their advertisers. And I have no idea why they aren't posting your reviews--I've heard this from a few people now. In fairness, the slapdown may have not been their fault, but their voting system is flawed to the point of being useless. After taking a closer look at it, I learned that it could be manipulated quite easily with less than 10 lines of PHP, a strategically placed iframe and some CSS to hide it all. Place the code on any site and every visitor unknowingly becomes a voter (circumventing the IP restriction), whether doing a slapdown or a boost. Clearly such a technique was used to slapdown PW and [i'm guessing] boost Joomla. One could inflate any rating to #1 or last in a matter of hours. I put together a test case to try it once (submitting 1 vote for PW) and, sure enough, that's exactly what appears to have happened. I would never use something like that because I view it as cheating. But it made me feel a little better to at least know how it was done and that the folks at opensourcecms.com weren't out to get us (I'm hoping not, anyway). But if anyone shares my curiosity let me know and I'll PM you what I found (just don't use it). The good news is that PW has already climbed quite a bit out of that slapdown hole legitimately. Honestly I wouldn't care about any of this except I've held that site in such high regard for so many years (and waited a long time to post PW there), that I was just a little disappointed to see the ratings system I used to take seriously is just a joke. But I probably should have known better. I'm still holding out hope that they will post everyones reviews, as that is where the real value is there and there's no joke about real reviews from real people. Also, made good progress with PW 2.2 today and admin multilanguage support! I'm posting from a cell phone in the middle of the night (woke up and trying to get back to sleep) so apologize if this post is poorly written, crazy or incoherent.
-
Thanks for sending over the site profile. Just wanted to let you know I've got it installed here and hope to have it figured out by next week.
-
Module Profile Export module (also upgrade PW 2.0 to 2.1)
ryan replied to ryan's topic in Modules/Plugins
Michael, thanks for testing that. I have updated the instructions on this page (under the 'How to export a profile' section) to account for this. It now includes the /site/modules/ directory as an optional inclusion. And the same applies to /site/templates-admin/ and /site/config.php. Everything has to be ready-to-go in the import profile before the PW installer is run.