ryan

I don't think that you could get two instances of ProcessWire running from the same PHP script. Perhaps that's something we should work towards for the future (and we really aren't far from it), but currently the convenience and simplicity of being able to use functions like wire('api var'); among others, takes precedence over true isolation of the ProcessWire instance. While I've not tried it, I'm pretty sure this would prevent you from having more than one PW instance operating from the same PHP script. You would need your multiple PW instances to use more traditional web service communication.

Hanna Code doesn't actually execute from the DB. It writes each Hanna code to a file in /site/assets/cache/HannaCode/ and then uses the DB copy of the code to compare against the one on the file system, to make sure something hasn't changed the one on the file system. It executes the PHP code from a file in order to ensure it is as fast as possible (avoiding eval) and in the same context as a template file. That's what it does behind the scenes, but Soma's tip is just as useful either way, as Hanna Code wouldn't let you edit its own PHP files directly.

Debbie, if you want to PM me the login information to the server I can take a look at it, to at least diagnose what the issue is.

ProcessWire will automatically remove stop words from a query that's going to use a fulltext index. However, it doesn't know what your MySQL ft_min_word_len might be (minimum indexed word length). So in this case I think the issue is the 3 character word "day", when the ft_min_word_len is 4. Marty in your case I would just change the search operator from "~=" to "%=". Either that, or you could have run a second query that uses "%=" if the first fails to match any results (this would probably be better).

Is this question specific to the AdminCustomPages module or specific to the admin theme in the PW dev branch? If admin theme in dev branch, you can remove or rename whatever theme you have in /site/templates-admin/. Then go to Admin > Modules > Core > Default Admin Theme and click "install".

Have a look in /wire/modules/PageRender.module. If you find it would be helpful to have any of those methods hookable that aren't already, let me know and we can do that. We've also got /wire/core/CacheFile.php which we may be able to modify to inject a file system dependency or make parts of it hookable. The way that I implemented caching with ProCache was to just make it something completely separate from the template caching, though not sure that would be the right route for your needs or not. But this route involves hooking after Page::render() and saving the result to a file.

When the file is protected, it's getting delivered by ProcessWire rather than Apache. ProcessWire doesn't know about all the different possibilities for file mime types, so it defaults to sending it as a binary download. Meaning, your browser should save it rather than display it. Though my browser still seems to recognize and display PDFs regardless, so the behavior may vary depending on the client side.

PW is looking at the request URL. Since your request URL is /5gum/, PW thinks that's the starting point. You may need to set $config->urls->root manually to /admin/. This bit of code is probably not so safe: $brand_slug = basename ($_SERVER['REQUEST_URI']); // this would get me "5gum" $brand = wire('pages')->get("name=".$brand_slug); // this gives me a specific page I'd suggest changing it to: // sanitize brand slug with the pageName function $brand_slug = wire('sanitizer')->pageName(basename($_SERVER['REQUEST_URI'])); // this would get me "5gum" $brand = wire('pages')->get("name=$brand_slug"); // this gives me a specific page // double check that brand is what you expect and that it's viewable if(!$brand->id || $brand->template != 'brand' || !$brand->viewable()) throw new Wire404Exception();

When you get that error message "call to member function size()", what is 'images' ? Is it NULL or is it a single image field that has become a multi-image field? To tell, you could try doing a var_dump() on it or this: $images = $pers->lang_image->first()->images; echo "images is: "; if(is_null($images)) echo "NULL"; else if(is_object($images)) echo get_class($images); else var_dump(images); If it turns out that it's null, then I'd be curious what the first() is returning to you. You could run the same code on that result. We know it's got to be an object since the error occurred on the size() call and not on images. $first = $pers->lang_image->first(); echo "first is: " . get_class($first); Please let me know what you find?

No problem. Glad you got it sorted out.

That was the hope with the JSON API we put into it. Two modules that use it are the InputfieldPageListAutocomplete and ServicePages modules. Though of those two, only InputfieldPageAutocomplete uses it in the way originally intended, as ServicePages essentially translates ProcessPageSearch for front-end use.

I've pushed some updates to the CKEditor Inputfield fixing some bugs and updating to the latest version of CKEditor (4.3.2). I recommend upgrading if you are already using a past version. I've also added a couple of detailed tutorials to the README file including: How to make your own custom styles menu How to customize the appearance of the editor While you are upgrading, be sure to grab the latest version of the HTML Purifier module as well.

Mike– Looks like this module needs the dev branch (2.4). But I think we can get by with just updating your WireHttp.php class file. I went ahead and did that. Does it work now?

Regarding circular references with pages, ProcessWire was never intended to allow them. The code was already written to prevent them from occurring, per a GitHub issue that came up a few months ago. When I found out Antti's module needed them, I held off on committing those updates to make sure we could find a solution that worked with his module. So what I'm trying to determine is just if I can now go ahead and commit those updates that disallow circular page references, or if someone has a real need for them that can't be solved any other way. I have never understood the need for a circular page reference, and am not sure if they are even a good idea in any case. But if you guys have a need for circular page references, please let me know before I put the code back in place to keep them from occurring.

Nice job Nik! Does that mean I don't have to figure out how to solve circular Page references in the core, or do we still need that? What's funny is that I was working on this in the core a couple of hours ago and then got a forum notification email that Nik had found a workaround. But I can keep working to find a core-level solution if we still need it.

Give this module (attached) a try. To install, upload into /site/modules/ServicePinger/ServicePinger.module. Go to your Modules menu and click "check for new modules". Click install for ServicePinger. The module configuration screen has a textarea input where you can put in all the service URLs you want to ping. I recommend pinging one of the services that pings others, like pingomatic or weblogs.com, rather than trying to make this module do all of them. Actually, those are the only two services I've tested this with yet. When you install, it creates a new field called "pinger". Go and edit any templates you want to use it on and add the field "pinger". In your case, I'm thinking you'll just add it to the "post" template. Now edit a page with that template and see the "pinger" field you added. If you want it to ping those services, check the pinger box and save. You might want to test this out on one of your smaller sites first before migrating to your main site, as I put this together quickly and haven't yet tested it a lot. But I'm planning to add a README file and maybe a couple other details and then add it to the modules directory soon. ServicePinger.module

I'll check with Pete on that one, as I'm not sure we have permission to send mass mailings to forum members. But we do have a good size email list of people that have requested email updates from us, so I could send to that. We still need to promote the contest on our Facebook group as well. I think it might be a matter of timing. As some others have mentioned, these contests tend to get most of their votes at the end, and that might be when we need to make these requests from the community. On one hand I'm a little afraid about us investing too many resources or asking much of people for this, as I recognize this type of voting system can be controlled by motivated individuals with a farm of proxy servers or by using existing web traffic for blind submissions (opensourcecms.com is a good example of what happens). But I also don't yet see any evidence of that going on here, and with the community already rallying behind this one, I am going to do everything I can to support it too. I am hopeful that we can win this one and get PW (hopefully 2.4!) into Bitnami.

MODX is the only big CMS project that has taken the time out to participate in our community here (Mark, Shaun, now Jay, and maybe others), and all have been positive forces here. A year or two ago, Shaun, one of the MODX core developers (at least at the time), took out the time to chat with me on the phone, do some code review and provide some valuable open source tips and suggestions. No other big CMS projects have been as supportive or taken an interest in ProcessWire like MODX has. They have always been friendly to ProcessWire and I've always viewed the MODX project as like a big brother to our project. These connections are why I see any mention on Twitter in a friendly manner. Though I genuinely appreciate those who responded to the tweet and were looking out for us either way. Had it been from some other CMS project where we didn't already have these connections, it might be different. But this all reinforces to me what a great community we have here.

Jay–I wrote my message before I saw you were here (I need to refresh my browser more often). Thanks for dropping by here. No offense was taken here at all.

I didn't take any offense from the MODX tweet. I saw it as a bit of a compliment to be recognized and mentioned by them, even if that wasn't the purpose of the tweet. It's nice to be on the radar at least. I've always seen MODX as one of the big guys. When you are a relatively small project, this kind of thing is good press. They've got a lot of followers and some people that didn't know about ProcessWire may now know about it. They know that. So long as they aren't saying bad things about us, then I'd see it as a friendly mention. But then the context and scale settled in. As nice as it is to have any mention, a single tweet from them could essentially kill us in any kind of competition like this (they've got 4k+ followers). That realization got me a little down yesterday as I realized all the hard work of saml and others to get out the vote could be wiped away with a single tweet from them. Hundreds or thousands of people voting for one thing to vote against another, many perhaps not even knowing what either is. That was my fear, luckily that hasn't played out. But I'd like to thank Jeroen, Mary and others that were looking out for the project here. I honestly don't think MODX had any bad intensions (and ElasticSearch deserves recognition), but it is really awesome just to know that people are looking out for the project like this.

Antti, were you able to find a way around the circular page reference limitation in PW? I've still got on my list to find a solution for this, so was curious if you'd found another route to make it work?

Thanks for the feedback guys! I agree on the serif typeface (replacing the Georgia with another serif face), but it's not my call. I'll suggest it though. I already communicated concern about using a geometric face for body copy (Avenir) but it doesn't seem to be a major issue in the end. I'll check with the client to see what I can share on the workflow side. But essentially, this site involves 1 PW installation for managing the inventory, and another PW installation for presenting it, and they use web services to chat back and forth all day.

Whether cached at view or save, t's exactly the same amount of work either way. Though caching at save potentially creates more work. Whether we're talking about template cache or ProCache, there are a few reasons why it's better to do it upon first view, rather than upon save. Pages are only cached for guest users. If we performed an automatic cache after a page save, it would be within the context of the user editing the page. This is not a context we want to cache. You want the page to be cached within the context of a real page view, not from something automatic or behind the scenes. This ensures that any other modules that are part of the render process also get to participate. You may save a page multiple times in a short period of time (don't we all?). If it gets cached on every save, you are potentially using a lot more resources than if it was just cached the first time it was viewed from a guest user. If we regenerated on save rather than view, that would be a whole lot of extra saves that have to be performed in the system (a save uses a lot more resources than a view). Keep in mind cache files automatically expire after some period of time (defined by you). You can't rely purely on a save() for knowing when data is stale or not, as your site may be pulling data from multiple pages or other resources.

It's true that ProcessPageSearch may change down the road, though no specific plans on that at present. But if you are worried about that, rather than extending it (in the PHP class sense) you could just copy ProcessPageSearch to another module, and modify it to make your own. The PW API behavior doesn't change, so when you make something where that is the dependency (as opposed to the implementation of class that's already an endpoint) then it's a safer bet.

This might be too complex of a scenario for me to reproduce very easily here. I wonder if I could get a copy of the database, or at least an export of the field_acara_code table? Also wanted to check if you've tried to run a DB table repair on the field_acara_code table? If this issue isn't due to some stray character or encoding issue in the table data, then it sounds like potentially a broken index, or some MySQL index behavior I'm not aware of. It's interesting to me that '%=' worked while '=' didn't, because '%=' bypasses the index, doing a full table scan, whereas '=' uses the index. It might also be good to know what version of MySQL?