Forum Replies Created

Viewing 15 replies - 46 through 60 (of 70 total)
  • Forum: Plugins
    In reply to: [Broadcast] Image handling
    Thread Starter cvc1968

    (@cvc1968)

    So I’m guessing I need to UN-broadcast the post(s), then turn debugging on, then re-broadcast in order to get that debug dump? Would that be the correct procedure?

    Thread Starter cvc1968

    (@cvc1968)

    Here is an example… On this page, the third and fourth result are Events that have past.

    Search Example

    Those two “Cooperative Education” events should no longer show up in search.

    Thread Starter cvc1968

    (@cvc1968)

    I did look into possibly writing my own search form to replace your search function, but ultimately found a solution that will work ‘good enough’ for my casting people. I simply created a collection of pages — duplicates of the Actor/Model list, but with the some additional date of birth filters to create lists by decade of birth (i.e. 1971-1980, etc). Then created a menu that appears a the top of all the list pages allowing selection of a decade if desired. It narrows the choices sufficiently for our purposes.

    I am looking forward to you next release, and I may revisit the idea of revising the search form once I’ve had a look at your new API hooks and templates.

    Thanks

    Thread Starter cvc1968

    (@cvc1968)

    So after reading your responses, I checked the site’s General settings…it WAS set to display date like this: September 13, 2013. Problem was that I was following your site’s instructions too literally. [pdb_list filter=’date_of_birth>jan1,2000′] did not work, but [pdb_list filter=’date>January 1, 2000′] does. I also tried changing the site to display dates as 09/13/2013 (American way) and then a filter setting like this: [pdb_list filter=’date>01/01/2000′] worked as well. All is good with shortcode filtering.

    As for the front-end search…I can manage without it, but it would be a nice addition sometime down the road. In Filemaker it looked like this:
    01/01/2000...12/31/2002
    If it was the same as the shortcode filter syntax, would that be easier to implement?
    As in:
    >January 1, 2000&<December 31, 2002

    I’d even be happy if it had to be entered exactly like the shortcode:
    date_of_birth>January 1, 2000&date_of_birth<December 31, 2002
    I could provide instruction to my limited number of users in how search with that syntax.

    Anyway, regardless of what, if anything, you come up with, this is a great plugin.

    Thread Starter cvc1968

    (@cvc1968)

    Sorry, forgot to mark as resolved in my previous reply.

    Thread Starter cvc1968

    (@cvc1968)

    That’ll be great. I can wait. Excellent work. Thanks.

    Thread Starter cvc1968

    (@cvc1968)

    Well, with apologies…I had marked this as resolved but have to change it back to not resolved.

    Unfortunately, that auto sync that occurred (mentioned in my second post) was apparently a fluke. Or something…I’m not sure. SOME of the files that I left uploading via FTP were added to Filebase…those that were uploaded before 7pm. This coincides with this message that appears next to the manual sync button:

    Automatic sync is enabled. Cronjob scheduled hourly. (Last cron sync on August 8, 2013 at 6:57 pm.)

    As I write this it is August 9 at 10:24am. No explanation as to why no more syncs occurred after 6:57pm. I do not know if syncs occurred hourly up until 6:57pm. Is there any log file that would show whether or not those syncs occurred?

    I’ll keep monitoring. Hopefully some better evidence will present itself. Meanwhile, I’m open to any troubleshooting suggestions or other ideas.

    Thank you.

    Thread Starter cvc1968

    (@cvc1968)

    Well, I spoke too soon, I guess. After a week of struggling with this without effect, it now suddenly seems to be working. Not sure why. I’ll keep testing to see if this was a one-time success or if it will now work consistently.

    Thanks

    I’ve just experienced this as well. In fact, my htaccess file is a disaster. There are numerous instances of #BEGIN WordPress and in some cases, it overwrote only part of the WordPress section. My client was merely making edits to some page content. One second it worked, then suddenly she got an Internal Server Error. Take a look below. Note that there is no #END W3TC Page Cache core. It was overwritten. Then after the first #END WordPress, you see the truncated portion of a duplicate WordPress section. This is what was causing the Internal Server Error I presume…(the line that starts with the partial URL)

    This is the second time this has happened to this site. The first time, W3 Total Cache was NOT installed, and I figured it was an aberration. However, I need to identify the cause of this problem to prevent it in the future. I guess I will chmod 644 for now, but that seems it would decrease functionality for the future. Any ideas why this is happening and how to prevent? Thanks.

    [UPDATE: I just discovered that the new .htaccess file is already set to 644. Should I set it to 444, thereby disabling the last of the ‘write’ abilities for user?]

    # BEGIN W3TC Browser Cache
    <IfModule mod_deflate.c>
        <IfModule mod_headers.c>
            Header append Vary User-Agent env=!dont-vary
        </IfModule>
            AddOutputFilterByType DEFLATE text/css text/x-component application/x-javascript application/javascript text/javascript text/x-js text/html text/richtext image/svg+xml text/plain text/xsd text/xsl text/xml image/x-icon application/json
        <IfModule mod_mime.c>
            # DEFLATE by extension
            AddOutputFilter DEFLATE js css htm html xml
        </IfModule>
    </IfModule>
    # END W3TC Browser Cache
    # BEGIN W3TC Page Cache core
    <IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteBase /
        RewriteCond %{HTTPS} =on
        RewriteRule .* - [E=W3TC_SSL:_ssl]
        RewriteCond %{SERVER_PORT} =443
        RewriteRule .* - [E=W3TC_SSL:_ssl]
        RewriteCond %{HTTP:Accept-Encoding} gzip
        RewriteRule .* - [E=W3TC_ENC:_gzip]
        RewriteCond %{REQUEST_METHOD} !=POST
        RewriteCond %{QUERY_STRING} =""
        RewriteCond %{REQUEST_URI} \/$
        RewriteCond %{HTTP_COOKIE} !(comment_author|wp\-postpass|w3tc_logged_out|wordpress_logged_in|wptouch_switch_toggle) [NC]
    
    # BEGIN WordPress
    
    <IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteBase /
    RewriteRule ^downloads([^/]+)$ https://www.wvup.dreamhosters.com/wp-content/plugins/download-monitor/download.php?id=$1 [L]
    </IfModule>
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    
    # END WordPress
    reamhosters.com/wp-content/plugins/download-monitor/download.php?id=$1 [L]
    </IfModule>
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    
    # END WordPress
    # BEGIN WordPress
    
    <IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteBase /
    RewriteRule ^downloads([^/]+)$ https://www.wvup.dreamhosters.com/wp-content/plugins/download-monitor/download.php?id=$1 [L]
    </IfModule>
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    
    # END WordPress

    Try putting the jQuery script into compatibility mode.

    For me, this fixed the problem:
    in the iNIC FAQ -> Settings, scroll to the bottom to the “Custom JS” field. Change all instances of “$” with “jQuery”.

    Thread Starter cvc1968

    (@cvc1968)

    One correction. I have realized that I have not enabled ImageMagick in the NGG settings, so the code I found relating to errors in the ImageMagick code is likely irrelevant.

    I haven’t found any other code containing the error string in the plugin files. Is GD Library part of the WordPress install?

    In any case, if anyone has any ideas how to stop the error message images from appearing, please let me know.

    Thanks.

    Thread Starter cvc1968

    (@cvc1968)

    Yes, I found the appropriate line in the plugin code. Of course, I really don’t want to modify that file.

    I attempted to override the code in my functions.php by copying the entire class from the plugin file, changing its name, and removing the original action.

    Unfortunately, I wasn’t able to get it all to work. I may try again when I get some other work done on this project, though it is an awful lot of work to change one line of code.

    I don’t understand why this string isn’t editable in the Formats tab of the plugin settings page. Every other possible display string is editable from there.

    If this becomes too big a fuss, the client may just have to either learn how to change it in the widget or live with the European date format in the widget.

    I also would like to request support for Custom Post Types. Any update on this since the last post?

    Thanks, scribu,
    I’ll give it a try.

    I have one possible workaround for this (see below)

    I have the same problem — just installed 1.9.2.1 in WordPress 3.0.4. I’m viewing using Safari (which is what my clients will be primarily using).

    All seems ok when the WYSIWYG editor is turned off. When the WYSIWYG Editor is turned ON, I get the narrow texarea. Inspecting the element reveals that there is an inline style width of 104px applied to two divs. The first div seems to be a container for the WYSIWYG editor buttons and the second is a container for the editable text itself. There is also another nested div with a width of 96px. Here is the relevant code I’m seeing:

    <div class="fee-form fee-type-rich fee-filter-the_content">
    
    	<div style="width: 104px; " unselectable="on">
    	  <!--- HERE IS WHERE A ALL THE ELEMENTS OF THE WYSIWYG BUTTON-BAR ARE DISPLAYED --->
    	</div>
    
    	<div style="width: 104px; ...ETC>
    
    		<div style="width: 96px; ...ETC>
    			<p>
    			MY POST CONTENT BEING EDITED HERE
    			</p>
    		</div>
    	</div>
    	<!--- MORE DIVS CONTAINING ELEMENTS SUCH AS SUBMIT BUTTON ETC --->
    </div>

    I have made it usable by adding the follow CSS to my template style sheet (only tested in Safari so far):

    div.fee-form > div {
    	width: 100% !important;
    }
    
    div.fee-form div > div.nicEdit-main {
    	width: 98% !important;
    }

    Another problem is that when the WYSIWYG Editor is turned ON, the “Display a tooltip above editable elements” option does not function, even though it is also enabled.

    Thanks.

Viewing 15 replies - 46 through 60 (of 70 total)