Forum Replies Created

Viewing 15 replies - 1 through 15 (of 26 total)
  • Shaun –

    Keep in mind the Airtable formatting controls affect only the *display* of information in the Airtable view; internally currency is stored as simply as an integer or decimal. You’ll either have to format the numbers yourself using javascript (there are tons of libraries that support this) or convert the currency fields to formatted strings in the base itself and retrieve the strings through Airpress. If you want to do the latter, you might want to steal some code from my pretty-print routines as found in this Community post:

    https://community.airtable.com/t/number-and-currency-pretty-print-routines/10807

    Thread Starter mazoola

    (@mazoola)

    Chester –

    So, I’ve been experimenting with hooking flush_rules to various points in the theme update cycle whenever Elegant Themes has rolled out a new Divi update — all to no avail. Fortunately, thanks to the Rewrite Rules Inspector plugin, it’s no problem to flush rules manually after a Divi upgrade — but now I’m pursuing it for the satisfaction of the chase itself. If anything dawns on you, please let me know — and should this blind pig happen to stumble across an acorn, I’ll do the same…

    Thread Starter mazoola

    (@mazoola)

    Chester –

    No, that’s a great help. I was looking at this a couple of days ago until I began to go cross-eyed, but I’m almost ready to jump back in.

    One thing I found that looked potentially useful was this — especially the section on flushing rewrite rules on activation.

    At one point he describes the 4-step process that occurs whenever a plugin is activated — which I assume also occurs when Divi returns from upgrading itself.

    1. The browser loads the plugins.php file.
    2. plugins.php file includes admin.php file. As a result, all other plugins have been loaded, and the init hook has already been called. WordPress doesn’t even know our plugin is activated yet, so of course your register_post_type() function hasn’t been hooked into init. Consequently, your CPTs are not registered.
    3. Then plugins.php calls activate_plugin()
    4. Our plugin is included, and your activate() function is called. Rewrite rules are flushed, but because your CPTs are not registered, nothing really changed.
    5. This chain of events might sound simple and straightforward to you, but it got me every single time I create a plugin. Every. Single. Time.

    I don’t know if that parallels Airpress’s experience, but I thought it might be worth a look.

    (FWIW, I’m upgrading from the console. This doesn’t seem to be a common problem with Divi, as the only post on Elegant Themes’ Divi board concerning 404s after upgrade is from 2014 and was caused by a WordPress bug involving child themes.)

    I’ve had two teapot-sized tempests blow up in the last couple of hours that, irritatingly, have to be calmed. If I free myself from them quickly enough, maybe I’ll kick things around a bit more.

    Thanks again!

    • This reply was modified 6 years, 7 months ago by mazoola.
    Thread Starter mazoola

    (@mazoola)

    Unsurprisingly, the same thing happened again following last night’s Divi update. If I get a chance to read up on plugin activation (all I know is ‘don’t tie flush_rules() to Init()‘), I may give it a shot.

    • This reply was modified 6 years, 7 months ago by mazoola.

    Sorry; that was about the most disjointed message I can recall writing in a while.

    What I was suggesting was that you create an additional field called ‘slug’, perhaps, defined as a formula field using some variant of the ones I provided, and pre-encode your record {name}s. Then, modify your Virtual Posts to match on {slug} rather than {name}. That’s how I deal with a base loaded with names containing reserved or extended characters….

    Maz

    Probably not the solution you’re looking for, but because of similar issues I match on a formula field called ‘slug’ rather than on the actual ‘Name’ field. In my case, I use the following formula to slug-ify record names:

    LOWER(SUBSTITUTE(SUBSTITUTE(SUBSTITUTE({name},"/","-")," ","-"),"é","e"))

    In your case, you might want to do something along these lines:

    LOWER(SUBSTITUTE({name}," ","%20"))

    There are a number of standard URL-encoding substitutions, but you’re probably safer to include only the ones you need. The following are considered ‘reserved’ characters under RFC 3986 and must be encoded if included as part of a URL:

     !    #    $    &    '    (    )    *    +    ,    /
    %21  %23  %24  %26  %27  %28  %29  %2A  %2B  %2C  %2F

     :    ;    =    ?    @    [    ]
    %3A  %3B  %3D  %3F  %40  %5B  %5D

    That said, your web server and/or WordPress will almost certainly intercept ‘/’, ‘?’, and ‘&’, at least, before they get to you. [As you note, the space character should be encoded as ‘%20’ and the percent sign (‘%’) as ‘%25’. If you need to support the latter, it has to be handled in the most deeply nested SUBSTITUTE() call lest you end up with such things as ‘%2520’ for a space.]

    The following formula is overkill, but it will encode all reserved characters except ‘/’, ‘?’, and ‘&’, plus the space character and ‘%’. Again, I recommend you *not* use it but instead create only those substitutions for which you have a definite need.

    LOWER(
    	SUBSTITUTE(
    		SUBSTITUTE(
    			SUBSTITUTE(
    				SUBSTITUTE(
    					SUBSTITUTE(
    						SUBSTITUTE(
    							SUBSTITUTE(
    								SUBSTITUTE(
    									SUBSTITUTE(
    										SUBSTITUTE(
    											SUBSTITUTE(
    												SUBSTITUTE(
    													SUBSTITUTE(
    														SUBSTITUTE(
    															SUBSTITUTE(
    																SUBSTITUTE(
    																	SUBSTITUTE({name},"%","%25"),
    																" ","%20"),
    															"!","%21"),
    														"#","%23"),
    													"$","%24"),
    												"'","%27"),
    											"(","%28"),
    										")","%29"),
    									"*","%2A"),
    								"+","%2B"),
    							",","%2C"),
    						":","%3A"),
    					";","%3B"),
    				"=","%3D"),
    			"@","%40"),
    		"[","%5B"),
    	"]","%5D"))

    Maz

    • This reply was modified 6 years, 7 months ago by mazoola.
    • This reply was modified 6 years, 7 months ago by mazoola.
    • This reply was modified 6 years, 7 months ago by mazoola.
    Thread Starter mazoola

    (@mazoola)

    Another Divi update — and more 404s. After the update, the rewrite rules inspector plugin showed all Airpress rewrite rules as missing. When I checked the Airpress Virtual Post definitions, though, they showed there were matching records for the test URLs. I noticed one VP didn’t show matches, so I changed the regex from (*.) to ([^/]+)/?$ and saved the VP. At that point, the rewrite plugin showed all rules present, and my Airpress-powered pages began appearing again. I assume the call to flush_rules() was responsible for the fix, but I’m not conversant enough with WordPress programming to understand why it’s not being called (or, if it is being called, what might be blocking it) on the return from maintenance mode.

    Hope this helps…

    Edit:
    In looking through 1.1.42, I don’t see any calls to flush_rules outside of the *Admin modules. Should there be a flush call hooked to plugin activation or loading as well?

    • This reply was modified 6 years, 7 months ago by mazoola.
    Thread Starter mazoola

    (@mazoola)

    So Divi finally updated today… and the 404s returned.

    Rewrite rules inspector shows all Airpress-related rewrite rules as missing. Using that plugin’s ‘flush rules’ button brings them back into existence, and Airpress starts working again. I realize this could easily be a conflict with another plug-in. Is there an easier way to test than, the next time a theme update is available, backing up my site, disabling a plugin, updating the theme — and, if that doesn’t catch the problem, restore, rinse, repeat?

    V

    Forum: Plugins
    In reply to: [Airpress] New pull request
    Thread Starter mazoola

    (@mazoola)

    Oops.

    Thread Starter mazoola

    (@mazoola)

    Of course, since you pushed 1.1.42, Divi hasn’t released a double-aught update. No 404s, of course, but…

    Thread Starter mazoola

    (@mazoola)

    No, all three VPs have valid sort fields…

    I’m in and out today, but I’ll text you when things settle down and we can figure out next steps. (I wish I could find a reliable trigger — or at least a way to make sure one of my deactivated plugins wasn’t the cause, as I don’t want you jumping through hoops needlessly.)

    Thread Starter mazoola

    (@mazoola)

    So after the latest Divi update, a few minutes ago, all I get are 404s. None of the presumed valid URLs still work.

    Essentially all my rewrite rules were missing, so now I suspect it’s a process of tracking down an offending or incompatible plug-in. I deactivated everything I’m not presently using and await the next Divi update….

    Thanks!

    Thread Starter mazoola

    (@mazoola)

    I’m pretty sure all three VPs are using the regex you suggested a while back.

    Yep:
    ^wardrobe/garment/([^/]+)/?$
    ^wardrobe/outfit/([^/]+)/?$
    ^wardrobe/item/([^/]+)/?$

    Thanks for the pointer to the plugin; I’ve been driving myself mad writing comment statement after comment statement. I had been wondering if you or anyone else made use of IDEs and, if so, which one, but this might be everything I need.

    Huh. I wondered why that was happening — but never dreamed it was Airpress-related… Thanks, @anvi7924 for IDing the problem, and thanks Chester for the quick fix!

    Thread Starter mazoola

    (@mazoola)

    Chester –

    After far too much banging of my head against the wall, I hit upon the boneheadedly simple idea of extracting the first image’s URL and storing it as an Airtable field. Unfortunately, I don’t seem to be able to access either thumbnail URL through Airtable, so very large images can slow down initial page loads — but I can now get back to the business of actually building the app.

    I’d still like to understand better the combined Airpress/WprdPress loop, as the one thing I managed to learn after hours of tracing through the code was I’d been looking in entirely the wrong place: The shortcodes referencing the images were being stripped or [incorrectly] replaced well before my window of visibility opened.

    Unfortunately, I’m also nearing the end of what I can accomplish using only shortcodes — and, so far, my experience with using both shortcodes and PHP routines on the same resource hasn’t been the best. The next couple of weeks, I’ll be moving within the city, but once that’s done expect me to pipe up even more frequently with questions

Viewing 15 replies - 1 through 15 (of 26 total)